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