From owner-freebsd-fs@FreeBSD.ORG Fri Jul 19 15:36:56 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 68B131FF for ; Fri, 19 Jul 2013 15:36:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AD391DD for ; Fri, 19 Jul 2013 15:36:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA11234; Fri, 19 Jul 2013 18:36:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V0Cjk-000A2D-Md; Fri, 19 Jul 2013 18:36:52 +0300 Message-ID: <51E95CDD.7030702@FreeBSD.org> Date: Fri, 19 Jul 2013 18:35:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Deadlock in nullfs/zfs somewhere References: <51E59FD9.4020103@FreeBSD.org> <51E67F54.9080800@FreeBSD.org> <51E7B686.4090509@FreeBSD.org> <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> <20130719103025.GJ5991@kib.kiev.ua> In-Reply-To: <20130719103025.GJ5991@kib.kiev.ua> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:36:56 -0000 on 19/07/2013 13:30 Konstantin Belousov said the following: > I think that you should satisfy the VFS invariants, and prevent mutators > from operating on the filesystem when MNTK_SUSPEND is set, for the > case mutators are running outside the context where VFS could call > vn_start_write() around. I would like to inquire more about this suggestion. With the proposed patch zfs_suspend_fs would first call vfs_write_suspend, which would wait for all threads that came via VFS (and called vn_start_write) to leave and it would also mark a filesystem as suspended and that would prevent new VFS writers. Then zfs_suspend_fs calls zfsvfs_teardown, which would wait for all threads in ZFS vnode ops and vfs ops to leave and would block new calls to those ops. So there is a window between the filesystem being marked as "VFS-suspended" and it becoming fully "ZFS-suspended". As I understand you are concerned about this window. I would like to understand what assumptions VFS code makes or could make about a filesystem marked as suspended. I also would like to be pointed to the code that makes any such assumptions. I need to understand this, because if there is any code that assumes that a suspended filesystem is really frozen, then there can be a much larger problem. Unlike UFS, ZFS does not use fs suspension for creating snapshots. It does not need to because of its COW nature and use of transactions. ZFS uses suspension for rollbacks, receiving of ZFS streams and fs version upgrades. That is for operations that modify the on-disk and in-memory data and metadata. So even without that window the filesystem is going to be modified. That's the whole purpose of ZFS suspend. -- Andriy Gapon