Re: xfs_fsr - problem with open files possible?

[Eric Sandeen <sandeen@sandeen.net>]

Martin Steigerwald wrote:

> Could data loss happen when running xfs_fsr on files that are opened by an 
> application?

It should not; fsr performs a lot of safety checks and aborts under
problematic circumstances.  It will skip files if:

 * mandatory locks are present
 * file is marked immutable, append-only, or nodefrag
 * filesystem is shut down
 * change/modify times have been altered since defrag started
 * original file is mmapped

If you can clearly recreate it with xfs_fsr, it would be interesting to
compare the good & bad index files to see how they differ, it might
offer a clue as to what/why/how it changed.

> I did not came across any other corrupted files except a Mercurial 
> repository. I can not pinpoint this problem to XFS at all and have no 
> idea how and when it got corrupted. At least in my backup from some weeks 
> ago the repository has been okay. Unfortunately I do not know anymore 
> whether I made a commit to that repository while xfs_fsr was running or 
> not. But I think I didn't.
> 
> The filesystem itself was okay after fragmentation, I checked it via 
> xfs_check!
> 
> I can try to reproduce the problem. Would be handy tough to have an 
> xfs_fsr that can be limited only to operate on a certain directory and 
> its files and sub directories. This way I could create a new mailfolder, 
> copy some mails in there, have it opened so that KMail accesses the index 
> file and let xfs_fsr only run on this mailfolder.

>From the man page:

 Files marked as no-defrag will be skipped. The xfs_io(8) chattr command
 with the f attribute can be used to set or clear this flag.  Files  and
 directories created in a directory with the no-defrag flag will inherit
 the attribute.

so you can flag your mail directory or index files as no-defrag if you
like.  (I know this is the converse of what you wanted... but maybe helpful)

-Eric

> I can also open a bug report, but I first wanted to ask here.
> 
> Regards,