All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <lkml@dervishd.net>
To: Nathan Scott <nathans@sgi.com>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: O_DIRECT, ext3fs, kernel 2.4.32... again
Date: Wed, 3 May 2006 07:27:52 +0200	[thread overview]
Message-ID: <20060503052752.GA20657@DervishD> (raw)
In-Reply-To: <20060503060336.A1918058@wobbly.melbourne.sgi.com>

    Hi Nathan :)

 * Nathan Scott <nathans@sgi.com> dixit:
> > > Nothing else really make sense due to fcntl...
> > > 	fcntl(fd, F_SETFL, O_DIRECT);
> > > ...can happen at any time, to enable/disable direct I/O.
> > 
> >     I know, but that fcntl call should fail just like the open() one.
> > I mean, I don't find this very different, it's just another point
> > where the flag can be activated and so it should fail if the
> > underlying filesystem doesn't support it (and doesn't ignore it
> > in read()/write()).
> 
> Problem is there is no way to know whether the underlying fs
> supports direct IO or not here (fcntl is implemented outside the
> filesystem, entirely).

    I thought that it was implemented per filesystem.

> Which is not unfixable in itself (could use a superblock flag or
> something similar) but it's way out of scope for the sort of change
> going into 2.4 these days.

    Which approach does 2.6 kernel use? O_DIRECT is correctly handled
for ext3 there, AFAIK :? Are the differences too large?

    I know that this change would be intrusive and probably large,
but IMHO is a quite important bug, because it prevents apps to
selectively disable O_DIRECT (the flag is accepted by open(), so
there's no reason the app should bother about which caused the
read()/write() failures. In fact, is very difficult to know that
those failures are caused by partial/buggy support of O_DIRECT flag).

    Thanks for the information! :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to... RAmen!

  reply	other threads:[~2006-05-03  5:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27  6:32 O_DIRECT, ext3fs, kernel 2.4.32... again DervishD
2006-05-01  6:20 ` Marcelo Tosatti
2006-05-01 11:23   ` DervishD
2006-05-01 21:28     ` Nathan Scott
2006-05-01 22:23       ` Bernd Eckenfels
2006-05-02 17:24       ` DervishD
2006-05-02 20:03         ` Nathan Scott
2006-05-03  5:27           ` DervishD [this message]
2006-05-03  6:35             ` Nathan Scott

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=20060503052752.GA20657@DervishD \
    --to=lkml@dervishd.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathans@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 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.