From owner-freebsd-fs@FreeBSD.ORG Wed Jun 8 14:11:34 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E894116A41C for ; Wed, 8 Jun 2005 14:11:33 +0000 (GMT) (envelope-from ut@bhi-hamburg.de) Received: from mail.terralink.de (mail.tlink.de [217.9.16.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CD9543D1D for ; Wed, 8 Jun 2005 14:11:32 +0000 (GMT) (envelope-from ut@bhi-hamburg.de) Received: from schweinkram.pleach-hamburg.de (p548EB77D.dip.t-dialin.net [84.142.183.125]) by mail.terralink.de (Postfix) with ESMTP id 4BAC8B8A1 for ; Wed, 8 Jun 2005 16:11:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by schweinkram.pleach-hamburg.de (Postfix) with ESMTP id AF77F6A89EB; Wed, 8 Jun 2005 16:03:54 +0200 (CEST) Received: from by localhost (amavisd-new, port ) id nED73pk2; Wed, 8 Jun 2005 16:03:53 +0200 (CEST) Received: by schweinkram.pleach-hamburg.de (Postfix, from userid 65534) id 1D0446A89C5; Wed, 8 Jun 2005 16:03:53 +0200 (CEST) Received: from titusn (titusn.pleach-hamburg.de [192.168.1.19]) by schweinkram.pleach-hamburg.de (Postfix) with SMTP id AB4656A5B58; Wed, 8 Jun 2005 16:03:49 +0200 (CEST) From: "Titus von Boxberg" To: Date: Wed, 8 Jun 2005 16:06:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on schweinkram.pleach-hamburg.de X-Spam-Status: No, hits=1.6 required=5.0 tests=BAYES_60 autolearn=no version=2.60 X-Spam-Level: * X-Virus-Scanned: by amavisd-new at pleach-hamburg.de Subject: Again: Inconsistent snapshot contents X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 14:11:34 -0000 Hi, I sent a mail about inconsistent snapshot contents a week ago but did not get a response yet. Please notify me at least if this is the wrong mailing list for these questions. This is the abstract: On two servers (5.2.1-RELEASE and 5.3-RELEASE) we use the following backup script: #!/bin sh # .... mksnap_ffs / /.snap/backupsnap mdconfig -a -t vnode -f /.snap/backupsnap -u 5 mount -o ro /dev/md5 /mnt cd /mnt cp fileinquestion /tmp/x1 # see below tar cf /dev/sa0 .... cp fileinquestion /tmp/x2 # see below tar df /dev/sa0 if [ $? -eq 1 ] ; then # see below tar -C /tmp -xf /dev/sa0 fileinquestion mv /tmp/fileinquestion /tmp/x3 fi # .... ASSUMPTIONS: I cannot see anything wrong with the script or the underlying assumptions (snapshots are COMPLETE consistent views of the state of the file system at a certain instant). I think it's highly unlikely that the tar command(s) are able to alter the read only mounted snapshot. STATISTICS: The verify tar almost always complains that at least one (and always the same) file(s) is/are differing. I tracked the file contents of one file that the verify tar usually complains about and could see that its contents ON THE SNAPSHOT (but NOT its size) frequently differ over time. The contents at least of this file in question are modified every minute or so OUTSIDE (of course) the snapshot. It does not have anything to do with the tape. The problem also occurs when tarring onto or from a disk file on a holding disk. I'm also quite sure that this problem is NOT reproducible if the backup process (tar) is not run. It is not sufficient to create the snapshot and compare over time ***without also starting the backup command***. The hardware configs of both servers are quite different (AthlonXP2800/512/ATA60GB vs. Celeron600/256/ATARAID 80GB). CONCLUSION 1 --> I'm quite sure now that the contents of the snapshot may be inconsistent over time. CONCLUSION 2 --> There is some bug in the kernel maybe related to a side effect that occurs somehow when the tar commands are run AND snapshotted files change (outside the snapshot) in a certain manner (by content but apparently NOT in size). QUESTIONS: Is something wrong with the ASSUMPTIONS above? Have I overlooked some bugfix between 5.3-RELEASE and 5-STABLE? Is this the wrong mailing list? Should I post this question / problem to some other list? Which list? My FreeBSD kernel specific skills are currently restricted to writing device drivers, but I'm willing and able to help by coding and installing or using any hook or debugging routine into the ufs kernel code if someone could point me to the right place. This would be the optimum answer on this mail. Thanks in advance. Titus