On Mon, 28 Nov 2005 09:27:47 -0500
Matthew Mondor <mm_lists@pulsar-zone.net> wrote:

I resumed doing some research related to custom storage using raw
devices:

Hmm reading /usr/src/sys/dev/ata/wd.c and physio(9), it appears that
using the raw device causes no unwanted buffering, if I properly
understand, so this should be fine.

About the prefered I/O block size to use, it appears that filesystems
can use various sizes depending on the wanted size of the FS and block
indexing methods used;  Since I can choose a custom block size, and that
I saw fdisk(8) report the same amount of sectors per tracks (63) both
for BIOS and NetBSD geometry, I guess that I could base the system on
sector sized blocks, or perhaps track sized blocks and use custom I/O
buffering....  I however have no idea if this geometry is virtual, or if
it actually corresponds to the hard drive hardware and that I'll gain
any advantage basing my block size on the sector or track size.

I have seen some cache related ioctls in wd.c.  I'm unsure if this
should be used to retreive/set/flush (DIOCGCACHE, DIOCSCACHE,
DIOCCACHESYNC).  I guess that since operations on raw devices are
unbuffered, that the use of fsync(2) will probably be irrelevant to
ensure that a the data is synchronized to disk, though.  Would it
however make any sense to set the buffer size related to my block size,
and to use the flush ioctl after commiting transaction data and related
log entries?

I yet can't determine if it's possible for a block to be only partially
written to disk in the event of a crash.  The latest transaction logs
will need to be properly commited to disk after writing the new file(s)
data out of the buffer, so this is an important aspect I must look into.

If someone with a better clue could shed some light on these, it would
be greatly appreciated.

Thanks,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.