[ On Saturday, December 4, 2004 at 03:00:04 (-0500), der Mouse wrote: ]
> Subject: Re: NetBSD, apple fibre-channel card & 2.8TB Xserve-RAID
>
> I saw no obvious problems with disks and partitions over 1T with
> 2.0RC4.  I am not able to try going above 2T, though.

Well that's very good to know....

I wonder if I can find all the necessary changes and pull them up to my
1.6.2 source tree.....


> This sounds like my own experiences with the 1.6.2 disklabel.  Did you
> try any of the 2.0 RCs?

Not a full release -- just a kernel.

Maybe my latest attempt to build a full '-current' will eventually
generate a usable disklabel program that I can try on the alpha with the
-current kernel I've been using to test GigE drivers....



> (1) Create a big file.  In my case, I ran "btoa < /netbsd > z", and
> then catted enough copies of z together to exceed 10G.
> 
> (2) Compress this file.  I used gzip --fast; someone else I've been
> corresponding with says exactly what the compression program is is
> irrelevant, as long as it has sanity checks on uncompression.
> 
> (3) Uncompress the file to /dev/null.  Do you get an error?  I do.

Yikes!  Indeed I do!

The label and filesystem were created with 1.6.2_STABLE, but the kernel
running during these tests is -current as of a few days ago.

[console]<@> # disklabel sd5
# /dev/rsd5c:
type: SCSI
disk: Xserve RAID
label: fictitious
flags:
bytes/sector: 512
sectors/track: 128
tracks/cylinder: 128
sectors/cylinder: 16384
cylinders: 179526
total sectors: 2147483647
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0 

3 partitions:
#        size    offset     fstype  [fsize bsize cpg/sgs]
 a: 2147483647         0     4.2BSD   2048 16384    27   # (Cyl.    0 - 131071*)
 c: 2147483647         0     unused      0     0         # (Cyl.    0 - 131071*)
[console]<@> # df -g /mnt
      /mnt (/dev/sd5a   ):   16384 block size         2048 frag size
 536754345 total blocks  525130240 free blocks   498292523 available
    621431 total files      621438 free files  78b00000828 filesys id
    ffs[0] fstype           0x1000 flag                255 filename length
         0 owner               324 syncwrites         1646 asyncwrites

[console]<@> # cd /mnt
[[ .... muck around creating big files -- I started with "hexdump /netbsd" .... ]]
[console]<@> # ls -l
total 18591216
-rw-r--r--  1 root  wheel   1163765834 Nov 27 07:06 bigger-file
-rw-r--r--  1 root  wheel  14103459216 Nov 27 07:14 biggest-file
-rw-r--r--  1 root  wheel     11522434 Nov 27 06:59 little-file
-rw-r--r--  1 root  wheel   3753902080 Oct  4 22:57 test.zero.dd
[console]<@> # gzip --fast < biggest-file > biggest-file.gz    
[console]<@> # ls -l
total 23248176
-rw-r--r--  1 root  wheel   1163765834 Nov 27 07:06 bigger-file
-rw-r--r--  1 root  wheel  14103459216 Nov 27 07:14 biggest-file
-rw-r--r--  1 root  wheel   4767516559 Nov 27 07:50 biggest-file.gz
-rw-r--r--  1 root  wheel     11522434 Nov 27 06:59 little-file
-rw-r--r--  1 root  wheel   3753902080 Oct  4 22:57 test.zero.dd
[console]<@> # gzcat < biggest-file.gz > /dev/null                             

gzcat: stdin: invalid compressed data--length error
[console]<@> # 


> I first tried this with 1.5G instead of 10G, and it didn't error.  The
> compressed file was slightly less than the machine's RAM, though (it
> has 1G ram, and the file was 1.01+e9 bytes, some tens of megs less than
> the RAM).  I now suspect that it is important that cg 0 fill up more
> than that the compressed file be larger than RAM.

This alpha has 16GB of RAM, and reports avail memory = 16086 MB on boot
with a -current kernel that's been partially "tuned" for the system.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>