Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ulysses.UUCP
Path: utzoo!linus!decvax!harpo!floyd!clyde!burl!hou3c!hocda!houxm!ihnp4!ulysses!smb
From: smb@ulysses.UUCP (Steven Bellovin)
Newsgroups: net.bugs.4bsd
Subject: Re: 4.2BSD installation mystery ...
Message-ID: <726@ulysses.UUCP>
Date: Sun, 4-Dec-83 19:59:55 EST
Article-I.D.: ulysses.726
Posted: Sun Dec  4 19:59:55 1983
Date-Received: Mon, 5-Dec-83 23:03:17 EST
References: <184@rna.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 48

I've seen a similar problem, and I believe it to be a bug in the kernel
and/or fsck.  In my case, the block number that fsck couldn't read was
291344.  By a curious non-coincidence, the slice in question (the
'h' slice on an RM05) has 291346 blocks.  Thus, there are only 2 blocks
available before the end of the file system, and an attempt to read
a full block will fail.  Worse yet, it will behave differently with
the cooked and raw devices.  Try this program -- on the cooked device,
*all three* reads fail, even though the first two should work!  On the
raw device, the first two work (512 and 1024 bytes), but the third fails.
My own opinion is that the third read (of 4096 bytes) should return a short
block.
--------------------
#include <ctype.h>
extern int errno;

main(argc, argv) int argc; char *argv[];
{
	extern long lseek();
	char buf[4096]; int i, fd;

	chdir("/dev");
	fd = open (argv[1], 0);
	if (fd < 0) {
		perror("open");
		exit(1);
	}

	if (lseek(fd, 291344L*512L, 0) < 0) {
		perror("lseek 1");
		exit(1);
	}
	i = read(fd, buf, 512);
	printf("512 %d %d\n", i, errno);

	if (lseek(fd, 291344L*512, 0) < 0) {
		perror("lseek 2");
		exit(1);
	}
	i = read(fd, buf, 1024);
	printf("1024 %d %d\n", i, errno);

	if (lseek(fd, 291344L*512L, 0) < 0) {
		perror("lseek 3");
		exit(1);
	}
	i = read(fd, buf, 4096);
	printf("4096 %d %d\n", i, errno);
}