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
> /dev/Home+Space/Home-2012.10.04-03.06.17
> /home/.snapdir/@GMT-2012.10.04-03.06.17
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
> umount...
>
> 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
snapshot...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|