Path: utzoo!attcan!uunet!mcvax!ukc!warwick!cudcv
From: cudcv@warwick.ac.uk (Rob McMahon)
Newsgroups: comp.bugs.4bsd
Subject: Re: 4.3 Tahoe dump bug
Keywords: dump bug
Message-ID: <69@titania.warwick.ac.uk>
Date: 20 Dec 88 11:06:08 GMT
References: <23685@pprg.unm.edu> <23642@cornell.UUCP>
Reply-To: cudcv@warwick.ac.uk (Rob McMahon)
Organization: Computing Services, Warwick University, UK
Lines: 40

In article <23642@cornell.UUCP> parmelee@wayback.cs.cornell.edu (Larry Parmelee) writes:
>In article <23685@pprg.unm.edu> cyrus@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@uk.ac.warwick             ARPA:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England