Date: Tue, 23 Jul 2002 21:57:00 -0400 From: "Mark W. Krentel" <krentel@dreamscape.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 4.6-RC: Glacial speed of dump backups Message-ID: <200207240157.g6O1v0534203@dreamscape.com>
next in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> If the filesystem is idle you'll be O.K. w/FreeBSD. I do not
> know of any issues with Linux that make it any different from
> FreeBSD. If you sync a couple of times dumping an idle filesystem
> under Linux ought to work just about the same as dumping an
> idle filesystem under FreeBSD.
The following sequence produces the problem for me in Red Hat 7.1.
You'll need a spare disk with a couple of unused partitions and mount
points for them. Let's say /one and /two.
mke2fs /dev/hdc1
mount /dev/hdc1 /one
cd /one
echo "the original append-me file" >append-me
echo "the original vi-me file" >vi-me
dump -0 -u -a -f /tmp/one.0 /dev/hdc1
echo "more stuff in append-me" >>append-me
vi vi-me
dump -4 -u -a -f /tmp/one.4 /dev/hdc1
mke2fs /dev/hdc2
mount /dev/hdc2 /two
cd /two
restore -r -f /tmp/one.0
restore -r -f /tmp/one.4
The vi-me file is copied correctly, but append-me is not. append-me
on /two has the same length as on /one, but the second line is
replaced with nulls.
# ls -l /one/append-me /two/append-me
-rw-r--r-- 1 root root 52 Jul 5 01:19 /one/append-me
-rw-r--r-- 1 root root 52 Jul 5 01:19 /two/append-me
# cat /one/append-me
the original append-me file
more stuff in append-me
# od -c /two/append-me
0000000 t h e o r i g i n a l a p p
0000020 e n d - m e f i l e \n \0 \0 \0 \0
0000040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000060 \0 \0 \0 \0
0000064
You can tell it's a cache flush problem. Unmounting and remounting
/one before the second dump fixes the problem. It also works to
unpack a large tar file before dumping. Waiting a few hours and
running a bazillion syncs doesn't help. And strangely, it's files
written without O_TRUNC that are copied incorrectly.
I asked about this on dump-users on SourceForge and Stelian Pop (the
ext2 dump maintainer) replied:
> And the inconsistency is normal, because both dump and the kernel
> accesses the raw disk structures directly, without synchronisation.
>
> This is a known problem, due to dump's design, which was no never
> run dump on mounted filesystems. Unless you either umount the
> filesystem first or use some kind of filesystem snapshots (LVM etc),
> you cannot guarantee that your files were in a consistent state.
> That's why you should check your backup with restore -C each time.
Anyway, my Freebsd question is answered and we're getting off-topic.
But if you ever figure out what's going on with Linux here and why
Freebsd is different, I'd be very interested to hear what it is.
--Mark
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207240157.g6O1v0534203>