From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 27 Jan 2005 20:08:32 -0800 From: geoff@collyer.net To: 9fans@cse.psu.edu Subject: Re: [9fans] fossil speed In-Reply-To: <568ba9e3d5e7d0a4f1031424662d5f89@granite.cias.osakafu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 37e55a34-eace-11e9-9e20-41e7f4b1d025 It is possible to generate file server kernels exactly compatible with existing ken fs on-disk file systems, but you get none of the benefits of the new file server if you do that. It does however let you build old and new file server kernels from the same sources. If you want to get the benefits of the new file server (64-bit file sizes, offsets and block numbers; smarter IDE code ported from the cpu kernel; larger file name components; indirect blocks beyond double-indirect; etc.), you have to build a new file server kernel that will not be compatible on disk with existing file systems (it will however speak 9p2000 compatibly, though not 9p1, because 9p1 depends crucially on NAMELEN being 28; 9p1 is disabled in the new file server kernels, but it turns out that nothing needs 9p1 any more [old drawterm uses it, but it never connects to file servers directly]). I decided that I could live without the history on my old file server, so just copied its main file system to a new file server. It's nice to not need lnfs any more.