"zfs receive" lock time

[Kevin]

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