From owner-freebsd-hackers Mon Dec 22 12:54:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26400 for hackers-outgoing; Mon, 22 Dec 1997 12:54:21 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26382 for ; Mon, 22 Dec 1997 12:54:06 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA18077; Mon, 22 Dec 1997 12:33:53 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd018075; Mon Dec 22 12:33:52 1997 Message-ID: <349ECE06.167EB0E7@whistle.com> Date: Mon, 22 Dec 1997 12:31:02 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Luoqi Chen CC: dima@tejblum.dnttm.rssi.ru, hackers@freebsd.org Subject: Re: msdosfs win95 long file name support References: <9712221554.AA11732@watermarkgroup.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hi! this is great.. from 0 options to 2 options in 2 days.. Is there a possibility that you guys can make a version of teh netbsd code that is clean enough to be acceptable to dima and friends? :) that way we can commit a single set of changes rather than trying to figure out which to apply. Luoqi Chen wrote: > > Actually I looked at NetBSD's code before I started. But its lookup code is > somehow not very efficient: directory entry found is stored as directory > relative offset, as opposed to file system relative offset as in our code. > This results in extra pcbmap() calls in subsequent vnops (this problem is > somewhat alleviated by the usage of fat cache, though). > > Their long file name support is not very well designed too. For instance, > if we are to create a file with long file name, we need to find a unique > 8.3 name. The logical place is to do that is in the lookup code, where we > traverse the whole directory. NetBSD's code instead does that in vnops code, > which means that you need to go through the directory TWICE. This is a > Bad Thing(TM) if the directory is very large (say, windows/system :) > > So I decided to modify our existing code, instead merging with NetBSD's code. > More efficient code in less time. > > > Some other differences: > > - NetBSD support FAT32 (I haven't tested it) > This would be nice to have in our code. I don't know how hard that would be. > I remember read in the mailing-list archive, someone said it was a completely > different beast than FAT16/12. > > > - NetBSD support such things as access time of a file. > Yes, they support creation/access time. But they didn't try hard to set them > correctly. If I've read their code correctly, both creation and access time > are always set to equal to the modification time. After all, it is trivial > to add support for them. > > > - NetBSD removed warning "root directory is not a multiple of the clustersize > > in length" :-) > > There's one feature in NetBSD's code I think would be useful. They have a > mount option called shortname, which allows you to use the 8.3 name space. > I added that to my code last night, this involves changes to sys/mount.h > and userland mount program (mount_msdos), and lkm has a different API, it's > no longer a drop-in replacement for the old module. So I am not sure if I want > to distribute the code now. > > > > Dima > > > > > > > -lq