Re: xfsdump question

[Matteo Centonza <matteo@sif.it>]

Hi Ivan,

> xfsdump assumes /sbin is in root's path.  If it isn't, it probably should
> be.  If it is, then be sure that xfsdq is there.

i think that the dump program is executed by the amanda user that in any
case has /sbin in the path (just as root). I suppose is a problem
inherited from amanda autoconf.

> Hm, this is a bit odd.  One might expect these failures if xfsdump were
> running on a busy filesystem, where a file may be deleted between the time
> that xfsdump finds out about it, and the time it decides to finally dump
> it to tape.
>
> However, I assume that the files in question are not subject to regular
> deletion and creation, so ... hmmm.

Filesystems are dumped early in the morning, when activity is very poor.
On the other hand, that's the second message i get about the same three
files, so it's very unlikely that this is the case.

>
> Can you try the following commands:
>
> . stat <filename>
> . ls -li <directory>
>   (confirm that regular stat will work on files)
>
> . df -klT
>   (is /xxxx/xxxxxx/.gnome/panel.d/default/Applet_7_Extern on the same
>   filesystem as /home)
>
> . cat <filename>
>   (is the file readable)
>
> . xfs_check
> . xfs_repair
>   (chech for inconsistencies within the filesystem)
>

Yes files are on the same fs....

I've tried all commands but xfs_repair and stuff _seems_ in good shape.

Hope this helps,

-m