2014/1/6 David Sterba <dste...@suse.cz>: > 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.
In my opinion, we should never update, if we dedup content of files with FILE_EXTENT_SAME. If we clone with CLONE(_RANGE), the mtime should be updated, because its like a write operation. The semantics of ctime is not completely clear to me. It should change if the "visible" meta data of a file changes. In this cases should it be updated if write to it, because mtime changes, or only if the size of the file changes? > david Gerhard -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
