On Thu, 15 Feb 2007 06:19:10 +0100, Mahesh Siddheshwar <[EMAIL PROTECTED]> wrote:

Robert Thurlow wrote:
Glenn Faden wrote:

4) A bug currently prevents a client instance and a server instance
from being safe to use on the same box (apologies, can't quote the
bugid from here).  How likely, in your use case, is it that this will
be a problem, i.e. will your boxes be in the position where a zone
needs data shared from another zone as opposed to a separate server?

This is a must fix. In TX we want to automount between labeled zones on the same machine. It seems to work with ZFS. Is the deadlock specific to UFS/NFS?

Good question!  I don't expect that it is, but perhaps ZFS's use of the
ARC would insulate it.  Maybe Mahesh would know.

The problem seen in 5065254 and what is seen commonly
in the recent past is mainly due to the interaction between NFS, UFS and
segmap driver**. This scenario, typically, is noticeable only under
heavy load or on systems with a low segmapsize.  Since ZFS does not
use the segmap driver, this particular scenario should be averted.

Currently the loopback mounted configuration is never tested. So I
won't be surprised if we run into other loopings, but with some
effort those should be tractable.


** NFS tries to commit pages, which, on the NFS server
requires UFS to obtain a segmap slot. Before you use the segmap slot,
you need to free/destroy the previous mappings for the segmap slot, which
happens to be a locked NFS page, the lock for which is currently
owned by the commit thread which begun this process.

There is one more scenario which I have not seen, but
is theoretically possible -- where writing to a UFS file
requires stealing a dirty NFS page which would in
turn require writing to the server, which requires exclusive
locking of the same UFS file.

even if you leave this segmap issue aside, it is very likely you encounter
different deadlocks, because this is an attempt to stack file systems
that are not really stackable file systems and you'd run into
issues similar to 4498652 / 4154394

zones-discuss mailing list

Reply via email to