From owner-svn-src-head@FreeBSD.ORG Mon Dec 15 00:43:01 2008 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8241065675; Mon, 15 Dec 2008 00:43:01 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id 64E268FC18; Mon, 15 Dec 2008 00:43:00 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by bwz7 with SMTP id 7so5749264bwz.19 for ; Sun, 14 Dec 2008 16:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=kXj3qOtIe3yBa25CTHCtt/hwdLqjSA3FR2tij/Nk9EE=; b=WxdhtVST4qmf06G0KuZQzR5JU7aY85iM85EuqeAJLKhLy/tSUH3JJEaeYTfH8FIqJQ ZZSdeJbi34p1Mm6TiHBYQVVMln92IsWbyDd43Va4Ixo9nooi6YsvXV9tqr//zMWCvpfZ aFEEPgk8Kebu4bGmlQl4B++y3gaow/SIklxFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=UOKLhoepeJRYpZfUiR6ZeRSF8sUToesE2aGYFSG/lRbDCDcE7kalxFRrepfsX/DOYz jnIeXiYaS37Tt8inDWUrEnKwfcZMYMaE5BqeO3lmQ1DOBXbDsaWHxnzxdjKWH4SCcVeh zacsRcTFmcm2107NEyDJI3S2PNnOnN67yB/iQ= Received: by 10.181.134.12 with SMTP id l12mr2322238bkn.26.1229301778951; Sun, 14 Dec 2008 16:42:58 -0800 (PST) Received: by 10.181.203.1 with HTTP; Sun, 14 Dec 2008 16:42:58 -0800 (PST) Message-ID: <9bbcef730812141642m554913cau6121a2f51458a49f@mail.gmail.com> Date: Mon, 15 Dec 2008 01:42:58 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Ulf Lilleengen" In-Reply-To: <20081214211341.GA3575@nobby> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812131414.mBDEEu0A031376@svn.freebsd.org> <20081214192100.GB16926@garage.freebsd.pl> <20081214211341.GA3575@nobby> X-Google-Sender-Auth: ba9bcd3d69489adf Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r186038 - head/sbin/geom/misc X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2008 00:43:01 -0000 2008/12/14 Ulf Lilleengen : > On Sun, Dec 14, 2008 at 08:21:01PM +0100, Pawel Jakub Dawidek wrote: >> On Sat, Dec 13, 2008 at 02:14:56PM +0000, Ulf Lilleengen wrote: >> > Author: lulf >> > Date: Sat Dec 13 14:14:56 2008 >> > New Revision: 186038 >> > URL: http://svn.freebsd.org/changeset/base/186038 >> > >> > Log: >> > - When writing metadata to a geom provider, open the it as read-write since it >> > might do subsequent reads from other providers. This stopped geli (and >> > probably other classes using g_metadata_store as well) from being put on top >> > of gvinum raid5 volumes. >> > >> > Note: >> > The reason it fails in the gvinum raid5 case is that gvinum will read back the >> > old parity stripe before calculating the new parity stripe to be written out >> > again. The write will then fail because the underlying disk to be read is >> > opened write only. >> >> I think we discussed this in the past. In my opinion this change is >> incorrect. The intend here is to only write something, that's why I use >> O_WRONLY. If gvinum/raid5 needs also read something to satisfy the >> write, this is gvinum/raid5's internal detail and should be handled >> there. RAID5 by design needs to read before it can write (in most >> cases), does it mean that the O_WRONLY flag became bogus suddenly? No. >> The flag given to open(2) describes caller's intend, not provider's >> internals. >> > Hmm, I understand your reasoning. But how can gvinum read from these internal > providers then? Is there some way to override this internally in GEOM? Can't you just convert (0,1,x) permission to (1,1,x) in your g_access? (i.e. convert all write-only openings to read-write)