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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
