public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Walsh <lkml@tlinx.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Dave Chinner <david@fromorbit.com>, xfs-oss <xfs@oss.sgi.com>,
	PXXdraig Brady <P@draigBrady.com>
Subject: Re: RFE kernel option to do the desirable thing, w/regards to 'O_DIRECT' and mis-aligned data
Date: Tue, 01 Mar 2011 18:27:18 -0800	[thread overview]
Message-ID: <4D6DAB06.7090806@tlinx.org> (raw)
In-Reply-To: <20110224092625.GA3087@dastard>


    Thanks for the shorthand Dave, but I wasn't really trying to use
xfs_mkfs to make a file that was failing -- but was more trying to use
it as an example of supporting the idea that both should succeed, and
if a write is a partial write to an O_DIRECT file, that it be allowed
to succeed and the kernel, knowing the device's minimum write size
from the driver, could buffer the last sector. 

To deal with back-compat issues, it could be based off of a proc
var like /proc/kernel/fs/direct_IO_handling using bitfields (or
multiple vars if you don't like bitfields, I s
with the bits defined as:

Bit 0 Controlling allowed partial writes that start at an aligned position
Bit 1 Controlling allowed non-aligned writes
Bit 2 Controlling allowed partial reads that start at aligned position
Bit 3 Controlling allowed non-aligned reads
Bit 4 Controlling whether to use general FS cache for affected sectors

It's a bit of 'overkill' for what I wanted (just case controlled by
Bit 0), but for sake of completeness, I thought all of these combinations
should be specified.

Default of 0 = current behavior of mis-aligned data accesses failing,
while specifying various combinations would allow for variations with
the kernel handling mis-aligned accesses automatically, much like the
x86 processor handles mis-aligned integer additions or stacks automatically
(perhaps at a performance penalty, but with a tendency toward 'working'
rather than failing, if possible).

It seems better to put that logic in the kernel rather than saddle multiple
applications using DIRECT I/O with handling the non-aligned cases. 
This seems especially useful given the long term trend toward
increasing use of static-memory devices which will likely support
arbitrary direct I/O sizes. 

Linda Walsh



      reply	other threads:[~2011-03-02  2:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23  4:30 write 'O_DIRECT' file w/odd amount of data: desirable result? Linda Walsh
2011-02-23 10:34 ` Pádraig Brady
     [not found]   ` <4D654C2E.2000703@tlinx.org>
2011-02-24  1:18     ` Pádraig Brady
2011-02-24  9:26     ` Dave Chinner
2011-03-02  2:27       ` Linda Walsh [this message]

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=4D6DAB06.7090806@tlinx.org \
    --to=lkml@tlinx.org \
    --cc=P@draigBrady.com \
    --cc=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox