Re: FILE_EXTENT_SAME changes mtime and ctime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 06, 2014 at 12:02:51AM +0100, Gerhard Heift wrote:
> I am currently playing with snapshots and manual deduplication of
> files. During these tests I noticed the change of ctime and mtime in
> the snapshot after the deduplication with FILE_EXTENT_SAME. Does this
> happens on purpose? Otherwise I would like to have ctime and mtime
> left unmodified, because on a read only snapshot I cannot change them
> back after the ioctl call.

I'm not sure what's the correct behaviour wrt timestamps and extent
cloning. The inode metadata are modified in some way, but the stat data
and actual contents are left unchanged, so the timestamps do not reflect
that something changed according to their definition (stat(2)).

On the other hand, the differences can be seen in the extent listing,
the physical offset of the blocks will change. I'm not aware of any
tools that would become broken by breaking this assumption. Also, the
(partial) cloning functionality is not implemented anywhere so we could
have a look and try to stay consistent with that.

My oppinion is to drop the mtime/iversion updates completely.


david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux