> > Just thinking about this, if you did the xfs_repair on a live filesystem
> > then you really cannot rely on it being correct. Repair uses the block
> > device interface which will not use the same caching as XFS is using
> > for its meta-data. In general, repair should not be run on a live
> > filesystem (repair -n can be since it does not modify anything).
> > Also if a filesystem was not cleanly unmounted then it should be
> > remounted and unmounted again before running repair - as the log
> > may contain the missing parts of the picture.
>
> no - all tests were done after a clean reboot into an ext2 based
> system - so no repair_xfs is done with the fs online
OK, this is good, provided we really managed to unmount the xfs filesystem
cleanly before rebooting into the ext2 system.
By the way, is it possible to find out what these inodes were? If they
contain text is it anything you recognize. I am wondering if they could
be things like the syslog file which could be written very close to
system shutdown. I am confident that an unmount of an xfs filesystem is
working correctly, but I am not confident that the root filesystem gets
unmounted correctly.
Steve
>
> > In theory XFS should unmount correctly, although I think there are some
> > issues with making a remount read-only look like a clean unmount - this
> > may be what is happening on the root disk.
>
> maybe i'll have a closer look at what exactly redhat is doing here
Looks like this:
mount -n -o remount,ro /
Which will not look like a clean shutdown when we remount an XFS filesystem.
Steve
|