On Thu, Oct 04, 2012 at 05:10:00PM -0700, Linda Walsh wrote:
> Dave Chinner wrote:
> >On Thu, Oct 04, 2012 at 03:39:33PM -0700, Linda Walsh wrote:
> >>When I tried xfs_freeze / fs_freeze got fs-busy -- same as I would
> >>if I tried to umount it.
> >Of course - it's got to write all the dirty data andmetadata in
> >memory to disk. Freeze is about providing a stable, consistent disk
> >image of the filesystem, so it must flush dirty objects from memory
> >to disk to provide that.
> But it says the freeze failed.... huh.
> Just tried it again .. ( first time after reboot.. froze it no
> messages or complaints) ?!?! I don't get it.
> It gave me a file system busy message before and as near as I could tell --
> it wouldn't allow me to xfs_freeze it.
You mean EBUSY?
That means the filesystem was already frozen.
> >the problem you saw. So:
> Wasn't sure what I saw or that it was related -- exactly...
> A possible theory... but nothing I'd blaim on xfs, -- last message in log
> Oct 4 13:52:50 Ishtar kernel: [985735.911825] INFO: task fetchmail:25872
> d for more than 120 seconds.
> Oct 4 13:52:50 Ishtar kernel: [985735.918777] "echo 0 >
> ask_timeout_secs" disables this message.
And the full stack trace?
> So if I xfs-freeze something, then take a snapshot, -- I don't see that any
> of that
> would help in doing an xfs_blockget o get a dump of inodes->blocks, as it
> like it would still be dirty...
Only the log is dirty - it has a single dummy record in it to mark
it dirty. Otherwise everything is consistent, and the tools will
work fine on the snapshot image. You just have to know the magic
incantations to run the xfs_db commands directly with the extra flag
to tel it to ignore a dirty log.
i.e. xfs_ncheck is a diagnostic tool, not something that should be
run as part of a regular "get some info from the fs" workflow...