Re: [Dump-users] Corruption of recently-modified file contents

[Stelian P. <st...@po...>]

Le vendredi 09 mars 2007 à 17:19 +0000, Ben Harris a écrit :

> > Dump does anyway need to have enough priviledges to access the raw block
> > device directly, and I would have expected BLKFLSBUF to work in these
> > conditions.
> 
> It doesn't.  BLKFLSBUF requires CAP_SYS_ADMIN, which isn't required just 
> to open the device for reading.  See linux/block/ioctl.c::blkdev_ioctl().

Right. Unfortunate but correct.

> > 
> > How can this be ? The remount process explicitely flushes the data to
> > the disk, and in R/O mode no further modifications are allowed.
> 
> Actually, I was mistaken -- using a r/o mount gives me a different failure 
> mode.  Using this test script:
[...]
> Each loop adds another unexpected file to the list, and running blockdev 
> --flushbufs wipes the list out.  If I actually restore the dump, the new 
> files are missing from it.

You're correct, I reproduced this here using a simple - and small - loop
mounted filesystem. I never saw this before because I always do the
dumps as root - so BLKFLSBUF works.

However, I am not sure if this is the intented behaviour ("mounting r/o
means all further writings are disallowed, but you still need to
manually flush the buffers if you want to make sure the data reached the
disk" or a genuine bug in the kernel block layer.

Stelian.
-- 
Stelian Pop <st...@po...>