Am Tue, 22 Jul 2014 00:30:57 +0200 schrieb Marc Joliet <mar...@gmx.de>:
> Am Mon, 21 Jul 2014 15:22:16 +0200 > schrieb Marc Joliet <mar...@gmx.de>: > > > 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? > > Hah, OK, apparently when my daily backup removed the oldest daily snapshot, it > freed up whatever was taking up so much space, so as of now the file system > uses only 169.14 GiB (from 218). Weird. And now that the background deletion of the old snapshots is done, the file system ended up at: # btrfs filesystem df /run/media/marcec/MARCEC_BACKUP Data, single: total=219.00GiB, used=140.13GiB System, DUP: total=32.00MiB, used=36.00KiB Metadata, DUP: total=4.50GiB, used=2.40GiB unknown, single: total=512.00MiB, used=0.00 I don't know how reliable du is for this, but I used it to estimate how much used data I should expect, and I get 138 GiB. That means that the snapshots yield about 2 GiB "overhead", which is very reasonable, I think. Obviously I'll be starting a full balance now. I still think this whole... thing is very odd, hopefully somebody can shed some light on it for me (maybe it's obvious, but I don't see it). -- 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
