From owner-cvs-all@FreeBSD.ORG Thu Sep 8 07:06:27 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09E5216A41F; Thu, 8 Sep 2005 07:06:27 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E74943D46; Thu, 8 Sep 2005 07:06:25 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id j8876EWn030225; Thu, 8 Sep 2005 10:06:14 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Thu, 8 Sep 2005 10:06:14 +0300 (EEST) From: Dmitry Pryanishnikov To: Mike Silbersack Message-ID: <20050908094705.R19771@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/msdosfs msdosfs_denode.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 07:06:27 -0000 Hello! > Date: Wed, 7 Sep 2005 12:24:30 -0500 (CDT) > From: Mike Silbersack > > 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 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