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

[Ben H. <bj...@ca...>]

On Fri, 9 Mar 2007, Stelian Pop wrote:

> Le jeudi 08 mars 2007 à 16:31 +0000, Ben Harris a écrit :
> > On Wed, 7 Feb 2007, Peter Münster wrote:
> > 
> > > I think, it's expected, since you use dump on an active file-system.
> > 
> > So it would appear.  It looks like dump actually calls BLKFLSBUF itself, 
> > so the problem only occurs when dump isn't running as root.
> 
> 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().

> > > How to deal with it:
> > > - you can mount the file-system read-only during the dump
> > 
> > This doesn't help.  Without the BLKFLSBUF, the dump is still inconsistent.
> 
> 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:

i=0
while sleep 1; do
  echo $$.$i > testfile.$$.$i
  mount -o remount,ro /dev/stuff/test1 /mnt
  su -c "/sbin/dump -0f - . 2>/dev/null | /sbin/restore -Cf -" dump
  mount -o remount,rw /dev/stuff/test1 /mnt
  i=$(($i + 1))
done

I get results like this:

Dump   date: Fri Mar  9 16:31:53 2007
Dumped from: the epoch
Level 0 dump of /mnt on wraith:/dev/mapper/stuff-test1
Label: none
filesys = /mnt
expected next file 32769, got 460
expected next file 32769, got 461
expected next file 32769, got 462
Some files were modified!

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.

-- 
Ben Harris, University of Cambridge Computing Service.  Tel: (01223) 334728