From: Andrea Arcangeli <andrea@suse.de>
To: Jeff Dike <jdike@karaya.com>
Cc: Ryan Cumming <bodnar42@phalynx.dhs.org>, linux-kernel@vger.kernel.org
Subject: Re: Special Kernel Modification
Date: Mon, 5 Nov 2001 17:53:37 +0100 [thread overview]
Message-ID: <20011105175337.D18319@athlon.random> (raw)
In-Reply-To: <E160aCK-0001Fs-00@localhost> <200111050552.AAA06451@ccure.karaya.com>
In-Reply-To: <200111050552.AAA06451@ccure.karaya.com>; from jdike@karaya.com on Mon, Nov 05, 2001 at 12:52:51AM -0500
On Mon, Nov 05, 2001 at 12:52:51AM -0500, Jeff Dike wrote:
> bodnar42@phalynx.dhs.org said:
> > > Mounting it synchronous will disable caching in the VM.
> > Who told
> > you that? Synchronous mounting turns off write buffering. Even with
> > "-o sync" writes will still end up in the page cache, they'll just be
> > commited immediately.
>
> Ummm, how about O_DIRECT instead of O_SYNC (or maybe as well, my googling
> hasn't been clear on whether O_DIRECT bypasses the cache on writes as well)?
O_DIRECT is synchronous but only in terms of data, if you want the
metadata to be synchronous as well you need to open with
O_SYNC|O_DIRECT, and even in such case all the metadata reads will came
from cache.
For example if you only care about being able to reach the data after a
crash (not about the inode info) in a file with all its logical blocks
mapped to physical blcoks (no holes) and then you fsync, later you can
as well avoid O_SYNC and you still don't risk to lose data after a crash
because the block mappings never changes, if you grow/shrink the file
you definitely need O_SYNC to be sure the O_DIRECT data is still there
after a crash instead.
Andrea
next prev parent reply other threads:[~2001-11-05 16:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-05 0:01 Special Kernel Modification Lonnie Cumberland
2001-11-05 0:19 ` Ryan Cumming
2001-11-05 0:29 ` lonnie
2001-11-05 1:04 ` Jan-Benedict Glaw
2001-11-05 3:04 ` Mike Fedyk
2001-11-06 0:34 ` Jorgen Cederlof
2001-11-06 0:38 ` lonnie
2001-11-05 0:22 ` Alan Cox
2001-11-05 0:39 ` Phil Sorber
2001-11-05 0:38 ` Rik van Riel
2001-11-05 1:04 ` Jeremy Jackson
2001-11-05 1:58 ` Jeff Dike
2001-11-05 2:14 ` Ryan Cumming
2001-11-05 4:02 ` Jeff Dike
2001-11-05 3:13 ` Ryan Cumming
2001-11-05 5:52 ` Jeff Dike
2001-11-05 5:30 ` Ryan Cumming
2001-11-05 14:22 ` Jeff Dike
2001-11-05 16:53 ` Andrea Arcangeli [this message]
2001-11-05 20:18 ` Jeff Dike
2001-11-05 19:05 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2001-11-05 0:37 John Weber
[not found] <E160aCK-0001Fs-00@localhost.suse.lists.linux.kernel>
[not found] ` <200111050552.AAA06451@ccure.karaya.com.suse.lists.linux.kernel>
2001-11-05 6:22 ` Andi Kleen
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=20011105175337.D18319@athlon.random \
--to=andrea@suse.de \
--cc=bodnar42@phalynx.dhs.org \
--cc=jdike@karaya.com \
--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 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.