Re: how to sync / commit data to disk?

Re: how to sync / commit data to disk?

[James Pearson]

>> grub is broken
>> 
>> this comes up all the time, there are various work-arounds but it
>> doesn't change the fact that GRUB IS BROKEN
>> 
>> it would be nice if someone would just address it from that end
>> 
>> > xfs_freeze -f
>> > sync
>> > xfs_freeze -u
>> 
>> sync before freeze (actually, I'm not sure a sync there is necessary
>> but it can't hurt)
> 
> Its not necessary (would be a bug if so).
> 
> FWIW, this hack can be better achieved in a filesystem independent way
> by doing a remount,ro ... remount,rw instead of freeze/thaw.

This is the way that I do it - based on info in an earlier posting on 
this list:

<http://marc.theaimsgroup.com/?l=linux-xfs&m=112096901910385&w=2>

James Pearson

how to sync / commit data to disk?

[Peter Gervai]

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

but I give a large chance to be wrong about it.

Ideas?

Please cc on me if possible. Thanks.

-- 
 byte-byte,
    grin

Re: how to sync / commit data to disk?

[Geir A. Myrestrand]

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
> 
> but I give a large chance to be wrong about it.
> 
> Ideas?
> 
> Please cc on me if possible. Thanks.

Call the sync before you freeze the file system, not after. You can't 
write to the file system when it is frozen, so it makes no sense to call 
sync after a freeze.

I don't think you have any control of whether the data is written 
physically to the disk or is still in the disk(s) buffer, the buffer you 
can flush is on the software side. Call sync and freeze.

-- 

Geir A. Myrestrand

Re: how to sync / commit data to disk?

[Eric Sandeen]

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

Re: how to sync / commit data to disk?

[Peter Gervai]

Thanks for the very informative replies!

I try to address some questions, and maybe ask some more.

The original question was:
> > What is the recommended way to make sure that a file is written
> > physically to the disk? (apart from the cache of the disk.)

On 1/23/07, Eric Sandeen <sandeen@sandeen.net> wrote:

> 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.

It does not seem to do evil in this case:

3243  open("//boot/grub/stage2", O_RDWR) = 5
3243  fstat64(0x5, 0xf7c2e9f4)          = 0
3243  mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7bc4000
3243  _llseek(5, 0, [0], SEEK_SET)      = 0
3243  read(5, "RV\276\3\201\350(\1^\277\370\201f\213-\203}\4\0\17\204\312\0\200|\377\0t>f\213\35f1\300\260\1779E\4\177\3\213E\4)E\4f\1\5\307\4\20\0\211D\2f\211\
\\10\307D\6\0pPf1\300\211D\4f\211D\f\264B\315\23\17\202\237\0\273\0p\353Vf\213\5f1\322f\3674\210T\nf1"...,
512) = 512
3243  write(5, "\352p\202\0\0\0\3\2\377\377\377\0\0\0\0\0\0\0000.97\0/boot/grub/menu.lst\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3721\300\216\330\216\320\216\300g"...,
512) = 512
3243  close(5)                          = 0

Now, for me it seems to be a very interesting question that why people
would CARE whether it's synced or not, since they write it by the
filesystem layer anyway? I do not know, and investigating the reason
why 'grub-install' would worry about sync is beyond my available time.

The original problem was because grub-install froze xfs, then tried to
do the above, which magically fail on the frozen filesystem, hanging
the install till the cows come home. I tried to fix this, then started
wondering how to do it properly, and now that you mentioned and I
checked the trace I really start wondering about why to care... :-o


Then Chris Wedgwood <cw@f00f.org> said:
> GRUB IS BROKEN

Apart from that it is so far he best boot manager I found (still I'm
open to suggestions of better, free boot managers, but please not on
this list), which is completely based on my extremely subjective point
of view (which includes XFS support, naturally), and which may be
completely opposite to the point of view of any human or nonhuman
being, it is not, as you have seen above. It uses a dirty hack which
works, I accept that. Specifying --stage2 seems to avoid that hack
altogether anyway.

> wrt to grub, i thought it did this for xfs anyhow?
I accept the "BROKEN" comment regarding this one. ;-) It is a broken
implementation. Freeze, ten tries to write. Doomed to fail.


Iustin Pop <iusty@k1024.org> commnted about:
> I usually unmount the /boot partition if I need to reinstall grub

Manually it's ok but this is about grub-install, a "vendor" provided
script which cannot assume that you have a separate boot partition.


"Geir A. Myrestrand" <geir.myrestrand@falconstor.com> added:
> Call the sync before you freeze the file system, not after. You can't
> write to the file system when it is frozen, so it makes no sense to call
> sync after a freeze.

I thought that freeze lets already written but unsynced data to be written.


It seems to me that sync before freeze seems to be a good way to make
sure things are on the disk where they gonna stay, as far as it is
possible in such a hacky case.

Thanks, and feel free to comment more, if you like.

-- 
 byte-byte,
    grin

Re: how to sync / commit data to disk?

[Eric Sandeen]

Peter Gervai wrote:
> Thanks for the very informative replies!
> 
> I try to address some questions, and maybe ask some more.
> 
> The original question was:
>> > What is the recommended way to make sure that a file is written
>> > physically to the disk? (apart from the cache of the disk.)
> 
> On 1/23/07, Eric Sandeen <sandeen@sandeen.net> wrote:
> 
>> 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.
> 
> It does not seem to do evil in this case:
> 
> 3243  open("//boot/grub/stage2", O_RDWR) = 5
> 3243  fstat64(0x5, 0xf7c2e9f4)          = 0
> 3243  mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7bc4000
> 3243  _llseek(5, 0, [0], SEEK_SET)      = 0
> 3243  read(5, 
> "RV\276\3\201\350(\1^\277\370\201f\213-\203}\4\0\17\204\312\0\200|\377\0t>f\213\35f1\300\260\1779E\4\177\3\213E\4)E\4f\1\5\307\4\20\0\211D\2f\211\ 
> 
> \\10\307D\6\0pPf1\300\211D\4f\211D\f\264B\315\23\17\202\237\0\273\0p\353Vf\213\5f1\322f\3674\210T\nf1"..., 
> 
> 512) = 512
> 3243  write(5, 
> "\352p\202\0\0\0\3\2\377\377\377\0\0\0\0\0\0\0000.97\0/boot/grub/menu.lst\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 
> 
> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3721\300\216\330\216\320\216\300g"..., 
> 
> 512) = 512
> 3243  close(5)                          = 0
> 
> Now, for me it seems to be a very interesting question that why people
> would CARE whether it's synced or not, since they write it by the
> filesystem layer anyway? I do not know, and investigating the reason
> why 'grub-install' would worry about sync is beyond my available time.
> 
> The original problem was because grub-install froze xfs, then tried to
> do the above, which magically fail on the frozen filesystem, hanging
> the install till the cows come home. I tried to fix this, then started
> wondering how to do it properly, and now that you mentioned and I
> checked the trace I really start wondering about why to care... :-o

The other thing I've seen grub do is to go ahead & write nicely through 
the filesystem, then do a verification step of trying to go read 
directly from the block device while the filesystem is still mounted.

Again, not treating the filesystem well; until you unmount the fs 
there's not a lot to guarantee that all your data is where you expect it 
on disk (especially w/ a journalling fs, where metadata in the journal 
is really enough for safety, even if its not in its final disk location 
- and of course grub doesn't replay the journal....)

When I saw it hanging, I saw it hanging in this verification step, for 
the above reasons.  it wandered into unwritten metadata blocks. 
Skipping that verification  step would probably be a better idea, it's 
causing many more problems than it's likely to catch (unless you can 
unmount or otherwise quiesce the filesystem first...)

-Eric

Re: how to sync / commit data to disk?

[Chris Wedgwood]

On Tue, Jan 23, 2007 at 09:33:01PM +0100, Peter Gervai wrote:

> Now, for me it seems to be a very interesting question that why
> people would CARE whether it's synced or not, since they write it by
> the filesystem layer anyway? I do not know, and investigating the
> reason why 'grub-install' would worry about sync is beyond my
> available time.

there was/is a case where grub assumes a sync will put the file in
it's fine place, it then pokes about using it's own fs code talking to
the block device --- and that's where it breaks

the reason is sync/fsync have to put the data down somewhere that's
not volatile, that isn't going to get lost --- the specification
doesn't require those system calls should put the data down in their
final place or indeed put the filesystem in a state where it's safe to
poke about under a mounted filesystem (though freeze essentialyl does
that)

> The original problem was because grub-install froze xfs, then tried
> to do the above, which magically fail on the frozen filesystem,
> hanging the install till the cows come home. I tried to fix this,
> then started wondering how to do it properly, and now that you
> mentioned and I checked the trace I really start wondering about why
> to care... :-o

i guess it wouldn't be hard to add an freeze/unfreeze hacky thing to
use as a super-duper-sync to allow people to do nasty things, i'm not
sure if that's really a good idea long term though

> Apart from that it is so far he best boot manager I found (still I'm
> open to suggestions of better, free boot managers, but please not on
> this list), which is completely based on my extremely subjective
> point of view (which includes XFS support, naturally), and which may
> be completely opposite to the point of view of any human or nonhuman
> being, it is not, as you have seen above. It uses a dirty hack which
> works, I accept that. Specifying --stage2 seems to avoid that hack
> altogether anyway.

to be quite honest, almost all the bootloaders suck in one way or
another, you're just best off picking whatever has the least pain and
living with it (arguably this applies to most software in general but
boot-loaders are most definately nasty in places)

> I accept the "BROKEN" comment regarding this one. ;-) It is a broken
> implementation. Freeze, ten tries to write. Doomed to fail.

right, so freeze/unfreeze in one call might be a better idea so there
is no chance of having it stuck frozen and breaking things

> I thought that freeze lets already written but unsynced data to be
> written.

freeze should push all unwritten data and metadata out to the fs and
leave it in a decent state suitable for taking a snapshot,
freeze/unfreeze in one go won't really do this, but it might be good
enough for grub

Re: how to sync / commit data to disk?

[Chris Wedgwood]

On Tue, Jan 23, 2007 at 04:16:59PM +0100, Peter Gervai wrote:

> 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.

grub is broken

this comes up all the time, there are various work-arounds but it
doesn't change the fact that GRUB IS BROKEN

it would be nice if someone would just address it from that end

> xfs_freeze -f
> sync
> xfs_freeze -u

sync before freeze (actually, I'm not sure a sync there is necessary
but it can't hurt)

wrt to grub, i thought it did this for xfs anyhow?

i suggested doing this a couple of years back and i thought that was
what it was doing now in some versions of grub (afaik vendors like red
hat never took that change, the last conversation i had about this
ended up being an argument about whether fsync should place the data
in it's final location on disk or not (nothing in the specs says it
should) so i gave up and dropped the issue)

Re: how to sync / commit data to disk?

[Nathan Scott]

On Tue, 2007-01-23 at 08:50 -0800, Chris Wedgwood wrote:
> On Tue, Jan 23, 2007 at 04:16:59PM +0100, Peter Gervai wrote:
> 
> > 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.
> 
> grub is broken
> 
> this comes up all the time, there are various work-arounds but it
> doesn't change the fact that GRUB IS BROKEN
> 
> it would be nice if someone would just address it from that end
> 
> > xfs_freeze -f
> > sync
> > xfs_freeze -u
> 
> sync before freeze (actually, I'm not sure a sync there is necessary
> but it can't hurt)

Its not necessary (would be a bug if so).

FWIW, this hack can be better achieved in a filesystem independent way
by doing a remount,ro ... remount,rw instead of freeze/thaw.

cheers.

-- 
Nathan

Re: how to sync / commit data to disk?

[Chris Wedgwood]

On Wed, Jan 24, 2007 at 09:24:29AM +1100, Nathan Scott wrote:

> FWIW, this hack can be better achieved in a filesystem independent
> way by doing a remount,ro ... remount,rw instead of freeze/thaw.

except it won't work if the are open read-write files (which can be
the case)

Re: how to sync / commit data to disk?

[Iustin Pop]

On Tue, Jan 23, 2007 at 04:16:59PM +0100, Peter Gervai wrote:
> My educated guess would be
> xfs_freeze -f
> sync
> xfs_freeze -u
> 
> but I give a large chance to be wrong about it.
> 
> Ideas?

I usually unmount the /boot partition if I need to reinstall grub (which
is a rare event). Since nowadays klogd doesn't keep /boot/System.map
open anymore, there is no reason not to do an umount/grub install/mount
sequence.

Iustin