FreeBSD open(2):
O_DIRECT may be used to minimize or eliminate the cache effects of read-
ing and writing. The system will attempt to avoid caching the data you
read or write. If it cannot avoid caching the data, it will minimize the
impact the data has on the cache. Use of this flag can drastically
reduce performance if not used with care.
Нигде кроме фряхи не нашел.
man 2 open под Linux:
Try to minimize cache effects of the I/O to and from this file.
In general this will degrade performance, but it is useful in
special situations, such as when applications do their own
caching. File I/O is done directly to/from user space buffers.
The I/O is synchronous, i.e., at the completion of the read(2)
or write(2) system call, data is guaranteed to have been trans-
ferred. Transfer sizes, and the alignment of user buffer and
file offset must all be multiples of the logical block size of
the file system.
This flag is supported on a number of Unix-like systems; support
*was added under Linux in kernel version 2.4.10.*
A semantically similar interface for block devices is described
in raw(8).
вобщем немного не то... советую почитать про o_direct патч от андреа акканджели. так же эндрю мортон занимался этими вопросами... вобщем читайте [вырезка из lkml]
Bruno Diniz de Paula <diniz@cs.rutgers.edu> wrote:
>> >> Hi, >> >> I am trying to use O_DIRECT to read ordinary files and read syscall >> always returns 0, unless when the file size equals the fs block size.
It should be returning -1, with errno set to EINVAL.
>> Is >> it true that I can only use O_DIRECT when the size of the file written >> in the inode is a multiple of block size? >>
The file can be of any size - the kernel will zero-fill any remaining bytes.
The address and length which you pass into the read() or write() system call must both be a multiple of the filesystem block size.
It is always safe to just use the machine's page size for alignment calculations - no filesystem has a blocksize larger than the pagesize.
A good way to do this is to run getpagesize(), and to then malloc a buffer which is one page larger than you need. Then round that address up to the next page boundary. And perform I/O into that memory with multiple-of-page-size requests.
In the 2.5 kernel the "must be a multiple of blocksize" requirement was relaxed. We now support alignments and lengths down to the minimum which is supported by the underlying device. Typically 512 bytes, but not always.
Portable applications should not assume that 512-byte alignment is supported. They should query the device's aligment requirements via the BLKSSZGET ioctl against (say) /dev/hda1. Or they can simply try 512, 1024, 2048, ... at initialisation time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
