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

Andreas Dilger
2009-11-02T22:53:38Z

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.

> 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.
>
> ext4 may already support mounting of readonly clones, but if not it
> needs to before it will qualify as a data center ready filesystem.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.