[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2250: don't re-use metadata from earlier snapshots, in a "tahoe backup"
Tahoe-LAFS
trac at tahoe-lafs.org
Fri Jun 27 01:12:48 UTC 2014
#2250: don't re-use metadata from earlier snapshots, in a "tahoe backup"
-------------------------------------------------+-------------------------
Reporter: zooko | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: code | undecided
Keywords: forward-compatibility tahoe-backup | Version: 1.10.0
metadata | Launchpad Bug:
-------------------------------------------------+-------------------------
Currently if you run {{{tahoe backup}}} on a directory, and the
''contents'' of the children of that directory have not changed, then
{{{tahoe backup}}} will reuse the already-created immutable LAFS-
directory. Therefore, the ''metadata'' on the children, such as the
timestamps, owner information, etc., will be re-used. This can lead to a
snapshot which says "Here's the state of the directory at time T", and
then it shows the children, with their ''metadata'' from an earlier
snapshot. This is very misleading, and only a very sophisticated user
would be able to figure out that the metadata was actually re-used from a
previous snapshot, and would be able to figure out in what cases metadata
gets re-used vs. gets read afresh from the filesystem.
To fix this, make it so that if any of the metadata of any of the children
has changed, then we make a new LAFS-directory to hold the current
metadata of all the children, even if the contents of the children (and
therefore their immutable file read-caps) haven't changed. (''Excluding''
{{{st_atime}}}, which we do not record anyway, and which would cause
intolerable thrashing if we did.)
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2250>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list