kern/85503: panic: wrong dirclust using msdosfs in RELENG_6

[Poul-Henning Kamp]

In message <20050904065305.T2366 at 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 at 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.