Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards]

[Eric Sandeen <sandeen@redhat.com>]

Andreas Dilger wrote:
> On 2009-11-02, at 14:59, Greg Freemyer wrote:
>> One example is a hardware raid array that creates readonly snapshots
>> or clones.  (Lots of those exist in the real world).
>>
>> So the typical backup procedure is:
>>
>> ====
>> Queisce application (databases, etc. have utils to do this.)
>>
>> Queisce filesystem (xfs_freeze -f can be done from userspace. is there
>> a ext4 util?)
>>
>> issue raid array command to create snapshot.
>>
>> release filesystem (xfs_freeze -u)
>>
>> release the app (util provided by app).
>>
>> Mount the snapshot readonly (true readonly with zero writes to the
>> block device).
>>
>> Backup the readonly snapshot (to tape, etc.).
> 
> 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.

>> I believe XFS had 2 issues related to this process when first
>> implemented in linux.
>>
>> 1) It required the UUID to be unique.  Obviously in the above scenario
>> it is not, so "mount -o nouuid" was added for xfs.
>>
>> 2) Journal replay was originally aways attempted in the above process,
>> so the "mount -o norecovery" option was added to force a true readonly
>> mount.

these days a frozen xfs fs should be consistent & not need replay.

-Eric

>> ext4 may already support mounting of readonly clones, but if not it
>> needs to before it will qualify as a data center ready filesystem.