All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.