Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Dec 2009 17:11:10 -0600
From:      Kevin <kevin@your.org>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: "zfs receive" lock time
Message-ID:  <EBC441B4-E2B6-4FD7-8303-E531226A83F3@your.org>
In-Reply-To: <20091204202134.GA1716@garage.freebsd.pl>
References:  <30582AF2-B1E8-4C07-A487-C220845963D2@your.org> <20091204202134.GA1716@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

On Dec 4, 2009, at 2:21 PM, Pawel Jakub Dawidek wrote:

> On Wed, Dec 02, 2009 at 02:55:23PM -0600, Kevin wrote:
>>
>> If the slave is completely idle, "zfs receive" takes a fraction of a
>> second. If the slave has been very busy (lots of read activity, no
>> writes - the slave has everything mounted read only), suddenly "zfs
>> receive" can take 30 seconds or more to complete, the whole time it
>> has the filesystem locked. For example, I'd see:
>>
>
> Read activity is related to the dataset on the slave that is being
> received? Is that right?
>

Correct.

> There are two operations that can suspend you file system this way:
> rollback and receive. The suspend is done by acquiring write lock for
> the given file system where every other operation acquires read lock.
> In the end receive to acquire write lock has to wait for all read
> operations to finish.
>
> I'm not sure how your applications use it, but if files are open for
> short period of time only and then closed, you could do something like
> this:
>
> 	master# curtime=`date "+%Y%m%d%H%M%S"`
> 	master# zfs snapshot pool/fs@${curtime}
> 	master# zfs send -i pool/fs@${oldtime} pool/fs@${curtime} | \
> 		ssh slave zfs recv pool/fs
> 	slave# zfs clone pool/fs@${curtime} pool/fs_${curtime}
> 	slave# ln -fs /pool/fs_${curtime} /pool/usethis
>
> Then point your application to use directory /pool/usethis/ (clone,
> instead of received file system). And clean up clones as you wish.
> Read activity on clones shouldn't affect received file system.

This worked much much better, thank you!

I'm still a little blurry on why "zfs receive" is so so so much slower  
(going from ms to >20s) if there's any read activity going on at all,  
but this seems to make it not matter to us.

-- Kevin




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBC441B4-E2B6-4FD7-8303-E531226A83F3>