Re: Activating space_cache after read-only snapshots without space_cache have been taken

[Ochi <ochi@arcor.de>]

On 04/16/2013 10:10 AM, Sander wrote:
> Liu Bo wrote (ao):
>> On Tue, Apr 16, 2013 at 02:28:51AM +0200, Ochi wrote:
>>> 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.
>>
>> So are you using '-o nospace_cache' when creating two RO snapshots?
>
> No, he first created two ro snapshots, then (some time later) mounted
> with nospace_cache, and then continued to take ro snapshots.

I need to clarify this: The NOspace_cache option was never used, I just 
didn't explicitly activate space_cache in the beginning. However, I was 
not aware that space_cache is the default anyways (at least in Arch 
which is the distro I'm using). I reviewed old system logs and it 
actually looks like space caching was always being used right from the 
beginning, even when I didn't explicitly use the space_cache mount 
option. So I guess this wasn't the problem after all :\

>>> 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 don't know why this happens, but maybe you can observe the umount
>> process's very slow behaviour by using 'cat /proc/{umount-pid}/stack'
>> or 'perf top'.
>
> AFAIUI the problem is not there anymore, but this is a good tip for the
> future.
>
> 	Sander

That's correct, the problem has vanished after the deletion of the 
oldest two snapshots. Mounting and unmounting is reasonably fast now. I 
will just continue to use the volume normally (i.e. making regular 
backups and snapshotting) and report back if the problem appears again.

Just for the records: The btrfs volume and the first snapshots were 
originally created under kernel 3.7.10. I then updated to 3.8.3. I don't 
know if this information is useful - just in case... :)

Thanks,
Sebastian