On Dec 18, 2005, at 8:43 PM, Charles Ballowe wrote:
> On 12/18/05, gwtmp01 / mac.com <gwtmp01 / mac.com> wrote:
>>
>> I hope you don't mean reading/writing to the raw device.   I would
>> do a whole lot of other things before I would drop down to
>> raw device access. Premature optimization is not a good thing.
>>
> nah... it would require filesystem interfaces to the block mapping in
> the inode - I don't know if such things exist and they certainly
> aren't portable, but it seems like it could be a very efficient way to
> drop data out of the middle of the file. Probably over-optimizing
> though.

uh, yep.

Just to be clear, when I say reading/writing to the raw device I mean
something like /dev/rdisk0, which presents the underlying media as a
single large file.  This bypasses the standard filesystem so that
the media just looks like a huge array of blocks.  I was not suggesting
actually writing a disk device driver to interface with the hardware
directly.

It is possible to query the filesystem to get the block size of the
device.  You could then arrange for your I/O to be in multiples of
the native block size to improve performance.  In Ruby:

	File.stat("testfile").blksize

Note:  this is all system programming stuff and has little if
anything to do with Ruby except for how Ruby abstracts the underlying
filesystem calls.

Disclaimer:  I have no idea what the situation is on the Windows side of
the house.