Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 15:03:38 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PN3RKO003171 for ; Thu, 25 Mar 2004 15:03:28 -0800 Received: (qmail 1516 invoked from network); 25 Mar 2004 23:03:27 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 25 Mar 2004 23:03:27 -0000 Message-ID: <4063650B.20600@xfs.org> Date: Thu, 25 Mar 2004 17:02:35 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: Christoph Hellwig , Chris Wedgwood , "IKARASHI, Seiichi" , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> In-Reply-To: <406361F2.6060308@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 31 Stefan Smietanowski wrote: > > Yup. That's what's happening. It first does one run with --just-copy > where it writes the files using the filesystem then reads the same > files using the blockdevice and it's own filesystem code basically. > > // Stefan > And I presume the files are missing? The bizzare part of this is that if you read the via the block device interface, you are looking at the same in memory pages which xfs uses for the metadata cache. So even if the data has not hit disk yet, things such as names in directories should be visible in the metadata cache. Inodes may be more tricky, since flushing of inodes into the metadata cache is delayed. Try this for an experiment, before the run, set /proc/sys/fs/xfs/sync_interval down to some small number like 1000, pause for a couple of seconds after calling sync, and then see if grub can see the files via the block device. This tunable controls how long xfs delays writing out inodes into the metadata cache from their internal format. Steve