Date: Mon, 23 Nov 2009 10:47:17 +0100 From: Borja Marcos <borjam@sarenet.es> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 dies in zfs Message-ID: <C21BA706-4BF2-405B-BFD2-F8E7C712A229@sarenet.es> In-Reply-To: <20091123090121.GA59823@icarus.home.lan> References: <m2skcajavv.wl%randy@psg.com> <m2r5ruja6v.wl%randy@psg.com> <4B066B13.1070006@freebsd.org> <m2bpiwitz7.wl%randy@psg.com> <4b07ac59.A2Afaf4X0IZlrgGU%perryh@pluto.rain.com> <57200BF94E69E54880C9BB1AF714BBCBA5722E@w2003s01.double-l.local> <m2ws1jh2oy.wl%randy@psg.com> <75706651-E9D4-4C40-B39C-6B8B0023DFF7@sarenet.es> <20091123090121.GA59823@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 23, 2009, at 10:01 AM, Jeremy Chadwick wrote: > On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: >> On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: >>>=20 >>>> Try running FreeBSD 7-Stable to get the latest ZFS version which on >>>> FreeBSD is 13 >>>=20 >>> that is what i am running. RELENG_7 >>=20 >> I've been following ZFS on FreeBSD long ago, and it really seems to = be stable on 8.0/amd64. >> Even Sun Microsystems say that ZFS is better used on a 64 bit system, = they don't recommend it >> on the 32 bit version of Solaris. >>=20 >> That said, there's still an outstanding bug, I managed to deadlock it = but the condition is easy to avoid. >=20 > Please provide details of this deadlock (PR, kernel output, scenario > details, etc.), and details of how to avoid it. Of course, it's been discussed on freebsd-fs, that's why I didn's = cross-post. I'm making a heavy usage of zfs send/receive to keep a replica of a = dataset. ZFS can deadlock if you are doing a zfs send and zfs receive = (I'm using incremental snapshots) and at the same time you have reading = activity on the destination dataset. Imagine this: Machine 1 is the origin, machine 2 is the destination: machine 1: zfs send -i pool/dataset@first pool/dataset@second | ssh = machine2 zfs receive -d pool And while this is running, I have some activity going on with = pool/dataset. Easy to replicate if pool/dataset contains /usr/obj and = you are doing a make buildworld on the first machine, doing frequent = replicas (30 second intervals) while on the second machine you keep a = job reading it, I did the tests with a tar process copying the /usr/obj = tree to another location. However, if you can ensure that the destination dataset is not read = while the zfs receive is working, there is no problem at all, zfs send = -i/zfs receives work like a charm, even at 30 second intervals. Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C21BA706-4BF2-405B-BFD2-F8E7C712A229>