[9fans] seek offset

[9fans] seek offset

[arisawa]

Hello 9fans,

Plan9 support sufficiently large file system for file server.
I guess the maximum capacity is 2TB.
On the other hand, the limit of local disk is too small today.
The limit is only 4GB. Now we will buy much larger disks.
We cannot install Plan9 to these large disk.
And what is worse, I realized today, we cannot put b.com 
to dos system in the disk over 4GB.

The above problem comes from 32bit offset of seek call.
How much work will it be required to extend the offset
to 64bit?

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] seek offset

[Russ]

I "fixed" my home Plan 9 installation not by fixing
the seek() call (which seemed to me an onerous
task), but by tweaking devata slightly.

You actually don't need the seek call to take
a 64-bit offset in order for Plan9 to accept
large disks.  devata can keep track of sectors
(512 bytes) instead of bytes, so you should be able to
handle a disk of 512*2^32 bytes = 2200 GB by making
devata's math a little more careful about not
overflowing.  You make the capacity in the Drive
struct count sectors instead of bytes, and then
you also have to mess with atapart(), which is
the tricky bit.  The relevant bits are as follows.
I would post a boddle but my copy of the driver
is in pretty embarrassing shape...

	/* 
	 * We initialize the partition table to be the last
	 * two sectors and then adjust it once we figure out which
	 * sector it actually is (see note below). 
	 * Setting up this partition first lets us 
	 * get at the last couple sectors using ataxfer without
	 * worrying about a >32bit offset on dp->p[0]
	 */
	strcpy(pp->name, "partition");
	pp->start = dp->p[0].end - 2;
	pp->end = dp->p[0].end;
	pp++;
	dp->npart = 2;

	[...]

		/*
		 *  Read second last sector from disk, null terminate.
		 *  The last sector used to hold the partition tables.
		 *  However, this sector is special on some PC's so we've
		 *  started to use the second last sector as the partition
		 *  table instead.  To avoid reconfiguring all our old systems
		 *  we still check if there is a valid partition table in
		 *  the last sector if none is found in the second last.
		 */
		skiplast = 1;
		ataxfer(dp, &dp->p[1], Cread, 0, dp->bytes, buf);
		buf[dp->bytes-1] = 0;
		n = getfields((char*)buf, line, Npart+1, "\n");
		if(n <= 0 || strncmp(line[0], PARTMAGIC, sizeof(PARTMAGIC)-1) != 0){
			ataxfer(dp, &dp->p[1], Cread, dp->bytes, dp->bytes, buf);
			buf[dp->bytes-1] = 0;
			n = getfields((char*)buf, line, Npart+1, "\n");
			if(n > 0 && strncmp(line[0], PARTMAGIC, sizeof(PARTMAGIC)-1) == 0)
				skiplast = 0;
		}

		/*
		 * Now that we know which sector holds the
		 * partition table, update the metaentry
		 */
		if(skiplast){
			dp->p[0].end--;
			dp->p[1].end--;
		}else{
			dp->p[1].start++;
		}


Similar changes apply to b.com (I think they 
were easier to apply there, if I remember right).

Without a 64-bit seek, your maximum partition
size is indeed limited to 4GB, but that's less
of a problem.

Without 64-bit stat responses from devata, disk/prep won't
work on large disks, but that's a smaller problem: at least
the support is almost all there already.

Russ

[9fans] seek offset

[jmk]

As Russ points out, fixing Plan9 and the bootstrap to deal with
discs >4GB is fairly easy, although you are still limited to a partition
size of 4GB.

The offset and return value of the seek system call in Brazil is 64-bits.
How much work it was to do is hard to gauge as it happened in a fairly
uncoordinated manner over a period of time and there are still corners to
straighten out. One thing to note is the order of the component parts of
Length in /386/include/u.h of the Plan 9 distribution is wrong...


When Presotto did the Plan 9 x86 port, it was to a Safari laptop with a
16MHz 386, 4MB memory and an 80MB disc and a serial-line for networking.
It was hard then to imagine a PC with a disc >10GB, let alone the fact that
I'm writing this on a cpu-server with 4 400MHz Xeon processors each with
1MB L2 cache, 2GB main memory, no disc and a full-duplex 100Mb ethernet.

--jim

[9fans] seek offset

[rob]

Also, Brazil's step to 64-bit offsets was done by using the long long type,
which is still a little buggy in the compilers, but wasn't even in the Plan 9
compilers, I believe, or if so, so buggy as to be unusable.

-rob

[9fans] seek offset

[arisawa]

Thank you Russ.

Now I have changed devata following your advice,
and I am writing this mail on the new kernel.

Now I am thinking about how I move my plan9 system
on primary ide (3.2GB) to the second ide (6.4GB).

Thanks,

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] seek offset

[Russ]

You'll have to partition the disk manually (cat >/dev/hd1partition
combined with 8½'s hold mode works well) since prep is now
broken.

I could be way off base here, but it seems to me that if
you set up an identically sized partition on both disks,
you could just do cat /dev/hd0fs >/dev/hd1fs

If you don't want to make them the same size, man mkfs(8)
and use that to copy the fs.

Russ

[9fans] seek offset

[arisawa]

Thank you Russ.

I have finished all.
My system is now working on secondary IDE over 6GB.
It was easy to fix b.com.

Thanks,

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] seek offset

[Scott]

arisawa@ar.aichi-u.ac.jp writes:
| It was easy to fix b.com.

Maybe we should collect the improved versions of b.com and devata
somewhere?  If you send the boddle to the list it will get into the
archives at least.

What's the situation with >2gb scsi disks?

[9fans] seek offset

[arisawa]

Hello 9fans,

schwartz@bio.cse.psu.edu wrote:
>If you send the boddle to the list it will get into the archives at least.

I changed two files:
	/sys/src/9/pc/devata.c
	/sys/src/boot/pc/hard.c
for large IDE.

I worked on `devata.c' sent by Forsyth and he forbid me
to redistribute the source without his permission.

It was fairly easy to fix hard.c.
Changing the meaning `cap' is all to do.

term% diff hard.c 877058463/hard.c
222,224c222,223
< 			print("hd%d: LBA %d sect/trk , %d bytes/sect, %lud sectors\n",
< 				drive->driveno, drive->sectors, drive->bytes,
< 				drive->cap);
---
> 			print("hd%d: LBA %d sectors, %d bytes\n",
> 				drive->driveno, drive->sectors, drive->cap);
226c225
< 			print("hd%d: CHS %d/%d/%d, %d bytes/sect, %lud sectors\n",
---
> 			print("hd%d: CHS %d/%d/%d %d bytes\n",
228c227
< 				drive->sectors, drive->bytes, drive->cap);
---
> 				drive->sectors, drive->cap);
520c519
< 		dp->cap = dp->sectors;
---
> 		dp->cap = dp->bytes * dp->sectors;
539c538
< 		dp->cap = dp->cyl * dp->heads * dp->sectors;
---
> 		dp->cap = dp->bytes * dp->cyl * dp->heads * dp->sectors;
661c660
< 	pp->end = dp->cap;
---
> 	pp->end = dp->cap / dp->bytes;


schwartz@bio.cse.psu.edu also wrote:
>What's the situation with >2gb scsi disks?

As far as `b.com' is concerned, 877058463/scsi.c have been
already fixed as shown bellow:
term% grep cap scsi.c
scsi.c:	case ScsiGetcap:
scsi.c:scsicap(int dev, void *p)
scsi.c:	cmd = scsicmd(dev, ScsiGetcap, scsibuf(), 8);
scsi.c:	pp->end = dp->cap;
scsi.c:		if(scsibread(dev, b, 1, dp->bytes, dp->cap-1) <= 0){
scsi.c:		if(scsicap(i, buf))
scsi.c:		sdrive[i].cap = ((buf[0]<<24)|(buf[1]<<16)|(buf[2]<<8)|buf[3])+1;
scsi.c:		print("scsi%d: cap %lud, sec %d\n", i, sdrive[i].cap, sdrive[i].bytes);



It is uncertain for me whether kernel support large scsi for kfs or not.
We can find the last update of `devwren.c' in 824494162.rc.
Taking a quick look at the code, it seems there is no problem.

I have not experienced large scsi except for file server.
It is best to get exact answer from the people in bell-labs.


Thanks,

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp