From owner-freebsd-hackers Mon Dec 22 18:40:09 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA21891 for hackers-outgoing; Mon, 22 Dec 1997 18:40:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from watermarkgroup.com (luoqi.watermarkgroup.com [207.202.73.170]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA21572 for ; Mon, 22 Dec 1997 18:34:49 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by watermarkgroup.com (8.8.8/8.8.7) id VAA02498; Mon, 22 Dec 1997 21:33:52 -0500 (EST) (envelope-from luoqi) Date: Mon, 22 Dec 1997 21:33:52 -0500 (EST) From: Luoqi Chen Message-Id: <199712230233.VAA02498@watermarkgroup.com> To: dima@tejblum.dnttm.rssi.ru Subject: Re: msdosfs win95 long file name support Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > 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. > ^^^^^^^^^ > You mean "old NetBSD code"? :) I suppose so. I wish I could have access to their cvs tree to find why they changed that. > > This results in extra pcbmap() calls in subsequent vnops (this problem is > > somewhat alleviated by the usage of fat cache, though). > > Hmm. I see, you store begin and end cluster of dir entry in denode. Don't you > assume that dir entry can only be in 2 clusters, by a chance? Probably, very > long names cannot happen, but it wouldn't look as a good design. That actually is the assumption. Longest file name is 255 characters, occupies about 20 blocks. Each block is 32 bytes, that gives us 640 bytes. Are clusters always greater than or equal to two sectors? Hmm, this is not a valid assumption. Just checked my floppy, it has one-sector clusters. :( Maybe it is not a very good design. I'll give it a little more thought. Thanks for pointing it out. -lq