From owner-freebsd-geom@FreeBSD.ORG Sun Nov 9 09:58:24 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33718106564A for ; Sun, 9 Nov 2008 09:58:24 +0000 (UTC) (envelope-from jmrueda@diatel.upm.es) Received: from edison.ccupm.upm.es (edison.ccupm.upm.es [138.100.4.49]) by mx1.freebsd.org (Postfix) with ESMTP id B43988FC12 for ; Sun, 9 Nov 2008 09:58:23 +0000 (UTC) (envelope-from jmrueda@diatel.upm.es) Received: from smtp.euitt.upm.es (acherontia2.euitt.upm.es [138.100.52.79]) by edison.ccupm.upm.es (8.13.8/8.13.8) with ESMTP id mA99lTYP013189 for ; Sun, 9 Nov 2008 10:47:30 +0100 Received: from localhost (localhost [127.0.0.1]) by smtp.euitt.upm.es (Postfix) with ESMTP id 7DFF956439 for ; Sun, 9 Nov 2008 10:47:29 +0100 (CET) Received: from smtp.euitt.upm.es ([127.0.0.1]) by localhost (smtp.euitt.upm.es [127.0.0.1]) (amavisd-new, port 11124) with ESMTP id 5p5pr+Duy0vt for ; Sun, 9 Nov 2008 10:47:18 +0100 (CET) Received: from aurora.diatel.upm.es (unknown [138.100.49.70]) (Authenticated sender: jmrueda) by smtp.euitt.upm.es (Postfix) with ESMTPSA id A3A5256424 for ; Sun, 9 Nov 2008 10:47:18 +0100 (CET) Received: from [172.29.9.10] ([172.29.9.10]) by aurora.diatel.upm.es (8.14.2/8.14.2) with ESMTP id mA99lDDX015264 for ; Sun, 9 Nov 2008 10:47:14 +0100 (CET) (envelope-from jmrueda@diatel.upm.es) Message-ID: <4916B19B.7000803@diatel.upm.es> Date: Sun, 09 Nov 2008 10:47:07 +0100 From: =?ISO-8859-1?Q?Javier_Mart=EDn_Rueda?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <20081107192150.GA3007@troutmask.apl.washington.edu> In-Reply-To: <20081107192150.GA3007@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: RW and RO semantic and unable to umount a partition? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 09:58:24 -0000 Steve Kargl escribió: > So, I may have done something in the category of "Don't do that!". > > On node n19, I export /dev/ad4s1e and combine it into a mirror > on node n18 with n18's /dev/ad4s1e. On n18 I have /dev/mirror/data, > and I've successfully mounted /dev/mirror/data: > > n18:root[32] mount /dev/mirror/data /data > > Now, I tried the the following: > > On n18, I created /etc/gg.exports > > n18:root[33] cat /etc/gg.exports > 192.168.0.17 RW /dev/mirror/data > n18:root[34] ggated -v > > On node n17 (yes, a third system). I do > > n17:root[08] ggatec create -o rw 192.168.0.18 /dev/mirror/data > > The above command does not create /dev/ggate0. So, I tried > > ggatec create -o ro 192.168.0.18 /dev/mirror/data > > This created the /dev/ggate0 device. Now, the interesting > part > > n17:root[10] mount /dev/ggate0 /mnt > n17:root[11] ls /mnt > .snap/ fcurra/ kargl/ > n17:root[12] umount /mnt > umount: unmount of /mnt failed: Operation not permitted > n17:root[13] umount -f /mnt > umount: unmount of /mnt failed: Operation not permitted > > Three questions. Why is RW not permitted? Why does umount > fail? How the heck to I force umount or the unmounting of /mnt? > > > RW is not permitted because gmirror has already opened /dev/ad4s1e for RW. The rule is this: you can open a geom provider (disks are also geom providers) RW only once at a time, but you can open a geom provider RO as many times as you want simultaneously or even combine it with one (and only one) RW open. I'm not 100% sure about the umount, but I imagine that, as you mounted it read-write, when you unmount it, it attempts to update the superblock and ggate denies the write because the device is read-only. With regards to forcing the umount, have you tried umount -f /mnt? Finally, even if you manage somehow to open a filesystem RW from two different systems, don't do that. The UFS filesystem is designed so that the disk store is managed by a single kernel, and if you modify it from two or more different kernels at the same time, you will definitely get corruption and panics.