From: "Norbert Scheibner" <scno@gmx.net>
To: linux-btrfs@vger.kernel.org
Subject: Freeing space over reboot question
Date: Thu, 09 Feb 2012 18:42:32 +0100 [thread overview]
Message-ID: <20120209174232.318280@gmx.net> (raw)
Gl=C3=BCck Auf!
I use now kernel 3.2. The filesystem was originally created under 2.6.3=
9 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-b=
ackup, 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 snap=
shot 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 durin=
g 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-fille=
d 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 o=
nly 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 s=
pace, should the umount take as long as the background process or shoul=
d the background process stop immediately and restart after the next mo=
unt (if possible, especially with a kernel change in between or the pos=
sibility that the fs gets mounted read-only)?
=2E.. Or is this all nonsense and it happened here because I rebooted a=
nd 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2012-02-09 17:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 17:42 Norbert Scheibner [this message]
2012-02-09 18:11 ` Freeing space over reboot question Chester
2012-02-09 18:57 ` Norbert Scheibner
2012-02-09 18:20 ` Roman Mamedov
2012-02-09 19:02 ` cwillu
2012-02-11 13:47 ` Norbert Scheibner
2012-02-11 13:56 ` Roman Mamedov
2012-02-11 16:42 ` Norbert Scheibner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120209174232.318280@gmx.net \
--to=scno@gmx.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.