Re: mmap() vs. O_DIRECT
phil-news-nospam_at_ipal.net
Date: 05/13/05
- Next message: phil-news-nospam_at_ipal.net: "Re: maybe using O_LARGEFILE"
- Previous message: Alex van der Wal: "Re: How to guarantee that an embedded (RealTime) application never causes a page fault"
- In reply to: Kasper Dupont: "Re: mmap() vs. O_DIRECT"
- Next in thread: Kasper Dupont: "Re: mmap() vs. O_DIRECT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 13 May 2005 14:39:18 GMT
On Fri, 13 May 2005 06:54:19 +0200 Kasper Dupont <kasperd@daimi.au.dk> wrote:
| phil-news-nospam@ipal.net wrote:
|>
|> On Thu, 12 May 2005 23:47:29 +0200 Kasper Dupont <kasperd@daimi.au.dk> wrote:
|> | phil-news-nospam@ipal.net wrote:
|> |>
|> |> How about if I write whole blocks, the ftruncate() at the end? Would
|> |> you think that should work?
|> |
|> | I think it would work, but why do you want to do
|> | that? Do you have a good reason for wanting the
|> | O_DIRECT there? Does ftruncate only change the
|> | file size? Or does it also zero the remaining part
|> | of the last block? If it wants to zero the unused
|> | part of the last block I don't think the combination
|> | with O_DIRECT is good.
|>
|> It might zero it. But for very large files it should not matter much.
|
| OK, maybe it would just be better to disable O_DIRECT
| before writing the last partial block.
It seems to be working OK doing O_DIRECT and ftruncate(). There is the
issue of this possibly defeating Reiserfs tail-packing. But for some
things I will be doing, I'd rather defeat it, anyway (yeah, I know I
can turn it off at mount time).
|> Got any better idea to defeat the tendency of the kernel to try to
|> keep the pages I'm writing, under the false idea that I might want
|> to read them back real soon?
|
| No, unfortunately not. My suggestion would be to
| improve the kernel to be less agrassive in caching
| stuff that has been accessed only once. The same
| problem applies to sequential reading. I wonder how
| is O_DIRECT going to deal with the last partial block
| in a file when reading? (So far I have mostly been
| using O_DIRECT on block devices).
I would think if you read using O_DIRECT, you have provided a full block
of virtual memory to use, and it thus can pass along the address of that
block internally instead of an internal buffer cache page. So even if
the file is short, it shouldn't need to buffer that block.
On writing, perhaps it is a bit different. If you write a partial block
then it would have to buffer it to zero out the rest, or just go ahead
and write in the excess space of the file's block whatever followed the
data in VM. But clearly, any further writing with O_DIRECT cannot be
done because the file position is off the block boundary. In theory the
next write could be taken from the same relative offset and be aligned
anyway, but you can't write the whole block at once now because the data
written before it will get overwritten by doing this one as a full block.
I noticed in an earlier test I was doing that files larger than 4096 bytes
were written as some multiple of 4096 bytes (and short). So it seems that
if the blocksize is 4096 and I write 9000 bytes I get 8192 written and the
write() call returns 8192 instead of 9000.
-- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------
- Next message: phil-news-nospam_at_ipal.net: "Re: maybe using O_LARGEFILE"
- Previous message: Alex van der Wal: "Re: How to guarantee that an embedded (RealTime) application never causes a page fault"
- In reply to: Kasper Dupont: "Re: mmap() vs. O_DIRECT"
- Next in thread: Kasper Dupont: "Re: mmap() vs. O_DIRECT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
