Am Sun, 20 Jul 2014 21:44:40 +0200 schrieb Marc Joliet <mar...@gmx.de>:
[...] > What I did: > > - delete the single largest file on the file system, a 12 GB VM image, along > with all subvolumes that contained it > - rsync it over again [...] I want to point out at this point, though, that doing those two steps freed a disproportionate amount of space. The image file is only 12 GB, and it hadn't changed in any of the snapshots (I haven't used this VM since June), so that "subvolume delete -c <snapshots>" returned after a few seconds. Yet deleting it seems to have freed up twice as much. You can see this from the "filesystem df" output: before, "used" was at 229.04 GiB, and after deleting it and copying it back (and after a day's worth of backups) went down to 218 GiB. Does anyone have any idea how this happened? Actually, now I remember something that is probably related: when I first moved to my current backup scheme last week, I first copied the data from the last rsnapshot based backup with "cp --reflink" to the new backup location, but forgot to use "-a". I interrupted it and ran "cp -a -u --reflink", but it had already copied a lot, and I was too impatient to start over; after all, the data hadn't changed. Then, when rsync (with --inplace) ran for the first time, all of these files with wrong permissions and different time stamps were copied over, but for some reason, the space used increased *greatly*; *much* more than I would expect from changed metadata. The total size of the file system data should be around 142 GB (+ snapshots), but, well, it's more than 1.5 times as much. Perhaps cp --reflink treats hard links differently than expected? I would have expected the data pointed to by the hard link to have been referenced, but maybe something else happened? -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
