mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Badari Pulavarty <pbadari@us.ibm.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	jack@suse.cz, Stephen Tweedie <sct@redhat.com>
Subject: Re: ext3_ordered_writepage() questions
Date: Mon, 20 Mar 2006 11:26:25 -0500	[thread overview]
Message-ID: <1142871986.3414.14.camel@orbit.scot.redhat.com> (raw)
In-Reply-To: <20060319023610.GA4824@mail.shareable.org>

Hi,

On Sun, 2006-03-19 at 02:36 +0000, Jamie Lokier wrote:

> Now, to be fair, most programs don't overwrite data blocks in place either.

Which is the point we're trying to make: "make" is almost always being
used to create or fully replace whole files, not to update existing data
inside a file, for example.

> They usually open files with O_TRUNC to write with new contents.  How
> does that work out with/without Badari's patch?  Is that safe in the
> same way as creating new files and appending to them is?

Yes, absolutely.  We have to be extremely careful about ordering when it
comes to truncate, because we cannot allow the discarded data blocks to
be reused until the truncate has committed (otherwise a crash which
rolled back the truncate would potentially expose corruption in those
data blocks.)  That's all done in the allocate logic, not in the
writeback code, so it is unaffected by the writeback patches.

So the O_TRUNC is still fully safe; and the allocation of new blocks
after that is simply a special case of extend, so it is also unaffected
by the patch.

It is *only* the recovery semantics of update-in-place which are
affected.

> It's this: you edit a source file with your favourite editor, and save
> it.  3 seconds later, there's a power cut.  The next day, power comes
> back and you've forgotten that you edited this file.

If your editor is really opening the existing file and modifying the
contents in place, then you have got a fundamentally unsolvable problem
because the crash you worry about might happen while the editor is still
writing and the file is internally inconsistent.  That's not something I
think is the filesystem's responsibility to fix!

--Stephen


  parent reply	other threads:[~2006-03-20 16:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08  0:19 [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support Badari Pulavarty
2006-03-08  0:22 ` [PATCH 1/3] Vectorize aio_read/aio_write methods Badari Pulavarty
2006-03-08 12:44   ` christoph
2006-03-08  0:23 ` [PATCH 2/3] Remove readv/writev methods and use aio_read/aio_write instead Badari Pulavarty
2006-03-08 12:45   ` christoph
2006-03-08 16:26     ` Badari Pulavarty
2006-03-08  0:24 ` [PATCH 3/3] Zach's core aio changes to support vectored AIO Badari Pulavarty
2006-03-08  3:37   ` Benjamin LaHaise
2006-03-08 16:34     ` Badari Pulavarty
2006-03-08 12:47 ` [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support christoph
2006-03-08 16:24   ` Badari Pulavarty
2006-03-09 16:17   ` ext3_ordered_writepage() questions Badari Pulavarty
2006-03-09 23:35     ` Andrew Morton
2006-03-10  0:36       ` Badari Pulavarty
2006-03-16 18:09         ` Theodore Ts'o
2006-03-16 18:22           ` Badari Pulavarty
2006-03-16 21:04             ` Theodore Ts'o
2006-03-16 21:57               ` Badari Pulavarty
2006-03-16 22:05                 ` Jan Kara
2006-03-16 23:45                   ` Badari Pulavarty
2006-03-17  0:44                     ` Theodore Ts'o
2006-03-17  0:54                     ` Andreas Dilger
2006-03-17 17:05                       ` Stephen C. Tweedie
2006-03-17 21:32                         ` Badari Pulavarty
2006-03-17 22:22                           ` Stephen C. Tweedie
2006-03-17 22:38                             ` Badari Pulavarty
2006-03-17 23:23                               ` Mingming Cao
2006-03-20 17:05                                 ` Stephen C. Tweedie
2006-03-18  2:57                             ` Suparna Bhattacharya
2006-03-18  3:02                           ` Suparna Bhattacharya
2006-03-17 15:32           ` Jamie Lokier
2006-03-17 21:50             ` Stephen C. Tweedie
2006-03-17 22:11               ` Theodore Ts'o
2006-03-17 22:44                 ` Jamie Lokier
2006-03-18 23:40                   ` Theodore Ts'o
2006-03-19  2:36                     ` Jamie Lokier
2006-03-19  5:28                       ` Chris Adams
2006-03-20  2:18                       ` Theodore Ts'o
2006-03-20 16:26                       ` Stephen C. Tweedie [this message]
2006-03-17 22:23               ` Jamie Lokier

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=1142871986.3414.14.camel@orbit.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=jamie@shareable.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=tytso@mit.edu \
    /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

Powered by JetHome