Date: Wed, 10 Nov 1999 01:09:08 -0500 From: Simon Shapiro <shimon@simon-shapiro.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) Message-ID: <38290C04.8FC73862@simon-shapiro.org> References: <Pine.BSF.4.10.9911101617310.12455-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
>
> > > Block devices have to use a fixed block size. This size is
> > > normally BLKDEV_IOSIZE. For historical reasons, BLKDEV_IOSIZE
>
> > What I observed, is that ALL block device I/O is happening
> > in 8KB calls, except for the 512 bytes calls for slice
> > and partition management (5 of them, methinks).
>
> 8KB is probably for a filesystem-related block size being used
> instead of BLKDEV_IOSIZE. This happens when the device is
> a partition on a labeled drive and the label entry says that
> the partition type is 4.2BSD and the block size is 8192.
>
> > The 10:1 random write problem may be mine; An ancient
> > and well hidden bug in st.d which made lock unlock calls
> > for every i/o.
>
> Drivers can have this bug too :-). The wd driver has it :-(.
> In RELENG_3, the specfs i/o routines check the label for every
> block, although this is worse than useless. Checking the
> label involves calling the driver ioctl routine, and wdioctl()
> does careful locking for all ioctls although it doesn't need to
> for most. wd's locking involves waiting until the controller
> is inactive and this has bad effects on the throughput.
>
> > We run circles around NT in the Random I/O department,
> > but take a beating in the sequential I/O arena;
> > For about the same hardware, they do 98 MB/Sec,
> > I cannot get more than 45.
>
> I've always though FreeBSD has the opposite problem.
Nope. I am getting 167MB/Sec for random block device.
We are almost nine times faster on random WRITE (and I
am comparing RAW I/O here to buffered there), twice as
fast on random READ (again our RAW vs. their buffered.
If you compare our block perfromance to theirs, we are
almost fourty times faster.
We are on-par on sequential WRITEs; we get 10MB/Sec RAW and
14 block, they report under 20.
There must be some nasty trick to their sequential READ;
It is 5 times as fast as their sequential WRITE.
BTW, I may have stepped on a hornet nest here;
panic: getnewbuf: inconsistent EMPTY queue, qindex=2
Another Question to this honorable forum:
Other than heavy, multiple process, concurrent sequential
and random I/O to the block and raw devices, what good way
is there to verify that the OSM is working correctly?
Making a filesystem is always successful, and after a
panic, it fsck's perfectly, and the panic appears to be
in other filesystems.
> Bruce
--
Sincerely Yours, Shimon@Simon-Shapiro.ORG
404.664.6401
Simon Shapiro
Unwritten code has no bugs and executes at twice the speed of mouth
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38290C04.8FC73862>