From: Bruno Diniz de Paula <diniz@cs.rutgers.edu>
To: Chris Wedgwood <cw@f00f.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: O_DIRECT foolish question
Date: 12 Feb 2003 19:36:19 -0500 [thread overview]
Message-ID: <1045096579.21195.121.camel@urca.rutgers.edu> (raw)
In-Reply-To: <20030213001302.GA13833@f00f.org>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
On Wed, 2003-02-12 at 19:13, Chris Wedgwood wrote:
> If I had to guess, write should work more or less the same as reads
> (ie. I should be able to write aligned-but-smaller-than-page-sized
> blocks to the end of files).
>
> Testing this however shows this is *not* the case.
This is not the case, I have also tested here and the file written has
n*block_size always. The problem with writing is that we can't sign to
the kernel that the actual data has finished and from that point on it
should zero-fill the bytes. And what is worse, the information about the
actual size is lost, since the write syscall will store what is passed
on the 3rd argument in the inode (field st_size of stat). This means
that after writing using O_DIRECT we can't read data correctly anymore.
The exception is when we write together with the data information about
the actual size and process disregarding information from stat, for
instance.
Well, I am sure I am completely wrong because this doesn't make any
sense for me. Someone that has already dealt with this and can bring a
light to the discussion?
Thanks,
Bruno.
>
> Now, this *might* actually be the right thing to do ... if we allow
> 'small writes' how do we deal with larger writes once the file-write
> position is messed up?
>
> Heh... tricky stuff. Though required.
>
>
>
> --cw
--
Bruno Diniz de Paula <diniz@cs.rutgers.edu>
Rutgers University
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-02-13 0:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-12 21:19 Bruno Diniz de Paula
2003-02-12 22:03 ` Andrew Morton
2003-02-12 22:29 ` Bruno Diniz de Paula
2003-02-12 22:42 ` Chris Wedgwood
2003-02-12 23:02 ` Bruno Diniz de Paula
2003-02-12 23:22 ` Bruno Diniz de Paula
2003-02-13 1:46 ` Randy.Dunlap
2003-02-12 23:24 ` Chris Wedgwood
2003-02-12 23:33 ` Bruno Diniz de Paula
2003-02-12 23:38 ` Chris Wedgwood
2003-02-12 23:49 ` Bruno Diniz de Paula
2003-02-12 23:51 ` Chris Wedgwood
[not found] ` <1045094589.4767.106.camel@urca.rutgers.edu>
[not found] ` <20030213001302.GA13833@f00f.org>
2003-02-13 0:36 ` Bruno Diniz de Paula [this message]
2003-02-13 5:12 ` Andrew Morton
2003-02-13 15:22 ` Bruno Diniz de Paula
2003-02-13 17:31 ` Andrew Morton
2003-02-13 22:45 ` Bruno Diniz de Paula
2003-02-12 23:33 ` Chris Wedgwood
2003-02-12 22:07 ` Chris Wedgwood
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=1045096579.21195.121.camel@urca.rutgers.edu \
--to=diniz@cs.rutgers.edu \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®