On Tuesday, 3 August 1999 at 11:11:39 +0800, Stephen Hocking-Senior Programmer PGS
Tensor Perth wrote:
> The people who I work for were about to junk a bunch of 6 year old disks when
> I snaffled them. Among them were 4 DEC DSP5400S (3.8GB each), with a nice
> external case. These disks had been doing duty on a boat carrying out seismic
> surveys, attached to misc. Sun workstations. These are typical of their
> vintage - full height 5 1/4" drives fast narrow SCSI2, and noisy as all
> blazes. I have them hooked up to a NCR810, as one striped FS (it's just for
> experiments, not valuable data). fdisking them was easy, but disklabelling
> them was a royal pain. I ended up editing the /etc/disktab file to add an
> appropriate label and running "disklabel -w -B /dev/rda0c DSP5400S" which
> still gives an error message, but appears to install the label. I only found
> out that it installed the label by accident, wasting a bunch of time in the
> process.
Did you try 'disklabel -w da0 auto'?
> I created a striped volume across the 4 drives with the default stripe size of
> 256K. I read the rather interesting discussion within the man pages about the
> optimal stripe size and have a couple of queries. Firstly, the type of traffic
> that this 13.9GB filesystem will see will be mainly sequential reading and
> writing of large files. There will only be a few files (~2-30), each several
> gigs. (I'm fooling around with the seismic software at home, and typcal
> surveys can results in files many gigs in size). Given that FreeBSD breaks
> I/Os down into 64k chunks, would having a 64k stripe size give more
> parallelism?
No, it would cause a higher I/O load. Vinum doesn't transfer entire
stripes, it transfers what you ask for. With a large stripe size, the
chances are higher that you can perform the transfer with only a
single I/O.
> I'm seeing 4.4MB/s if I read from an individual disk, but only about
> 5.6MB/s when reading from the striped volume.
How many concurrent processes? Remember that striping doesn't buy you
anything with a single process. You might like to try rawio
(ftp://ftp.lemis.com/pub/rawio.tar.gz) and see what that tells you.
> Looking at the systat display, the 8k fs blocks do seem to be
> clustered into larger requests, so I'm not too worried about the FS
> block size. What have people observed with trying larger FS block
> sizes?
I don't know if anybody has tried larger FS blocks than 8 kB. I once
created a file system with 256 kB blocks (just to see if it could be
done). I also tried 512 kB blocks, but newfs died of an overflow.
I'd expect that you would see a marked drop in performance, assuming
that it would work at all.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
