Direct I/O support (patches included)

Linda Walsh rsync at tlinx.org
Sat Feb 16 23:24:06 MST 2013


> Dag Wieers wrote:
>> Hi,
>>
>> Since a --direct-io feature was requested a few times the past decade 
>> with little response and the actual patch is quite trivial, I patched 
>> both v3.0.9 and master branch and included the patches here.
----
	Sigh.

	It hasn't been done because it isn't trivial.

	The code to the core-utils 'dd' util has got it right.  They transparently handle
cases where your file size or requested I/O isn't on a block boundary.

	Have to also make sure the memory buffer lines up... AT LEAST,
cache-line size (64 bytes?).. malloc only guarantees aligned for
any of the types they support.  That would be 16 bytes for a long long.

	It may be that memory has to be aligned on a 512 or 4096 byte
boundary like the disk, but I can't think of why that would be off hand.
But the cache line size is almost a certainty.  That would mean allocating
64 bytes more than you need and putting your actual byte buffer at a memory
address where the bottom 5 bits are all zero (cuz 64=0b10 0000), so when the
bottom 5 bits are zero, it has a 64-byte alignment.

	if 512 bytes are needed, that's 2&9, so the bottom 8-bits of the address
start of your transfer buffer would need to be zero.

	Ahh... yup... didn't look carefully at the message.

writefd_unbuffered failed to write 4 bytes to socket

	You can't write partial sectors.  a minimum of 512, or 4096 to
be safe (because some disks are 4k sector sizes now).

	Sadly, it's a bit more work than trivial.







More information about the rsync mailing list