I ran e4defrag from e2fsprogs-1.42 on a file system and a lot of folders
had their mtime updated as a result. This confuses both my backup
program and myself. I guess the folder timestamps change because the
temporary donor file is created in the same directory as the original
file. XFS's defrag program put the donor files in a temporary folder in
the root of the file system. Maybe e4defrag could do the same.
/Thomas Lindroth
On Sun, Jan 01, 2012 at 09:12:36PM +0100, Thomas Lindroth wrote:
> I ran e4defrag from e2fsprogs-1.42 on a file system and a lot of
> folders had their mtime updated as a result. This confuses both my
> backup program and myself. I guess the folder timestamps change
> because the temporary donor file is created in the same directory as
> the original file. XFS's defrag program put the donor files in a
> temporary folder in the root of the file system. Maybe e4defrag
> could do the same.
Yes, that could be done if the user running the program (which does
not have to be root) has write access to the root directory of the
file system. There will certainly be cases where this will not be
true, however.
- Ted
On Tue, Jan 03, 2012 at 03:34:43PM -0500, Ted Ts'o wrote:
> On Sun, Jan 01, 2012 at 09:12:36PM +0100, Thomas Lindroth wrote:
> > I ran e4defrag from e2fsprogs-1.42 on a file system and a lot of
> > folders had their mtime updated as a result. This confuses both my
> > backup program and myself. I guess the folder timestamps change
> > because the temporary donor file is created in the same directory as
> > the original file. XFS's defrag program put the donor files in a
> > temporary folder in the root of the file system. Maybe e4defrag
> > could do the same.
>
> Yes, that could be done if the user running the program (which does
> not have to be root) has write access to the root directory of the
> file system. There will certainly be cases where this will not be
> true, however.
xfs_fsr doesn't use these donor files to avoid mtime updates - it
uses invisible IO (i.e. O_NOATIME|O_NOCMTIME) to do that.
Also xfs_fsr needs root permissions because it uses the XFS
open-by-handle interfaces. Indeed, it doesn't always use tmp donor
dirs in the root directory - it only ever does that when doing an
entire fs re-organisation. If you are just defragging a single file,
it creates the tmp file in the same directory as the file being
defragged...
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Wed, Jan 04, 2012 at 03:53:18PM +1100, Dave Chinner wrote:
>
> xfs_fsr doesn't use these donor files to avoid mtime updates - it
> uses invisible IO (i.e. O_NOATIME|O_NOCMTIME) to do that.
O_NOCMTIME doesn't exist yet. From include/linux/fs.h:
/*
* Don't update ctime and mtime.
*
* Currently a special hack for the XFS open_by_handle ioctl, but we'll
* hopefully graduate it to a proper O_CMTIME flag supported by open(2) soon.
*/
#define FMODE_NOCMTIME ((__force fmode_t)0x800)
I'd have to check, but it wouldn't surprise me if glibc is filtering
out all fcntl flags it doesn't understand, so for now, this is an
XFS-only special...
- Ted
On Wed, Jan 04, 2012 at 12:27:18AM -0500, Ted Ts'o wrote:
> On Wed, Jan 04, 2012 at 03:53:18PM +1100, Dave Chinner wrote:
> >
> > xfs_fsr doesn't use these donor files to avoid mtime updates - it
> > uses invisible IO (i.e. O_NOATIME|O_NOCMTIME) to do that.
>
> O_NOCMTIME doesn't exist yet. From include/linux/fs.h:
>
> /*
> * Don't update ctime and mtime.
> *
> * Currently a special hack for the XFS open_by_handle ioctl, but we'll
> * hopefully graduate it to a proper O_CMTIME flag supported by open(2) soon.
> */
> #define FMODE_NOCMTIME ((__force fmode_t)0x800)
>
> I'd have to check, but it wouldn't surprise me if glibc is filtering
> out all fcntl flags it doesn't understand, so for now, this is an
> XFS-only special...
Sounds to me like e2defrag needs it, so perhaps it should finally
be made a proper open flag like the comment says rather than
inventing some other way of solving the problem....
Cheers,
Dave.
--
Dave Chinner
[email protected]