From: Nuno Silva <nuno.silva@vgertech.com>
To: Matti Aarnio <matti.aarnio@zmailer.org>
Cc: Dave Jones <davej@codemonkey.org.uk>,
Andries Brouwer <aebr@win.tue.nl>,
linux-kernel@vger.kernel.org
Subject: Re: open(.. O_DIRECT ..) difference in between Linux and FreeBSD ..
Date: Fri, 13 Jun 2003 00:14:32 +0100 [thread overview]
Message-ID: <3EE90958.5030901@vgertech.com> (raw)
In-Reply-To: <20030612150909.GI28900@mea-ext.zmailer.org>
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/
>
next prev parent reply other threads:[~2003-06-12 23:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-12 11:14 open(.. O_DIRECT ..) difference in between Linux and FreeBSD Matti Aarnio
2003-06-12 11:24 ` Christoph Hellwig
2003-06-12 13:17 ` Andries Brouwer
2003-06-12 14:58 ` Dave Jones
2003-06-12 15:09 ` Matti Aarnio
2003-06-12 23:14 ` Nuno Silva [this message]
2003-06-13 21:05 ` Andries Brouwer
2003-06-12 23:12 ` Rob van Nieuwkerk
2003-06-13 7:47 ` Arjan van de Ven
2003-06-13 8:27 ` Rob van Nieuwkerk
2003-06-13 8:28 ` Arjan van de Ven
2003-06-13 9:02 ` Rob van Nieuwkerk
[not found] <20030612111437.GE28900@mea-ext.zmailer.org.suse.lists.linux.kernel>
2003-06-12 11:26 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EE90958.5030901@vgertech.com \
--to=nuno.silva@vgertech.com \
--cc=aebr@win.tue.nl \
--cc=davej@codemonkey.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.aarnio@zmailer.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.