Date: Wed, 6 May 1998 02:33:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@sdf.com (Tom) Cc: tlambert@primenet.com, beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <199805060233.TAA26505@usr02.primenet.com> In-Reply-To: <Pine.BSF.3.95q.980505180708.23727A-100000@misery.sdf.com> from "Tom" at May 5, 98 06:16:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> dump/restore does not work on my 32GB filesystem. Why? Possibly a 4+GB
> bug, though somone has speculated that it is sparse file problem. What
> happens? dump generates a corrupted archive (bug), and restore detects
> the corruption and crashes anyway (another bug). There has been
> an outstanding PR on this for a long time.
There is no "4G problem". If there is a problem based on type size,
it will occur at 2G + 1, *not* 4G.
The "long" type is a 32 bit signed value, meaning 31 bits of data
and the sign bit, meaning 2G.
The "long long" type is a 64 bit signed value, meaning 63 bits of
data and the sign bit, meaning 2G * 4G.
If a "long" type is used to represent block offests instead of byte
offsets, then the problem, if existant, will occur at 2^31 * 512 = 1T.
If the "long long" type is used to represent block offsets instead of
byte offset, then the problem, if existant, will occur at 512 * 2G * 4G,
otherwise known as "more disk than you have".
Now you are claiming the problem occurs in dump instead of restore.
If the problem has anything to do with sparse files (which it doesn't),
you will be able to repeat it by creating a file, writing some small
number of blocks up front, and then seeking out to:
off_t off = 1 << 34;
And writing some more blocks, then dumping the FS containing the file.
You could fit this file on a floppy disk, since it's sparse, and make
the test case teeny.
Having run this experiment the other night with my QIC SCSI 2525
drive, I can tell you that the problem is not in dump or restore,
unless it's a byte/block offfset problem.
If you are seeing a byte/block offset problem, it's not going to be
occurring where ou are saying you are seeing the problem ("4G"), it's
going to occur at one of the boundry conditions I identified, above.
If you are seeing a problem where you said you are seeing the problem,
then it is the driver/controller/tape drive/tape that is causing it.
What version of FreeBSD are you running?
What is the controller for the tape drive?
Which driver is responsible for that controller?
What exact model of tape drive are you using?
What exact brand of tapes are you using?
What is the controller for the disk showing the problem?
What driver is responsible for that controller?
What exact model of disk drive are you using?
Are you overclocking your processor?
> While browsing the PR database, I found that dump/restore does not
> always save/restore the new 4.4 attributes.
I haven't seen this. The inode data is stored as a 128 byte image
of the disk contents, with the block offsets restored relative to
the new block allocation.
An image either is, or it isn't.
Are you sure the bug reporter was not using group permissions
to access devices? He will not be able to restore attributes
accessible only to root unless he is root.
Likewise, the secure level will affect the ability of the user to
perform certain flags related operations.
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?199805060233.TAA26505>