Comment 18 for bug 412470

Hi,

> Sounds like a solution.
> The latest_snapshot will always contain all the information of the last
> taken snapshot and we store only the part that is included via hardlinks in
> the folder with the snapshot-id.

This is exactly what I meant.

> Advantages:
>   1. we use less space than by copying everything each time
No, space should be the same.

>   2. we need to have only one rsync command (the --dry-run is unnecessary)
Yes.

>   3. we copy (hardlink) only the included folders
Yes, so less hardlinks mean less fs-meta-infos and better performance.

> Disadvantage:
>   1. now we have every file visible in every snapshot, it might not have
>   been updated in that round but it is visible, making scrolling through the
>   snapshot folders to search for that particular version you want easy. if we
>   use your proposed trick a lot of the snapshot folders will show: file not
>   present in this snapshot (for less frequent files)

Yes, like I said. Big disadvantage. What I proposed to solve this,
softlinks, are really not suitable, because you can delete a snapshot
and get orphan links. So maybe we have to hardlink indeed all the
files.

>   2. we use one complete snapshot more than before (the latest_snapshot)

Yes and no. There is one more directory: latest_snapshot, but there is
no loss of space.

The very first start after configuring BiT would make the
latest_snapshot by copying all the files, sure. Then it makes its
first snapshot-id by hardlinking. So after the first start, two
snapshots exist, but only the space of one snapshot is used.

Of course, rsync has to unlink a destination file which has changed,
instead of changing the content. This would be a mess, as there are 2
links to the same file! If you think about it, this is actually the
current behaviour. BackInTime would not work correctly else! I mean
the current code!

> We could avoid the last though, by first making the copy (hardlinking) and
> give it the name of last time, and then do the rsync for the next round. (so
> you make the actual snapshot folder during the next scheduled round), this
> gets pretty complicated so I vote actually against that option and use the
> extra space for an extra snapshot...

This I don't get. Sounds complicated, and which extra space? We talk
about hardlinks or Fat32? On Fat32 each snapshot occupies the space
regarding the files in it, but the algorithm should work correctly on
both FS.

Peter