Date: Fri, 19 Dec 2008 16:49:45 -0500 From: "Michael Jung" <mikej@paymentallianceintl.com> To: "Ulf Lilleengen" <ulf.lilleengen@gmail.com>, "John-Mark Gurney" <jmg@funkthat.com> Cc: freebsd-geom@freebsd.org Subject: RE: Encrypting raid5 volume with geli Message-ID: <ADC733B130BF1D4A82795B6B3A2654E20128D8FE@exchange.paymentallianceintl.com> In-Reply-To: <20081214215913.GA3723@nobby> References: <20081212155023.GA82667@keira.kiwi-computer.com> <ADC733B130BF1D4A82795B6B3A2654E2777381@exchange.paymentallianceintl.com> <917871cf0812130559r6d423688q57287dd765d6edf4@mail.gmail.com> <20081214195649.GK34842@funkthat.com> <20081214215913.GA3723@nobby>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD 7.1-PRERELEASE #1: Fri Dec 19 09:04:23 EST 2008 With the new patch I can create UFS system and mount. I can also: (root@charon) /etc# geli init -P -K /root/test.key /dev/gvinum/test But when I try to attach it: (root@charon) /etc# geli attach -p -k /root/test.key /dev/gvinum/test (root@charon) /etc# mount /dev/gvinum/test.eli /mnt mount: /dev/gvinum/test.eli : Invalid argument (root@charon) /etc# (root@charon) /etc# geli list Geom name: gvinum/test.eli EncryptionAlgorithm: AES-CBC KeyLength: 128 Crypto: software UsedKey: 0 Flags: NONE Providers: 1. Name: gvinum/test.eli Mediasize: 127469303296 (119G) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: gvinum/test Mediasize: 127469303808 (119G) Sectorsize: 512 Mode: r1w1e1 (root@charon) /etc# --mikej Michael Jung Payment Alliance International 11857 Commonwealth Drive Louisville, KY 40299 502-212-4045 Work Voice 502-212-4004 Work Facsimile -----Original Message----- From: Ulf Lilleengen [mailto:ulf.lilleengen@gmail.com] Sent: Sunday, December 14, 2008 4:59 PM To: John-Mark Gurney Cc: Michael Jung; freebsd-geom@freebsd.org Subject: Re: Encrypting raid5 volume with geli On Sun, Dec 14, 2008 at 11:56:49AM -0800, John-Mark Gurney wrote: > 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.. > Yes, I agree. Michael, could you try the attached patch? It should fix the issue within gvinum itself. The previous change will have to be reverted too. -- Ulf Lilleengen CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ADC733B130BF1D4A82795B6B3A2654E20128D8FE>