linux-ext4 - Re: [PATCH RFC] Insure direct IO writes do not use the page cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090803093628.GA21712@duck.suse.cz>
Date:	Mon, 3 Aug 2009 11:36:28 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Tso <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, Curt Wohlgemuth <curtw@...gle.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH RFC] Insure direct IO writes do not use the page cache

On Thu 30-07-09 16:33:51, Theodore Tso wrote:
> On Thu, Jul 30, 2009 at 08:30:53PM +0200, Jan Kara wrote:
> >   I have to say I'm a bit worried about modify-in-place tricks - it's
> > not trivial to make sure buffer is not part of any transaction in the
> > journal, since the buffer head could have been evicted from memory, but
> > the transaction still is not fully checkpointed. Hence in memory, you
> > don't have any evidence of the fact that if the machine crashes, your
> > modify-in-place gets overwritten by journal-replay.
> 
> Yeah, good point; tracking which blocks might get overwritten on a
> journal replay is tough.  What we *could* do that would make this easier
> is to insert a revoke record for all extent tree blocks after the
> blocks have been written to disk (since at that point there's no need
> for that block to be replayed).
  Hmm, but will this help you? You'd have to wait for revoke records to
commit before you can be sure that journal replay won't overwrite your
in-place changes.
  Looking at the O_DIRECT semantics, I don't think nobody really requires
the data being on disk after the write() returns and we crash - in
particular if we extend the file, the write will be just an ordinary
buffered write so in practice, it behaves like this already. Given the fact
that only a bit special applications use O_DIRECT, I think we can afford to
make a reservation that O_DIRECT writes even to a preallocated space do not
have any special data-consistency guarantees.

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html