Date: Thu, 8 Sep 2005 10:06:14 +0300 (EEST) From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> To: Mike Silbersack <silby@silby.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/msdosfs msdosfs_denode.c Message-ID: <20050908094705.R19771@atlantis.atlantis.dp.ua>
next in thread | raw e-mail | index | archive | help
Hello! > Date: Wed, 7 Sep 2005 12:24:30 -0500 (CDT) > From: Mike Silbersack <silby@silby.com> > > Heh, I was going to request a regression test, but I guess a 24 gig swap > backed partition would be a bit difficult to create. :) >> PR: 85503 >> Submitted by: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> I've thought about it too ;) Actually, to trigger this error one should have little more than 4Gb device, but carefully placed directory on it ;) If we have 2 files, which directory entries begin at byte offsets from the start of the media with identical low-order 32 bits; e.g., 64-bit offsets 0x0000000000001000 and 0x0000000100001000 and we've enough memory to hold first directory entry in the vfs cache while looking up the second, then this bug will manifest itself. So if somebody knows the tools with which this situation could be created (or enough time and inspiration to create it manually with some kind of binary data editor), it would be possible to keep this disk image as a regression test for this particular bug (it could be compressed just fine ;). It's just very probable that on large filesystems (as my 24Gb) with many files and reach directory tree (yes, yes, WinXP lives there ;) + a lot of free memory for vfs cache (my machine has 512Mb) that this situation will happen "automagically"... Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050908094705.R19771>