Date: Fri, 02 Sep 2005 12:37:54 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> 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: <35184.1125657474@phk.freebsd.dk> In-Reply-To: Your message of "Thu, 01 Sep 2005 11:56:06 %2B0300." <20050901113819.F95708@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050901113819.F95708@atlantis.atlantis.dp.ua>, Dmitry Pryanishniko v writes: > >Hello! > > During the hunting the bug kern/85503 (panic: wrong dirclust in msdosfs) >I've tried to think about the solution, but it seems to be >architecture-related. The problem is: msdosfs uses pseudo-inodes (that is, >the offset from the start of the partition to the start of directory entry >in bytes) which must therefore have off_t bitness (at least 64 bits). I've >found the primary error (lack of casts leaded to 32-bit result), but then >we should transfer this 64-bit "inode" number to vfs_hash_get(). Oops, >it also limited to u_int (32 bits on i386). Finally, I see that the >primary shortcoming here: in sys/vnode.h we have 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?35184.1125657474>