Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Aug 2013 11:47:44 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: Deadlock in nullfs/zfs somewhere
Message-ID:  <520209B0.1030402@FreeBSD.org>
In-Reply-To: <20130721161854.GC5991@kib.kiev.ua>
References:  <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> <51E95CDD.7030702@FreeBSD.org> <20130719184243.GM5991@kib.kiev.ua> <51E99477.1030308@FreeBSD.org> <20130721071124.GY5991@kib.kiev.ua> <51EBABAB.5040808@FreeBSD.org> <20130721161854.GC5991@kib.kiev.ua>

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

Kostik,

thank you for being patient with me and explaining details of the contract and
inner workings of VFS suspend.

As we discussed out-of-band, unfortunately, it seems that it is impossible to
implement the same contract for ZFS.  The reason is that ZFS filesystems appear
as many independent filesystems, but in reality they share a common pool.  So
suspending a single filesystem does not suspend the pool and that is contrary to
current VFS suspend concept.

Additionally, ZFS needs a "full" suspend mechanism that would prevent both read
and write access from VFS layer.  The current VFS suspend mechanism suspend
writes / modifications only.

I am not sure how to reconcile the differences...
Here is a number of rough ideas.  I will highly appreciate your opinion and
suggestions.

Idea #1.
Add a new suspend type to VFS layer that would correspond to the needs of ZFS.
This is quite laborious as it would require adding vn_start_read calls in many
places.  Also, making two kinds of VFS suspend play nice with each other could
be non-trivial.

Idea #2.
This is perhaps an ugly approach, but I already have it implemented locally.
The idea is to re-use / abuse vnode locking as a ZFS suspend barrier.
(This can be considered to be analogous to putting vn_start_op() / vn_end_op()
into vop_lock / vop_unlock).
That is, ZFS would override VOP_LOCK/VOP_UNLOCK to check for internal
suspension.  The necessary care would be taken to respect all locking flags
including LK_NOWAIT.  Recursive entry would have to be supported too.

Idea #3.
Provide some other mechanism to expose ZFS suspension state to VFS.  And then
use that mechanism to avoid blocking on calls to ZFS in the strategic /
sensitive places like vlrureclaim(), vtryrecycle(), etc.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520209B0.1030402>