Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 13 Jun 2003 00:14:32 +0100 | From | Nuno Silva <> | Subject | Re: open(.. O_DIRECT ..) difference in between Linux and FreeBSD .. |
| |
Hi!
OARS, anybody knows a patch that implements O_DIRECT in 2.4 the same way that it's implemented in 2.5?
2.5's O_DIRECT is much less restrictive than 2.4's. OTOH 2.5 is still not recommended for production use. Any way of having the best of both worlds? :)
Thanks, nuno Silva
Matti Aarnio wrote: > On Thu, Jun 12, 2003 at 03:58:14PM +0100, Dave Jones wrote: > >> > Transfer sizes, and the alignment of user buffer >> > and file offset must all be multiples of the logi- >> > cal block size of the file system. >> >>Just to confirm something that I wrote in the post-halloween-2.5 doc, >>that doesn't tally with this.. >> >>- The size and alignment of O_DIRECT file IO requests now matches that >> of the device, not the filesystem. Typically this means that >> you can perform O_DIRECT IO with 512-byte granularity rather than 4k. >> >>Is this a case of the man pages not following 2.5 yet, or is this >>incorrect ? > > > I think of three things: > - 2.4 defines rules in most confusing manner > - 2.5 continues that > - We need more complete IRIX's O_DIRECT API: > > from open(2): > O_DIRECT > If set, all reads and writes on the resulting file descriptor will > be performed directly to or from the user program buffer, provided > appropriate size and alignment restrictions are met. Refer to the > F_SETFL and F_DIOINFO commands in the fcntl(2) manual entry for > information about how to determine the alignment constraints. > O_DIRECT is a Silicon Graphics extension and is only supported on > local EFS and XFS file systems, and remote BDS file systems. > > > from fcntl(2): > F_SETFL Set file status flags to the third argument, .... > > Flags not understood for a particular descriptor are silently > ignored except for FDIRECT. FDIRECT will return EINVAL if used > on other than an EFS, XFS or BDS file system file. > > F_DIOINFO Get information required to perform direct I/O on the specified > fildes. Direct I/O is performed directly to and from a user's > data buffer. Since the kernels buffer cache is no longer > between the two, the user's data buffer must conform to the > same type of constraints as required for accessing a raw disk > partition. The third argument, arg, points to a data type > struct dioattr which is defined in the <fcntl.h> header file > and contains the following members: d_mem is the memory > alignment requirement of the user's data buffer. d_miniosz > specifies block size, minimum I/O request size, and I/O > alignment. Ths size of all I/O requests must be a multiple of > this amount and the value of the seek pointer at the time of > the I/O request must also be an integer multiple of this > amount. d_maxiosz is the maximum I/O request size which can be > performed on the fildes. If an I/O request does not meet these > constraints, the read(2) or write(2) will return with EINVAL. > All I/O requests are kept consistent with any data brought into > the cache with an access through a non-direct I/O file > descriptor. See also F_SETFL above and open(2). > > >> Dave > > > /Matti Aarnio > - > 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/ >
- 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/
| ![\](/images/icornerr.gif) |