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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
