From owner-freebsd-stable Tue Jul 23 18:57:48 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAF8C37B400 for ; Tue, 23 Jul 2002 18:57:45 -0700 (PDT) Received: from mail2.dreamscape.com (mail2.dreamscape.com [206.64.128.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27B5443E42 for ; Tue, 23 Jul 2002 18:57:45 -0700 (PDT) (envelope-from krentel@dreamscape.com) Received: from dreamscape.com (sa3-p12.dreamscape.com [207.198.19.76]) by mail2.dreamscape.com (8.9.3+blt/8.9.3) with ESMTP id VAA00370; Tue, 23 Jul 2002 21:57:37 -0400 (EDT) Received: from blue.mwk.domain (localhost [127.0.0.1]) by dreamscape.com (8.11.1/8.11.1) with ESMTP id g6O1v0534203; Tue, 23 Jul 2002 21:57:01 -0400 (EDT) (envelope-from krentel@blue.mwk.domain) Message-Id: <200207240157.g6O1v0534203@dreamscape.com> To: Matthew Dillon Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 4.6-RC: Glacial speed of dump backups Date: Tue, 23 Jul 2002 21:57:00 -0400 From: "Mark W. Krentel" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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