From: Eric Sandeen <sandeen@redhat.com>
To: Ric Wheeler <rwheeler@redhat.com>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>,
Surbhi Palande <surbhi.palande@canonical.com>,
linux-ext4@vger.kernel.org, Theodore Tso <tytso@mit.edu>
Subject: Re: [PATCH] ext4: Ensure writecache to disk in no journal mode
Date: Fri, 26 Mar 2010 12:40:04 -0500 [thread overview]
Message-ID: <4BACF174.50703@redhat.com> (raw)
In-Reply-To: <4BACEBE3.50108@redhat.com>
On 03/26/2010 12:16 PM, Ric Wheeler wrote:
> On 03/26/2010 12:37 PM, Dmitry Monakhov wrote:
>> Surbhi Palande<surbhi.palande@canonical.com> writes:
>>
>>
>>> Ensure that in the no journal mode the write cache is flushed to the disk by
>>> calling a blkdev_issue_flush() which issues a WRITE_BARRIER if necessary.
>>>
>> As soon as i understand, nojournal mode is assumed to be used for
>> fail-free block devices(raid + UPS). So we don't have to worry about
>> blkdev's wcache vs persistent storage correctness.
No, I don't think so - even with "fail-free" storage, a system crash
still results in an inconsistent filesystem; with nojournalling you've
made the decision to either fsck or re-mkfs after that event.
> I don't think that is a safe assumption. If users want that behavior,
> they can mount with fs without barriers...
yes, I agree with Ric - even if you don't have journalling, the proper
sequence of sync calls should still result in data permanently on disk
by default. (though I think using mount -o nobarrier for this purpose,
in absence of journalling, overloads the option a little...)
-Eric
prev parent reply other threads:[~2010-03-26 17:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 16:21 [PATCH] ext4: Ensure writecache to disk in no journal mode Surbhi Palande
2010-03-26 16:37 ` Dmitry Monakhov
2010-03-26 17:16 ` Ric Wheeler
2010-03-26 17:40 ` Eric Sandeen [this message]
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=4BACF174.50703@redhat.com \
--to=sandeen@redhat.com \
--cc=dmonakhov@openvz.org \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=surbhi.palande@canonical.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 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.