All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <lkml@dervishd.net>
To: Marcelo Tosatti <marcelo@kvack.org>
Cc: Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: O_DIRECT, ext3fs, kernel 2.4.32... again
Date: Mon, 1 May 2006 13:23:03 +0200	[thread overview]
Message-ID: <20060501112303.GA1951@DervishD> (raw)
In-Reply-To: <20060501062058.GA16589@dmt>

    Hi Marcelo :)

 * Marcelo Tosatti <marcelo@kvack.org> dixit:
> >     Shouldn't ext3fs return an error when the O_DIRECT flag is
> > used in the open call? Is the open call userspace only and thus
> > only libc can return such error? Am I misunderstanding the entire
> > issue and this is a perfectly legal behaviour (allowing the open,
> > failing in the read operation)?
> 
> Your interpretation is correct. It would be nicer for open() to
> fail on fs'es which don't support O_DIRECT, but v2.4 makes such
> check later at read/write unfortunately ;(

    Oops :(
 
> And its too late for changing that IMO...

    Probably. Anyway, since an userspace app shouldn't bother about
which underlying filesystem a file is under, ext3 should:

    - fail in the open() call: OK, it's too late for that.
    - don't check while in read()/write(): I'm not sure about this.

    The problem I see is that I can't tell if (given that probably
the bug cannot be fixed right now) it's better to let the userspace
app believe that O_DIRECT is honored but silently ignore it, or let
the userspace believe that O_DIRECT was honored in the open() call
and make all subsequent calls to read()/write() fail.

    Myself, I would prefer to be deceived and have successful calls
even if the O_DIRECT flag was ignored instead of having successful
calls to open(O_DIRECT) but failures on subsequent read()'s, but I
must confess that I don't know what kind of scenarios need the use of
O_DIRECT and I don't know if having O_DIRECT accepted but ignored is a
good thing :(

    I'm not familiar with the ext3 code, so I don't know if it's easy
to modify it so it will reject an open if O_DIRECT is specified :(((

    Thanks for your answer, Marcelo :)

    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-01 11:23 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 [this message]
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
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=20060501112303.GA1951@DervishD \
    --to=lkml@dervishd.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@kvack.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.