From owner-freebsd-hackers Sat Apr 26 13:14:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06477 for hackers-outgoing; Sat, 26 Apr 1997 13:14:25 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA06470 for ; Sat, 26 Apr 1997 13:14:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA07503; Sat, 26 Apr 1997 13:10:33 -0700 From: Terry Lambert Message-Id: <199704262010.NAA07503@phaeton.artisoft.com> Subject: Re: VFAT 32 support in msdosfs To: joa@kuebart.stuttgart.netsurf.de (Joachim Kuebart) Date: Sat, 26 Apr 1997 13:10:33 -0700 (MST) Cc: sysop@mixcom.com, hackers@freebsd.org In-Reply-To: from "Joachim Kuebart" at Apr 26, 97 10:33:11 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Much rather have NTFS in 95 with all the little BS files less then 1K. > > Does NTFS have owners and permissions like any file system should? Besides, I > don't understand why they didn't just use NTFS... Only so now there's 2 > _incompatible_ bad file systems ? Despite the claims to the contrary, the only real win in NTFS is the directory btree's, and then only for what a UNIX user would consider a *really* full directory. In general, NTFS performs worse than VFAT. With VFAT hogging all free memory as much as it can, and with the full directory (mostly) in core (see the MACH paper, which turns off all the performance attributes of FFS as "unfair" and then loads the entire FAT into core as "a necessary optiomization"), you would be hard pressed to beat VFAT in a race. We were able to do it with FFS in the Heidemann framework under Windows 95, and then only got really serious performance improvement after implementing our own paging handler and soft updates. We had some really clever people. Log structuring, and all the associated BS, is only really useful if you have database transactions, and even then only if the transaction interface is exported to the top level. The performance and reliability comparisons to FFS are all pretty much bogus. With a coulpe of minor tweaks (like setting up the default block size from a measly 4k), it was possible to get the UFS (FFS) in UnixWare to perform withing 5% of VXFS on the same hardware. So much for the touted improvements, other than the transactioning features. The only people to really take off with this type of FS design are Network Appliance Corp., the people who got Guy Harris after Auspex. They get their winds from FFS-style geometry optimization, using stripe sets ias if they were physical geometry artifacts. Quite clever, actually, but not terribly suitable for paging access, as in interactive use, as oppossed to be a server on a wire (it's to be expected: it was *designed* to be a server, so that's the right trade). If you are really interested in NTFS, I recommend: The read-only NTFS code available for Linux Inside the Wondows NT File System Helen Custer Microsoft Press ISBN 1-55615-660-X Inside Windows NT Helen Custer Microsoft Press ISBN 1-55615-481-X The first goes into enough detail that you could write a read-only NTFS, if you had one to test your code on. Get the second only if you are interested in the NT security model, since it has little real information on the FS itself, other than explaining why some of the FS stuff from the first book is the way it is. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.