From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>,
Theodore Tso <tytso@mit.edu>,
Ted Augustine <taugustine@techpathways.com>,
Alexey Fisher <bug-track@fisher-privat.net>,
linux-ext4@vger.kernel.org
Subject: Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards]
Date: Wed, 04 Nov 2009 10:20:29 -0600 [thread overview]
Message-ID: <4AF1A9CD.8010704@redhat.com> (raw)
In-Reply-To: <9EA6C408-DC45-457F-B7FA-93F08A769E78@sun.com>
Andreas Dilger wrote:
> On 2009-11-02, at 16:02, Eric Sandeen wrote:
>> Andreas Dilger wrote:
>>> I thought Takashi Sato was working on allowing a filesystem freeze
>>> ioctl from userspace? This would hook into the filesystem-specific
>>> freeze code so that when the ioctl() returns the on-disk filesystem
>>> is fully consistent and does not even require journal replay.
>> That's in and done; most recent xfsprogs' xfs_freeze utility will
>> even freeze non-xfs filesystems now :) Otherwise a wrapper utility
>> around the ioctl would be trivial to write.
>
>
> It probably makes sense to add a tune2fs option to freeze and unfreeze
> the
> filesystem? That would allow ext* users to have an available/documented
> command even if they don't have xfsprogs installed.
I'd rather see a simple tool in util-linux-ng since it's no longer
fs-specific, rather than putting something in each filesystem's toolbox.
However, the command is a little dangerous; you can lock up the machine
by freezing the wrong filesystem at the wrong time... IO can stack up
(nothing stops mmap writes yet, today) and the unfreeze may require
memory, which may require writeback to ... the frozen filesystem....
In this case there is a fair bit of rope to hang oneself ;)
-Eric
next prev parent reply other threads:[~2009-11-04 16:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-30 14:20 xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards] Greg Freemyer
2009-10-30 15:14 ` Eric Sandeen
2009-10-30 15:31 ` Alexey Fisher
2009-10-30 16:14 ` Eric Sandeen
2009-10-30 16:52 ` Alexey Fisher
2009-10-30 17:13 ` Eric Sandeen
2009-10-30 17:43 ` Duane Griffin
2009-10-30 15:47 ` Alexey Fisher
2009-11-01 5:45 ` Theodore Tso
2009-11-02 21:59 ` Greg Freemyer
2009-11-02 22:53 ` Andreas Dilger
2009-11-02 23:02 ` Eric Sandeen
2009-11-04 8:05 ` Andreas Dilger
2009-11-04 16:20 ` Eric Sandeen [this message]
2009-11-03 13:52 ` Theodore Tso
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=4AF1A9CD.8010704@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@sun.com \
--cc=bug-track@fisher-privat.net \
--cc=greg.freemyer@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=taugustine@techpathways.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