Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Mar 2004 05:00:32 -0800 (PST) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2PD0RKO026122 for ; Thu, 25 Mar 2004 05:00:28 -0800 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i2PD0MId022617; Thu, 25 Mar 2004 14:00:22 +0100 Message-ID: <4062D7E5.6070501@stesmi.com> Date: Thu, 25 Mar 2004 14:00:21 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: "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> In-Reply-To: <20040325124152.GA12078@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2588 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: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1356 Lines: 39 Hi. >>Firstly anaconda executes "grub-install --just-copy", and executes >>sync() three times. > > grub is braindead then. Calling sync() once should suffice. Grub does it as a workaround. >>Then anaconda runs "grub --batch" to really install grub into MBR of >>the disk, but grub cannot find files which should have been already >>written in the partition by sync(). > > That sounds like something else. sync() ensures dirty buffers are > on-disk. Even if you don't sync() you can still read-back using the > buffer-cache/page-cache. Or.. Should. >>When I put 1 minutes of sleep() next to sync(), grub finds those >>files and is installed successfully. > > I'm not sure I follow, but I'n not convinced it's XFS failing to > sync() to disk unless it's a really old tree. Happens with current tree I can tell you that me and .. Steve I think discussed it on IRC a while back and he looked into the POSIX spec and according to POSIX a filesystem does not have to keep the block device the same as the filesystem after a sync() (or mounting SYNC). In the case of XFS it _should_ but doesn't but it's not violating any specs. And Grub relies on the filesystem keeping the block device in sync with the filesystem after a sync() call. That's a bug in both Grub and XFS but XFS isn't the one violating the spec, even though it's a bug. // Stefan