4.3 Tahoe dump bug
Rob McMahon
cudcv at warwick.ac.uk
Tue Dec 20 21:06:08 AEST 1988
In article <23642 at cornell.UUCP> parmelee at wayback.cs.cornell.edu (Larry Parmelee) writes:
>In article <23685 at pprg.unm.edu> cyrus at pprg.unm.edu (Tait Cyrus) writes:
>> trying to get the 4.3 Tahoe dump running on a Sun 3 running SunOS 3.X, I
>> ... have run into the following bug (feature) (shown below).
>
>> > DUMP: mapping (Pass II) [directories]
>> > DUMP: (This should not happen)bread from /dev/rxy1g [block 58766]: count=24, got=512
>> > DUMP: (This should not happen)bread from /dev/rxy1g [block 60802]: count=536, got=1024
>
>Under 4.2 (on which Sun 3.x is based) directories were allowed to be any old
>size, whatever was convienient. Under 4.3, as an efficiency hack,
>directories were forced to be multiples of 512 bytes.
I believe this was actually a bug in 4.2. When directories first got created
they were created short (24 bytes). After adding the first file they were
extended to 512 bytes, and thereafter stayed a multiple of 512. (Maybe
someone will correct me on this, my 4.2 memory is beginning to fade, and it
doesn't quite explain 536 bytes, which is suspiciously equal to 512 + 24 ...)
>The 4.3 dump expects this, and will generate errors like you're seeing when
>confronted with an old 4.2 filesystem containing random length directories.
I believe the real problem is that SunOS rounds requests for reads from a raw
device *up* to a multiple of 512 blocks. Note that dump has asked for 24
bytes but got 512. I don't know whether is actually puts all this data in
your buffer. If it does it's horrible because it could overrun a buffer,
whose size you had accurately given. If it doesn't it's horrible because it's
lying about how many bytes were read into your buffer. IMHO it should behave
like a tape drive - return the amount asked for and junk the rest of the
block. Or maybe it would be better to round down for requests greater than
the blocksize ?
>Below is my fix, in file dumptraverse.c, routine dsrch().
I believe your fix, but not your explanation.
--
UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037
JANET: cudcv at uk.ac.warwick ARPA: cudcv at warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list