From owner-freebsd-arch@FreeBSD.ORG Sat Mar 1 09:33:43 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D39E106566C for ; Sat, 1 Mar 2008 09:33:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id B87EB8FC1A for ; Sat, 1 Mar 2008 09:33:42 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 9B3EE744013 for ; Sat, 1 Mar 2008 11:33:41 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id RvDhXfT4P6Hp for ; Sat, 1 Mar 2008 11:33:41 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3D6D774400D for ; Sat, 1 Mar 2008 11:33:41 +0200 (EET) Message-ID: <47C922F1.2050307@icyb.net.ua> Date: Sat, 01 Mar 2008 11:33:37 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: multiple filesystems sharing/clobbering device vnode X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 09:33:43 -0000 First, a little demonstration suggested by Bruce Evance: [I hope you will continue reading after reboot] 1. mount_cd9660 /dev/acd0 /mnt1 2. mount -r /dev/acd0 /mnt2 # -r is important 3. ls -l /mnt1 The issue can be laconically described as follows: 1. We do not disallow multiple RO mounts of the same device (which could be done either on purpose or by an accident). 2. All popular (on-disk) filesystems use/clobber bufobj of device's vnode, even for RO mounts; some (ufs) do that even if mount fails. 3. There are no considerations for such a shared access, all filesystems act as if it is an exclusive owner of the vnode / its bufobj. Small snippet of code that speaks for itself (the most interesting lines are marked with XXX at the beginning): int g_vfs_open(struct vnode *vp, struct g_consumer **cpp, const char *fsname, int wr) { struct g_geom *gp; struct g_provider *pp; struct g_consumer *cp; struct bufobj *bo; int vfslocked; int error; g_topology_assert(); *cpp = NULL; pp = g_dev_getprovider(vp->v_rdev); if (pp == NULL) return (ENOENT); gp = g_new_geomf(&g_vfs_class, "%s.%s", fsname, pp->name); cp = g_new_consumer(gp); g_attach(cp, pp); error = g_access(cp, 1, wr, 1); if (error) { g_wither_geom(gp, ENXIO); return (error); } vfslocked = VFS_LOCK_GIANT(vp->v_mount); vnode_create_vobject(vp, pp->mediasize, curthread); VFS_UNLOCK_GIANT(vfslocked); *cpp = cp; XXX bo = &vp->v_bufobj; XXX bo->bo_ops = g_vfs_bufops; XXX bo->bo_private = cp; XXX bo->bo_bsize = pp->sectorsize; gp->softc = bo; return (error); } In addition to this, some filesystems (ufs) directly modify v_bufobj. I've been pondering this issue for over a month now, I have some ideas but they all are wanting in one aspect or other. I would like to hear ideas and opinions of the people on this list. P.S. for those who didn't actually run the test, here's a hand-copied excerpt from stack trace: g_io_request g_vfs_strategy ffs_geom_strategy cd9660_strategy VOP_STRATEGY_APV bufstrategy breadn bread cd9660_readdir -- Andriy Gapon