Date: Sat, 03 Sep 2005 23:17:40 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>, freebsd-arch@FreeBSD.org Subject: Re: kern/85503: panic: wrong dirclust using msdosfs in RELENG_6 Message-ID: <44604.1125782260@phk.freebsd.dk> In-Reply-To: Your message of "Sun, 04 Sep 2005 07:13:58 %2B1000." <20050904065305.T2366@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050904065305.T2366@epsplex.bde.org>, Bruce Evans writes: >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 :-). Uhm, did none of you guys see my email about how this must be done correctly the say way NFS does it correctly ? To repeat: NFS has the same sort of problem, it has 16 or 32 *bytes* filehandles that need to hash to 32 bit "inode numbers". If you look at vfs_hash_get calls in sys/nfsclient you can see that it calculates a 32bit hash but then provides a "nfs_vncmpf" function to do the actual comparison to resolve hash collisions. You need to do the same thing. Making the hashes be 64bit is pointless since no filesystems will have that many inodes and it still doesn't solve the problem properly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44604.1125782260>