* e4defrag modifies folder's mtime.
@ 2012-01-01 20:12 Thomas Lindroth
2012-01-03 20:34 ` Ted Ts'o
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Lindroth @ 2012-01-01 20:12 UTC (permalink / raw)
To: linux-ext4
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: e4defrag modifies folder's mtime.
2012-01-01 20:12 e4defrag modifies folder's mtime Thomas Lindroth
@ 2012-01-03 20:34 ` Ted Ts'o
2012-01-04 4:53 ` Dave Chinner
0 siblings, 1 reply; 5+ messages in thread
From: Ted Ts'o @ 2012-01-03 20:34 UTC (permalink / raw)
To: Thomas Lindroth; +Cc: linux-ext4
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: e4defrag modifies folder's mtime.
2012-01-03 20:34 ` Ted Ts'o
@ 2012-01-04 4:53 ` Dave Chinner
2012-01-04 5:27 ` Ted Ts'o
0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2012-01-04 4:53 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Thomas Lindroth, linux-ext4
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
david@fromorbit.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: e4defrag modifies folder's mtime.
2012-01-04 4:53 ` Dave Chinner
@ 2012-01-04 5:27 ` Ted Ts'o
2012-01-04 7:43 ` Dave Chinner
0 siblings, 1 reply; 5+ messages in thread
From: Ted Ts'o @ 2012-01-04 5:27 UTC (permalink / raw)
To: Dave Chinner; +Cc: Thomas Lindroth, linux-ext4
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: e4defrag modifies folder's mtime.
2012-01-04 5:27 ` Ted Ts'o
@ 2012-01-04 7:43 ` Dave Chinner
0 siblings, 0 replies; 5+ messages in thread
From: Dave Chinner @ 2012-01-04 7:43 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Thomas Lindroth, linux-ext4
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
david@fromorbit.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-04 7:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-01 20:12 e4defrag modifies folder's mtime Thomas Lindroth
2012-01-03 20:34 ` Ted Ts'o
2012-01-04 4:53 ` Dave Chinner
2012-01-04 5:27 ` Ted Ts'o
2012-01-04 7:43 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).