raw vs. ufs comparison

[Jan Andres]

Hi there!

someone wrote:

> Did some quick tests of raw vs. ufs ... both under SDS 4.2.1 on Solaris8
> ... but it is turning out that ufs is faster. Does this seem reasonable ?

It does. When using the raw device, any I/O is done synchronously. When
using UFS, only metadata is written synchronously. For your "dd" example,
the latter is surely more performant.

The usual application of raw devices (or the "forcedirectio" flag) however
is DBMSes, which do their own caching and perform any disk I/O with the
O_SYNC flag. In that case raw devices win, because data doesn't need to be
copied from one memory region to another (from application memory to cache),
and is instead written directly from user space memory to disk.

The OS'es caching mechanisms mainly just increase I/O overhead if you're
running a DBMS.

--
Jan Andres

[Anthony Mandic]

Jan Andres wrote:

> > Did some quick tests of raw vs. ufs ... both under SDS 4.2.1 on Solaris8
> > ... but it is turning out that ufs is faster. Does this seem reasonable ?

>
> It does. When using the raw device, any I/O is done synchronously.

Is that right? Guess the aiowrite man page must be wrong then.

> The usual application of raw devices (or the "forcedirectio" flag) however
> is DBMSes, which do their own caching and perform any disk I/O with the
> O_SYNC flag.

The O_SYNC flag with raw devices. Amazing!

> In that case raw devices win, because data doesn't need to be
> copied from one memory region to another (from application memory to cache),
> and is instead written directly from user space memory to disk.

And that makes it faster? I didn't realise memory copies are
so slow.

-am © 2003

[Akop Pogosian]

noone <noone@noone.org> wrote:

> Did some quick tests of raw vs. ufs ... both under SDS 4.2.1 on Solaris8
> ... but it is turning out that ufs is faster. Does this seem reasonable ?

Have you installed the latest SDS 4.2.1 patch (108693 on SPARC)? I
remember, the SDS 4.2.1 without this patch had some serious
performance problems when accessing the raw metadevices under certain
configurations.


-akop

[Richard L. Hamilton]

In article <beun6d$rek$1@lust.ihug.co.nz>,
jmsalvo <jmsalvo@yahoo.com.au> writes:

>
> A much better tool to do the raw vs. ufs should be dt ( similar to dd ),
> with support for async i/o:
>
> [url]http://www.bit-net.com/~rmiller/dt.html[/url]
>
> However, the PDF manual says that aio support in the program is only
> built-in for Tru64.
>
> Anyone tried it on Solaris ?

Along those lines, there's also
[url]ftp://ftp.lysator.liu.se/pub/unix/pcopy/pcopy-1.3.tar.gz[/url], a threaded
copy program (although I suppose asyncio could be faster than threads,
pthreads are arguably more widely available). It might be interesting
if someone with large enough amounts of disk space to for significant
results timed some of the various copy programs out there.

--
mailto:rlhamil@mindwarp.smart.net [url]http://www.smart.net/~rlhamil[/url]

[John Salvo]

Richard L. Hamilton wrote:

> In article <beun6d$rek$1@lust.ihug.co.nz>,
> jmsalvo <jmsalvo@yahoo.com.au> writes:
>

>>A much better tool to do the raw vs. ufs should be dt ( similar to dd ),
>>with support for async i/o:
>>
>>[url]http://www.bit-net.com/~rmiller/dt.html[/url]
>>
>>However, the PDF manual says that aio support in the program is only
>>built-in for Tru64.
>>
>>Anyone tried it on Solaris ?

>
>
> Along those lines, there's also
> [url]ftp://ftp.lysator.liu.se/pub/unix/pcopy/pcopy-1.3.tar.gz[/url], a threaded
> copy program (although I suppose asyncio could be faster than threads,
> pthreads are arguably more widely available). It might be interesting
> if someone with large enough amounts of disk space to for significant
> results timed some of the various copy programs out there.
>

Interesting ... but I really wanted to test async I/O on raw vs. async
I/O with concurrent direct I/O on UFS.

The dt program from Robert Miller that I mentioned above does not link
against the aio library.

[Richard L. Hamilton]

In article <Am0Ra.5927$wU5.3080@news-server.bigpond.net.au>,
John Salvo <jmsalvo@yahoo.com.au> writes:

> Richard L. Hamilton wrote:

>> In article <beun6d$rek$1@lust.ihug.co.nz>,
>> jmsalvo <jmsalvo@yahoo.com.au> writes:
>>

>>>A much better tool to do the raw vs. ufs should be dt ( similar to dd ),
>>>with support for async i/o:
>>>
>>>[url]http://www.bit-net.com/~rmiller/dt.html[/url]
>>>
>>>However, the PDF manual says that aio support in the program is only
>>>built-in for Tru64.
>>>
>>>Anyone tried it on Solaris ?

>>

[...]

> The dt program from Robert Miller that I mentioned above does not link
> against the aio library.

Well, it wouldn't directly, even if it were set up to do AIO on Solaris,
it would link against -lrt, which would pull in libaio because the librt
POSIX aio functions are implemented in terms of libaio on Solaris.

If you add dtaio.c to CFILES, -lrt to EXTLIBS, and -DAIO to CFLAGS
in Makefile.solaris, it should compile with the AIO functionality enabled
on Solaris 8 (it did for me). No idea whether it will actually _work_ or
not, I leave that up to you. :-)

--
mailto:rlhamil@mindwarp.smart.net [url]http://www.smart.net/~rlhamil[/url]