how to replay log of a fs that has no log? or is this supposed to work?

how to replay log of a fs that has no log? or is this supposed to work?

[Linda Walsh]

Looking at xfs_freeze it claims it is suppose to:
        When this is selected, all ongoing transactions in the
        filesystem are allowed to complete, new write system calls are  halted,
        other calls which modify the filesystem are halted, and all dirty data,
        metadata, and  log  information  are  written  to  disk.
--
Important in the above is the part about all the log information being
written to disk.

That ***should*** imply that xfs_ncheck shouldn't complain about outstanding
logfile changes that need to be replayed, no?  Er, um, having just tried that,
and noting that it DOES still indicated the log file is still outstanding,
does that mean xfs_freeze doesn't work in regards to writing out the logfile
or ?? what?

I assume I'm missing something? Seems like lunches aren't available even
after paying for them...let alone hoping for free ones...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: how to replay log of a fs that has no log: is this supposed to work? SW Defect?

[Linda Walsh]

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
Ishtar:/# umount /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

---
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.

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)?


  

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: how to replay log of a fs that has no log: is this supposed to work? SW Defect?

[Dave Chinner]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs