On Thu, Oct 04, 2012 at 09:06:49AM -0700, Linda Walsh wrote:
> Linda Walsh wrote:
> (blah blah blah)...
> or more specifically:
> xfs_freeze -f /home/.snapdir/\@GMT-2012.10.04-03.06.17
> Ishtar:/# xfs_ncheck /dev/Home+Space/Home-2012.10.04-03.06.17
> ERROR: The filesystem has valuable metadata changes in a log which needs to
> be replayed. Mount the filesystem to replay the log, and unmount it before
> re-running xfs_ncheck. If you are unable to mount the filesystem, then use
> the xfs_repair -L option to destroy the log and attempt a repair.
> Note that destroying the log may cause corruption -- please attempt a mount
> of the filesystem before doing this.
> must run blockget -n first
> ok -- lets mount/umount it:
> Ishtar:/# mount -o ro,nouuid
So, a read only snapshot? If so what makes you think that recovery
can run and modify the filesystem/log?
THe whole point of freeze creating a consistent disk image is so you
can mount it without needing recovery to run. i.e:
# mount -o ro,nouuid,norecovery ....
> Um... looking at the above it would appear that I froze a fs.
> ncheck claimed the freeze didn't result in the logfile being written being put
> into a consistent state, but said to remount the fs to allow it to play then
> So... did that.
> Log file is still in a corrupt state.
The log is not corrupt, just dirty.
> Am I wrong in assuming that doing xfs_repair -L to destroy the log on this
> dev, might be a bad thing to do and might screw up it's "Origin" file
> system (i.e. the current 'live' /home partition)?
It will try to write to the snapshot. If it is a read-only