dan@rna.UUCP (12/12/83)
I want to report back the answer to my question of why 4.2BSD fsck screwed up on the block device version of /dev/hp0h (/usr) on an Eagle. A number of people have been writing about the cache'ing effect of block devices versus raw device, etc., all true but totally irrelevant. ulysses!smb and perhaps a couple others pointed out that the partition size of /dev/hp0h on an Eagle (and other large disk drives) was 291346 which is not an integral multiple of the blocking size for the suggested /usr filesystem (dumb!). Code in hpstrategy() checks if the transfer would exceed the partition boundary and returns an error even if a partial transfer would have been permissible. Naturally the block device interface asks for more than there is while the raw interface asks for only what the program (fsck in this case) asks for. I haven't delved into fsck to figure out why it reports nonsense after not being able to read the last 2 sectors, but presumeably it ignores have received the error completely (which it shouldn't, it should clean up) and in any case reports a few unallocated inodes and bad link counts. YABB (Yet another Berkeley Bug), this time in the configuration and packaging. Cheers, Dan Ts'o ...cmcl2!rna!dan