From owner-freebsd-hackers  Tue May  5 00:53:18 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA16190
          for freebsd-hackers-outgoing; Tue, 5 May 1998 00:53:18 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16183
          for <freebsd-hackers@freebsd.org>; Tue, 5 May 1998 00:53:13 -0700 (PDT)
          (envelope-from tlambert@usr02.primenet.com)
Received: (from daemon@localhost)
	by smtp02.primenet.com (8.8.8/8.8.8) id AAA17715;
	Tue, 5 May 1998 00:53:14 -0700 (MST)
Received: from usr02.primenet.com(206.165.6.202)
 via SMTP by smtp02.primenet.com, id smtpd017705; Tue May  5 00:53:10 1998
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id AAA17757;
	Tue, 5 May 1998 00:53:07 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199805050753.AAA17757@usr02.primenet.com>
Subject: Re: Network problem with 2.2.6-STABLE
To: tom@sdf.com (Tom)
Date: Tue, 5 May 1998 07:53:07 +0000 (GMT)
Cc: beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <Pine.BSF.3.95q.980503224157.16746A-100000@misery.sdf.com> from "Tom" at May 3, 98 10:51:01 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>   Really?  Since dump/restore requires direct knowledge of filesystem
> internals, it should probably be dropped for being a gross layering
> violation alone.  Assuming it can even capture a consistant view of an
> active filesystem (I doubt it myself).  dump/restore's idea of raw
> filesystem access was a mistake.

1)	You are not supposed to use it on mounted FS's.

2)	By that reasoning, we should get rid of fsck.

>   But dump/restore has been broken forever.  I hope that you don't have
> any 4+GB filesystems that you are dumping, because you will get a nasty
> surprise trying to restore it.

The dump format would have to change to be 64 bits (or more).

The fix is probably:

	struct statfs	fssb;
	off_t		tot;

	if( statfs( path, &fssb)) {
		perror( "statfs");
		exit( EX_SOFTWARE);
	}

	tot = fssb.f_bsize;
	tot *= f_blocks;

	if( tot & 0xffffffff00000000LL) {
		fprintf( stderr, "fs is too large for dump\n");
		exit( EX_DATAERR);
	}

Meanwhile, break you FS's up; your backups will take less time, too.

					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message