xfs
[Top] [All Lists]

Re: how to sync / commit data to disk?

To: Peter Gervai <grinapo@xxxxxxxxx>
Subject: Re: how to sync / commit data to disk?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 23 Jan 2007 10:08:22 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <d55656c10701230716x1ae7cf49kd8a854fd73429c4f@xxxxxxxxxxxxxx>
References: <d55656c10701230716x1ae7cf49kd8a854fd73429c4f@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.9 (X11/20061219)
Peter Gervai wrote:
> Hello,
> 
> [Tried to search archieves, found nothing, probably my keywords are bad. :-)]
> 
> What is the recommended way to make sure that a file is written
> physically to the disk? (apart from the cache of the disk.)
> 
> This problem seem to have arisen in grub bootloader under Debian linux
> (and most probably everywhere else): it must be sure that the copied
> files are there, and can be addressed by C/H/S and modified there, at
> the given sector address.
> 
> My educated guess would be
> xfs_freeze -f
> sync
> xfs_freeze -u

That's one hack that has been proposed, and may help.

Another issue that I've seen with grub is that it seems to like to write
directly to the block device WHILE THE FILESYSTEM IS MOUNTED.

This is very bad, and causes ext3 grief too.

grub seems to think that it can just call "sync" and have everything be
happy, but esp. when it's doing reads & writes via both block dev &
filesystem, stuff is so out of whack syncs won't save you.

I'm not sure how you're invoking grub, but we found that manually
specifying --stage2, i.e.

        install --stage2=/boot/grub/stage2 ...

at least caused it to leave the block device alone while the fs is
mounted, rather than trying to write the underlying bdev... that was
obvious, no?  ;-)  You could verify this by stracing your grub command,
and see what it is doing with the block device.

-Eric


<Prev in Thread] Current Thread [Next in Thread>