Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Dec 2008 01:42:58 +0100
From:      "Ivan Voras" <ivoras@freebsd.org>
To:        "Ulf Lilleengen" <lulf@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r186038 - head/sbin/geom/misc
Message-ID:  <9bbcef730812141642m554913cau6121a2f51458a49f@mail.gmail.com>
In-Reply-To: <20081214211341.GA3575@nobby>
References:  <200812131414.mBDEEu0A031376@svn.freebsd.org> <20081214192100.GB16926@garage.freebsd.pl> <20081214211341.GA3575@nobby>

next in thread | previous in thread | raw e-mail | index | archive | help
2008/12/14 Ulf Lilleengen <lulf@freebsd.org>:
> 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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730812141642m554913cau6121a2f51458a49f>