e4defrag modifies folder's mtime.
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
Quoted 7 lines · Thomas Lindroth
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
Quoted 9 lines · Ted Ts'o
Quoted 7 lines · Thomas Lindroth
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.
Quoted 4 lines
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.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 3 lines · Dave Chinner
xfs_fsrdoesn'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
Quoted 15 lines · Ted Ts'o
Quoted 3 lines · Dave Chinner
xfs_fsrdoesn't use these donor files to avoid mtime updates - it uses invisible IO (i.e. O_NOATIME|O_NOCMTIME) to do that.
O_NOCMTIMEdoesn't exist yet. Frominclude/linux/fs.h:/*
* Don't update ctime and mtime.
*
* Currently a special hack for the XFSopen_by_handleioctl, but we'll
* hopefully graduate it to a properO_CMTIMEflag supported by open(2) soon. */
#defineFMODE_NOCMTIME((__forcefmode_t)0x800)
Quoted 3 lines
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.
Signature · 2 lines
Dave Chinner [email protected]