[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4AF1A9CD.8010704@redhat.com>
Date: Wed, 04 Nov 2009 10:20:29 -0600
From: Eric Sandeen <sandeen@...hat.com>
To: Andreas Dilger <adilger@....com>
CC: Greg Freemyer <greg.freemyer@...il.com>,
Theodore Tso <tytso@....edu>,
Ted Augustine <taugustine@...hpathways.com>,
Alexey Fisher <bug-track@...her-privat.net>,
linux-ext4@...r.kernel.org
Subject: Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption
with 2.6.32-rc1 and upwards]
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
--
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
Powered by blists - more mailing lists