Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Dec 2008 11:56:49 -0800
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Ulf Lilleengen <ulf.lilleengen@gmail.com>
Cc:        Michael Jung <mikej@paymentallianceintl.com>, freebsd-geom@freebsd.org
Subject:   Re: Encrypting raid5 volume with geli
Message-ID:  <20081214195649.GK34842@funkthat.com>
In-Reply-To: <917871cf0812130559r6d423688q57287dd765d6edf4@mail.gmail.com>
References:  <20081212155023.GA82667@keira.kiwi-computer.com> <ADC733B130BF1D4A82795B6B3A2654E2777381@exchange.paymentallianceintl.com> <917871cf0812130559r6d423688q57287dd765d6edf4@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Ulf Lilleengen wrote this message on Sat, Dec 13, 2008 at 14:59 +0100:
> Then, I discovered in geom userland code that it opens the disk where
> metadata should be written in write only mode. Then I discovered the reason:
> gvinum tries to write to the stripe in question, but has to read back the
> parity data from one of the other stripes. But, they are opened O_WRONLY, so
> the request fails. I tried opening the device as O_RDWR, and everything is
> find.

Isn't this a bug in gvinum that it lets a disk be opened in O_WRONLY,
when it needs read permissions?  Shouldn't it add the read permission
to it's provider open, and let the underlying fd still be O_WRONLY (so
the OS will prevent any reads) or it should be documented in the
gvinum man page that raid5 volumes cannot be opened in O_WRONLY mode..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



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