Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: minor bug in dump, can cause system to hang.
Message-ID: <1781@umcp-cs.UUCP>
Date: Tue, 8-Oct-85 04:41:25 EDT
Article-I.D.: umcp-cs.1781
Posted: Tue Oct  8 04:41:25 1985
Date-Received: Thu, 10-Oct-85 06:02:36 EDT
References: <1763@brl-tgr.ARPA> <14694@onfcanim.UUCP> <2856@sun.uucp>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 27

In article <2856@sun.uucp> shannon@sun.uucp (Bill Shannon) writes:
>> In article <1763@brl-tgr.ARPA> davet@RAND-UNIX.ARPA (Dave Truesdell) writes:
>>
>> But why fix dump when the problem is almost certainly in the disk driver?
>
> Because: [... the manuals] strongly suggest that you do reads in multiples
> of 512 (== DEV_BSIZE) when reading the raw device [; and]  Not all disk
> controllers on all machines are capable of reading partial sectors.

This is, I must admit, a good point.  However. . . .

> The bug is in dump, and should be fixed there.

Actually, the bug is once again in the kernel.  Dump should perhaps
be more careful in its assumption that directory sizes are always
correct; but directories are always supposed to be an exact multiple
of DEV_BSIZE.  The 4.2BSD mkdir system call wrote out `dirtemplate'
without first padding it out, giving 24 byte directories, which on
occasion would remain 24+k*512 bytes (usually the 24+ disappears
after the first file creation).

The 4.3BSD kernel has this fixed (and the 4.3 `fsck' adjusts
directory sizes upward as necessary to fix the 24+ problem).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu