Glück Auf!
I use now kernel 3.2. The filesystem was originally created under 2.6.39 on 1
whole hdd, mounted with "noatime,nodiratime,inode_cache". I use it for backups:
rsync the whole system to a subvolume, snapshot it and then delete some
tempfiles in the snapshot, which are 90% of the full-backup, all once a day. In
figures: on this 1 TB hdd is the full-backup with around 600 GiB and 10 to 20
snapshots with around 30 GiB each, all together using around 700 GiB on disc.
What I did:
- I deleted (by accident) the big subvolume with the full-backup with "btrfs
subvolume delete" and recreated it with the same name with a snapshot of the
latest snapshot.
- During the deletion of this big subvolume in background I changed the kernel
from 3.1 to 3.2 and did a reboot.
- After that, the fs was operational, but the space was still used and the next
system-backup onto this fs failed with no space left errors. "btrfs filesystem
df" showed me that the fs used the whole hdd and that there were only some kB
free, which fits to the errors from rsync during backup.
So the used space of subvolume I deleted, was not freed.
How to get the space back which should have been freed?
A balance did not help. What worked was the deletion of that half-filled
subvolume, which I use for the full backup. After that the space got freed and
the next balance run shrinked the fs again, so that it uses only a part of the
hdd.
What I wonder is: Couldn't this be a little bit more user-friendly?
If there is a background process running like this here, freeing some space,
should the umount take as long as the background process or should the
background process stop immediately and restart after the next mount (if
possible, especially with a kernel change in between or the possibility that
the fs gets mounted read-only)?
... Or is this all nonsense and it happened here because I rebooted and after
that used another kernel.
My best wishes
Norbert
--
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
