Date: Tue, 5 May 1998 07:53:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@sdf.com (Tom) Cc: beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <199805050753.AAA17757@usr02.primenet.com> In-Reply-To: <Pine.BSF.3.95q.980503224157.16746A-100000@misery.sdf.com> from "Tom" at May 3, 98 10:51:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805050753.AAA17757>