Date: Wed, 17 Jul 2013 14:26:12 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Adrian Chadd <adrian@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, freebsd-current <freebsd-current@FreeBSD.org> Subject: Re: Deadlock in nullfs/zfs somewhere Message-ID: <51E67F54.9080800@FreeBSD.org> In-Reply-To: <CAJ-VmokR8jJpdRc_kBJzhW4_R1pJnj3UPfsG5ANpq-kEGwCP9g@mail.gmail.com> References: <CAJ-Vmomy3MrkSwJLQUGnDuD3EC3HzrudEghSDMeDwzVdaFNpLg@mail.gmail.com> <51DCFEDA.1090901@FreeBSD.org> <CAJ-VmokctCmV4%2By17uvqO9wXEyh0s%2BaXZ9nggvoAgP5%2BZHSgFA@mail.gmail.com> <51E59FD9.4020103@FreeBSD.org> <CAJ-VmokR8jJpdRc_kBJzhW4_R1pJnj3UPfsG5ANpq-kEGwCP9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 16/07/2013 22:40 Adrian Chadd said the following: > :( So it's a deadlock. Ok, so what's next? A creative process... One possibility is to add getnewvnode_reserve() calls before the ZFS transaction beginnings in the places where a new vnode/znode may have to be allocated within a transaction. This looks like a quick and cheap solution but it makes the code somewhat messier. Another possibility is to change something in VFS machinery, so that VOP_RECLAIM getting blocked for one filesystem does not prevent vnode allocation for other filesystems. I could think of other possible solutions via infrastructural changes in VFS or ZFS... -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E67F54.9080800>