2008/12/14 Ulf Lilleengen <l...@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) _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"