Thanks Darrick, Christoph for the replies: On Fri, Apr 25, 2025 at 08:00:55AM -0700, Darrick J. Wong wrote: > On Fri, Apr 25, 2025 at 06:10:14AM -0700, Christoph Hellwig wrote: > > On Thu, Apr 24, 2025 at 03:00:41PM -0700, Darrick J. Wong wrote: > > > The thing is, if you were relying on atime/mtime for detection of "file > > > data changed since last read" then /not/ copying atime into the > > > filesystem breaks that property in the image. > > > > I don't think that matter for images, because no software will keep > > running over the upgrade of the image. Also plenty of people run > > with noatime, and btrfs even defaulted to it for a while (not sure if > > it still does). > > > > At the same time having the same behavior as mkfs.ext4 is a good thing > > by itself because people obviously have been using it and consistency > > is always a good thing. > > I don't see where mke2fs -d actually copies i_mtime into the filesystem. > In misc/create_inode.c I see a lot of: > > now = fs->now ? fs->now : time(0); > ext2fs_inode_xtime_set(&inode, i_atime, now); > ext2fs_inode_xtime_set(&inode, i_ctime, now); > ext2fs_inode_xtime_set(&inode, i_mtime, now); > > which implies that all three are set to a predetermined timestamp or the > current timestamp. I'm going to set them to current timestamp as a default (so noatime, noctime will be true by default) > Also while I'm scanning create_inode.c, do you want to preserve > hardlinks? Right, will work on this too > > > How about copying [acm]time from the source file by default, but then > > > add a new -p noatime option to skip the atime? > > > > I'd probably invert the polarity. When building an image keeping > > atime especially and also ctime is usually not very useful. But that > > would give folks who need it for some reason a way to do so. > > Either's fine with me. > > --D Perfect, I'll default to current timestamp for [ac]time. Thanks
