Thomas Graichen wrote:
> Steve Lord <lord@xxxxxxx> wrote:
>
> >>
> >> I just tried three copies of a root filesystem into xfs using
> >>
> >> find / -mount -print | cpio -pdm /mnt/root
> >>
> >> In two out of the three cases running repair on the resulting
> >> filesystem I got a number of disconnected inodes:
> >>
> >> disconnected inode 132, moving to lost+found
> >> disconnected inode 133, moving to lost+found
> >> disconnected inode 134, moving to lost+found
> >> disconnected inode 135, moving to lost+found
>
> > ....
>
> > OK, this is a red herring, these were files from the lost+found on the root
> > filesystem, so xfs_repair removed its lost+found to start with, so it was
> > not finding anything wrong really.
>
> > This basically says that after cloning a root the lost+found directory in
> > the xfs filesystem needs to be cleaned.
>
> hmmm in my cases the files were real (just on several real machines
> i get it after some time of use) - i also usually do an
>
> xfs_repair
> mount
> rm -rf lost+found
> xfs_repair <- is fine now
> umount
> reboot
>
> so - it is not the lost+found dir in my case ...
>
Drat, I thought had cleaned this up.
This seems to happen when the last call to sync doesn't fully complete,
or more file system activity comes in after the call to sync.
This gets back to the problem of there not really being a way to check for
activity in the file systen.
Do you have a specific circumstance that causes the failure or is it
rather random?
|