Date: Sun, 4 Sep 2005 07:13:58 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Cc: freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 Message-ID: <20050904065305.T2366@epsplex.bde.org> In-Reply-To: <20050903194401.E1788@atlantis.atlantis.dp.ua> References: <20050901183311.D62325@atlantis.atlantis.dp.ua> <20050902205456.S2885@delplex.bde.org> <20050903190632.S1788@atlantis.atlantis.dp.ua> <20050903194401.E1788@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: > On Sat, 3 Sep 2005, Dmitry Pryanishnikov wrote: >>> I think I said that the inode number in msdosfs should be the cluster >>> number of the first cluster in the file. This would be broken by >>> variable-sized clusters (unlikely, and even less useful) or new file >>> types like symlinks (useful and not so unlikely -- FreeBSD could add >>> them as an extension). >> >> Yes, I agree with this. While this fs has being called FAT32, >> it's cluster number will fit in 32-bit word. > > Ups, how about empty files? They haven't any allocated clusters, have > they? So, alas, we can't go this route. Urk. It also doesn't work for cd9660. So the block number can be used at most as a hint getting a unique fake inode number, and in msdosfs file systems don't have to be much larger than 128GB to have >= 4G files -- a 128+GB file system can consist of 128GB of directories all containing empty files :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050904065305.T2366>