From: Ochi <ochi@arcor.de>
To: linux-btrfs@vger.kernel.org
Subject: Activating space_cache after read-only snapshots without space_cache have been taken
Date: Tue, 16 Apr 2013 02:28:51 +0200 [thread overview]
Message-ID: <516C9B43.7040605@arcor.de> (raw)
Hello everyone,
I've ran into problems with _very_ slow unmounting of my btrfs-formatted
"backup" volume. I have a suspicion what might be the cause but maybe
someone with more experience with the btrfs code could enlighten me
whether it is actually correct.
The situation is the following: I have created a backup-volume to which
I regularly rsync a backup of my system into a subvolume. After
rsync'ing, I take a _read-only_ snapshot of that subvolume with a
timestamp added to its name.
Now at the time I started using this backup volume, I was _not_ using
the space_cache mount option and two read-only snapshots were taken
during this time. Then I started using the space_cache option and
continued doing snapshots.
A bit later, I started having very long lags when unmounting the backup
volume (both during shutdown and when unmounting manually). I scrubbed
and fsck'd the volume but this didn't show any errors. Defragmenting the
root and subvolumes took a long time but didn't improve the situation much.
Now I started having the suspicion that maybe the space cache possibly
couldn't be written to disk for the readonly subvolumes/snapshots that
were created during the time when I wasn't using the space_cache option,
forcing the cache to be rebuilt every time.
Clearing the cache didn't help. But when I deleted the two snapshots
that I think were taken during the time without the mount option, the
unmounting time seems to have improved considerably.
I will have to observe whether unmounting stays quick now but my
question is whether it is possible that the read-only snapshots taken
during the time when I wasn't using space_cache might actually have been
the culprits.
Best,
Sebastian
next reply other threads:[~2013-04-16 0:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 0:28 Ochi [this message]
2013-04-16 3:11 ` Activating space_cache after read-only snapshots without space_cache have been taken Liu Bo
2013-04-16 8:10 ` Sander
2013-04-16 11:35 ` Ochi
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=516C9B43.7040605@arcor.de \
--to=ochi@arcor.de \
--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.