Regarding regular zfs

Peter Maloney peter.maloney at brockmann-consult.de
Fri Apr 5 14:59:41 UTC 2013


On 2013-04-05 16:07, Ronald Klop wrote:
> On Fri, 05 Apr 2013 15:02:12 +0200, Joar Jegleim
> <joar.jegleim at gmail.com> wrote:
>
>> You make some interesting points .
>> I don't _think_ the script 'causes more than 1 zfs write at a time,
>> and I'm
>> sure 'nothing else' is doing that neither . But I'm gonna check that out
>> because it does sound like a logical explanation.
>> I'm wondering if the rsync from the receiving server (that is: the
>> backup
>> server is doing rsync from the zfs receive server) could 'cause the same
>> problem, it's only reading though ...
>>
>>
>>
>
> Do you run the rsync from a snapshot or from the 'live' filesystem?
> The live one changes during zfs receive. I don't know if that has
> anything to do with your problem, but rsync from a snapshot gives a
> consistent backup anyway.
>
> BTW: It is probably more simple for you to test if the rsync is
> related to the problem, than for other people to theorize about it here.
>
> Ronald.

Also I don't believe using rsync either on the snapshot or the file
system (read or write) should be related in any way to the hang I
described. I let my cronjob rsync backups run wild without issues.

When I say zfs commands, I don't mean random other commands on the zfs
file system, but only the "zfs" command with a writing subcommand, such
as destroy, recv, or snapshot, which obviously need some locking, and
also send which locks some things, such as preventing the snapshot you
are sending from being removed while you send it.

Next time it hangs, just run something like: ps axl | grep zfs. If you
see 2 zfs commands running at once that aren't parent/child of
eachother, then you may have the same problem I described. If not (such
as if you see your send + rsync at the same time), then it is something
else.


More information about the freebsd-fs mailing list