I''m planning on running FreeBSD in VirtualBox (with a Linux host) and
giving it
raw disk access to four drives, which I plan to configure as a raidz2 volume.
On top of that, I''m considering using encryption. I understand that
ZFS doesn''t
yet natively support encryption, so my idea was to set each drive up with
full-disk encryption in the Linux host (e.g., using TrueCrypt or dmcrypt), mount
the encrypted drives, and then give the virtual machine access to the virtual
unencrypted drives. So the encryption would be transparent to FreeBSD.
However, I don''t know enough about ZFS to know if this is a good idea.
I know
that I need to specifically configure VirtualBox to respect cache flushes, so
that data really is on disk when ZFS expects it to be. Would putting ZFS on top
of full-disk encryption like this cause any problems? E.g., if the (encrypted)
physical disk has a problem and as a result a larger chunk of the unencrypted
data is corrupted, would ZFS handle that well? Are there any other possible
consequences of this idea that I should know about? (I''m not too
worried about
any hits in performance; I won''t be reading or writing heavily, nor in
time-sensitive applications.)
I should add that since this is a desktop I''m not nearly as worried
about
encryption as if it were a laptop (theft or loss are less likely), but
encryption would still be nice. However, data integrity is the most important
thing (I''m storing backups of my personal files on this), so if
there''s a chance
that ZFS wouldn''t handle errors well when on top of encryption,
I''ll just go
without it.
Thanks,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100710/94b6787d/attachment.html>
On Sun, Jul 11, 2010 at 11:51 AM, Michael Johnson <mjjohnson.geo at yahoo.com> wrote:> I''m planning on running FreeBSD in VirtualBox (with a Linux host) and giving > it raw disk access to four drives, which I plan to configure as a raidz2 > volume. > On top of that, I''m considering using encryption. ?I understand that ZFS > doesn''t yet natively support encryption, so my idea was to set each drive up > with full-disk encryption in the Linux host (e.g., using TrueCrypt or > dmcrypt), mount the encrypted drives, and then give the virtual machine > access to the virtual unencrypted drives. ?So the encryption would be > transparent to FreeBSD. > However, I don''t know enough about ZFS to know if this is a good idea. ?I > know that I need to specifically configure VirtualBox to respect cache > flushes, so that data really is on disk when ZFS expects it to be. ?Would > putting ZFS on top of full-disk encryption like this cause any problems? > ?E.g., if the (encrypted) physical disk has a problem and as a result a > larger chunk of the unencrypted data is corrupted, would ZFS handle that > well? ?Are there any other possible consequences of this idea that I should > know about? ?(I''m not too worried about any hits in performance; I won''t be > reading or writing heavily, nor in time-sensitive applications.) > I should add that since this is a desktop I''m not nearly as worried about > encryption as if it were a laptop (theft or loss are less likely), but > encryption would still be nice. ?However, data integrity is the most > important thing (I''m storing backups of my personal files on this), so if > there''s a chance that ZFS wouldn''t handle errors well when on top of > encryption, I''ll just go without it. > Thanks, > Michael >you can also create zfs on top of GELI[1][2] devices. Create the encrypted disks first and then use that to create zpool. Exact steps (assuming single disk, da1): - create the key # dd if=/dev/random of=/root/da1.key bs=64 count=1 - initialize GELI disk, if you want to only use the key as authentication method or automatically attach on boot, check the reference links for initialization and configuration (-K and -b) # geli init -s 4096 -K da1.key /dev/da1 - attach GELI disk # geli attach -k da1.key /dev/da1 - create zpool, either directly on geli disk or by creating it on top of GPT>>direct:# zpool create securepool da1.eli>>on top of GPT:# gpart create -s gpt da1.eli # gpart add -t freebsd-zfs da1.eli # zpool create securepool da1.elip1 - adjust rc.conf and loader.conf accordingly Another tutorial: http://forums.freebsd.org/showthread.php?t=2775 [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html [2] http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
I''m planning on running FreeBSD in VirtualBox (with a Linux host) and giving it raw disk access to four drives, which I plan to configure as a raidz2 volume. Wouldn''t it be better or just as good to use fuse-zfs for such a configuration? I/O from VirtualBox isn''t really very good, but then, I haven''t tested the linux/fbsd configuration... Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100711/5c393f44/attachment.html>
On Sun, Jul 11, 2010 at 4:21 AM, Roy Sigurd Karlsbakk <roy at karlsbakk.net> wrote:>> I''m planning on running FreeBSD in VirtualBox (with a Linux host) and giving >> it raw disk access to four drives, which I plan to configure as a raidz2 >> volume. > > Wouldn''t it be better or just as good to use fuse-zfs for such a > configuration? I/O from VirtualBox isn''t really very good, but then, I > haven''t tested the linux/fbsd configuration...ZFS-FUSE is horribly unstable, although that''s more an indication of the stability of the storage stack on Linux. We''ve been testing it at work to see how dedupe support will affect our FreeBSD+ZFS storage servers. We can''t keep it (Linux+ZFS) running for more than a few days. Drives drop off at random, the pool locks up, resilvers never complete. When it does work, it works nicely. It''s just hard to keep it running. You definitely want to do the ZFS bits from within FreeBSD. -- Freddie Cash fjwcash at gmail.com
on 11/07/2010 14:21 Roy Sigurd Karlsbakk said the following:> > ------------------------------------------------------------------------ > > I''m planning on running FreeBSD in VirtualBox (with a Linux host) > and giving it raw disk access to four drives, which I plan to > configure as a raidz2 volume. > > Wouldn''t it be better or just as good to use fuse-zfs for such a > configuration? I/O from VirtualBox isn''t really very good, but then, I > haven''t tested the linux/fbsd configuration...Hmm, an unexpected question IMHO - wouldn''t it better to just install FreeBSD on the hardware? :-) If an original poster is using Linux as a host OS, then probably he has some very good reason to do that. But performance and etc -wise, directly using FreeBSD, of course, should win over fuse-zfs. Right? [Installing and maintaining one OS instead of two is the first thing that comes to mind] -- Andriy Gapon
On Jul 11, 2010, at 5:11 PM, Freddie Cash <fjwcash at gmail.com> wrote:> ZFS-FUSE is horribly unstable, although that''s more an indication of > the stability of the storage stack on Linux.Not really, more an indication of the pseudo-VFS layer implemented in fuse. Remember fuse provides it''s own VFS API separate from the Linux VFS API so file systems can be implemented in user space. Fuse needs a little more work to handle ZFS as a file system. -Ross
on 11/07/2010 15:54 Andriy Gapon said the following:>on 11/07/2010 14:21 Roy Sigurd Karlsbakk said the following: >> >> I''m planning on running FreeBSD in VirtualBox (with a Linux host) >> and giving it raw disk access to four drives, which I plan to >> configure as a raidz2 volume. >> >> Wouldn''t it be better or just as good to use fuse-zfs for such a >> configuration? I/O from VirtualBox isn''t really very good, but then, I >> haven''t tested the linux/fbsd configuration...Like Freddie already mentioned, I''d heard that fuse-zfs wasn''t really all that good of an option, and I wanted something that was more stable/reliable.>Hmm, an unexpected question IMHO - wouldn''t it better to just install FreeBSDon>the hardware? :-) >If an original poster is using Linux as a host OS, then probably he has some >very good reason to do that. But performance and etc -wise, directly using >FreeBSD, of course, should win over fuse-zfs. Right? > >[Installing and maintaining one OS instead of two is the first thing that comes >to mind]I''m going with a virtual machine because the box I ended up building for this was way more powerful than I needed for just my file server; thus, I figured I''d use it as a personal machine too. (I wanted ECC RAM, and there just aren''t that many motherboards that support ECC RAM that are also really cheap and low-powered.) And since I''m much more comfortable with Linux, I wanted to use it for the "personal" side of things.
Freddie Cash wrote:> You definitely want to do the ZFS bits from within FreeBSD.Why not using ZFS in OpenSolaris? At least it has most stable/tested implementation and also the newest one if needed?
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Freddie Cash > > ZFS-FUSE is horribly unstable,That may be true. I couldn''t say.> although that''s more an indication of > the stability of the storage stack on Linux.But this, I take issue with. Ext3 isn''t unstable. It may not be as awesome as ZFS, but it isn''t unstable. And the same goes for all the other storage and filesystems in Linux. Years ago, when I first started using Gimp, it was stable in Linux and not stable in Windows. I went to gimp.org, and looked at the FAQ''s, and FAQ #1 said "Gimp is unstable on windows." And the reply was "Everything is unstable on Windows." Which was simply false. It was a developer (or group of developers) expressing a biased point of view, and blaming a platform that they were not fond of. In later versions of gimp, even on the same version of Windows, gimp evolved into something that was stable. To simply blame gimp, or simply blame windows, both positions are not accurate. The truth is, gimp was stable on linux, and other apps were stable on windows. The truth is, there was something unstable in the interaction between the two.
Nikola M wrote:>Freddie Cash wrote: >> You definitely want to do the ZFS bits from within FreeBSD. >Why not using ZFS in OpenSolaris? At least it has most stable/tested >implementation and also the newest one if needed?I''d love to use OpenSolaris for exactly those reasons, but I''m wary of using an operating system that may not continue to be updated/maintained. If OpenSolaris had continued to be regularly released after Oracle bought Sun I''d be choosing it. As it is, I don''t want to be pessimistic, but the doubt about OpenSolaris''s future is enough to make me choose FreeBSD instead. (I''m sure that such sentiments won''t make me popular here, but so far Oracle has been frustratingly silent on their plans for OpenSolaris.) At the very least, if FreeBSD doesn''t do what I want I can switch the system disk to OpenSolaris and keep using the same pool. (Right?) Going back to my original question: does anyone know of any problems that could be caused by using raidz on top of encrypted drives? If there were a physical read error, which would get amplified by the encryption layer (if I''m understanding full-disk encryption correctly, which I may not be), would ZFS still be able to recover?
On Mon, 2010-07-12 at 09:41 -0700, Michael Johnson wrote:> Nikola M wrote: > >Freddie Cash wrote: > >> You definitely want to do the ZFS bits from within FreeBSD. > >Why not using ZFS in OpenSolaris? At least it has most stable/tested > >implementation and also the newest one if needed? > > > I''d love to use OpenSolaris for exactly those reasons, but I''m wary of using an > operating system that may not continue to be updated/maintained. If OpenSolaris > had continued to be regularly released after Oracle bought Sun I''d be choosing > it. As it is, I don''t want to be pessimistic, but the doubt about OpenSolaris''s > future is enough to make me choose FreeBSD instead. (I''m sure that such > sentiments won''t make me popular here, but so far Oracle has been frustratingly > silent on their plans for OpenSolaris.) At the very least, if FreeBSD doesn''t > do what I want I can switch the system disk to OpenSolaris and keep using the > same pool. (Right?) > > Going back to my original question: does anyone know of any problems that could > be caused by using raidz on top of encrypted drives? If there were a physical > read error, which would get amplified by the encryption layer (if I''m > understanding full-disk encryption correctly, which I may not be), would ZFS > still be able to recover? >I don''t know about ramifications (though I suspect that a broadening error scope would decrease ZFS'' ability to isolate and work around problematic regions on the media), but one thing I do know. If you use FreeBSD disk encryption below ZFS, then you won''t be able able to import your pools to another implementation -- you will be stuck with FreeBSD. Btw, if you want a commercially supported and maintained product, have you looked at NexentaStor? Regardless of what happens with OpenSolaris, we aren''t going anywhere. (Full disclosure: I''m a Nexenta Systems employee. :-) -- Garrett> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Mon, Jul 12, 2010 at 10:00 AM, Garrett D''Amore <garrett at nexenta.com>wrote:> Btw, if you want a commercially supported and maintained product, have > you looked at NexentaStor? Regardless of what happens with OpenSolaris, > we aren''t going anywhere. (Full disclosure: I''m a Nexenta Systems > employee. :-) >I''m trying to decide for myself when I''ll give up on Oracle releasing another dev or release build and moving to something like Nexenta Core. I actually *like* the Solaris user space, so GNU/Debian userspace isn''t that compelling for me. I see it enough at work that using something different at home is novel and helps keep me honest. I also don''t see a roadmap for the upcoming releases or what release of Debian or Ubuntu they''ll be based on. -B -- Brandon High : bhigh at freaks.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100712/6ee9b70d/attachment.html>
On Mon, 2010-07-12 at 12:55 -0700, Brandon High wrote:> On Mon, Jul 12, 2010 at 10:00 AM, Garrett D''Amore > <garrett at nexenta.com> wrote: > Btw, if you want a commercially supported and maintained > product, have > you looked at NexentaStor? Regardless of what happens with > OpenSolaris, > we aren''t going anywhere. (Full disclosure: I''m a Nexenta > Systems > employee. :-) > > > I''m trying to decide for myself when I''ll give up on Oracle releasing > another dev or release build and moving to something like Nexenta > Core. > > > I actually *like* the Solaris user space, so GNU/Debian userspace > isn''t that compelling for me.The distinction is quickly shrinking. I think the trend has been to value compatibility with Linux over compatibility with legacy Solaris, at least for OpenSolaris and probably also for whatever next release of Solaris might be forthcoming. (At least at the shell/command line level. The *library* level -i.e. C API - is a totally different story, of course.)> I see it enough at work that using something different at home is > novel and helps keep me honest. I also don''t see a roadmap for the > upcoming releases or what release of Debian or Ubuntu they''ll be based > on.We have plans centered around 3.0.x and 3.1, and our plans for 4.0 are still forming. For 3.0. and 3.1, we will remain based on the same release of Ubuntu. For 4.0, there will be a major change, but the ultimate base of this is still under debate. I don''t know if marketing has released any timelines yet, so I won''t do so here. But you should contact our sales group if you want to find out more -- they can probably say more than I can. - Garrett> > > -B > > -- > Brandon High : bhigh at freaks.com >
Garrett wrote:>I don''t know about ramifications (though I suspect that a broadening >error scope would decrease ZFS'' ability to isolate and work around >problematic regions on the media), but one thing I do know. If you use >FreeBSD disk encryption below ZFS, then you won''t be able able to import >your pools to another implementation -- you will be stuck with FreeBSD.This is an excellent point. Geli isn''t a good option for me, then, though using encryption outside of the VM would still work.>Btw, if you want a commercially supported and maintained product, have >you looked at NexentaStor? Regardless of what happens with OpenSolaris, >we aren''t going anywhere. (Full disclosure: I''m a Nexenta Systems >employee. :-)I probably ought to consider other OpenSolaris alternatives, like NexentaStor. (Though I''d be looking at the free version, not the commercial one: this is just for personal use, despite how careful I''m being with it. :) ) However (and please correct me if I''m wrong), isn''t your future still tied to the future of OpenSolaris? The code is open, of course, but my understanding is that there isn''t the same kind of developer community supporting OpenSolaris itself that you see with Linux (or even the BSDs). In other words, if Oracle stops development of OpenSolaris, there wouldn''t be enough developers still working on it to keep it from stagnating. Or are you saying that you employ enough kernel hackers to keep up even without Oracle? (I am admittedly ignorant about the OpenSolaris developer community; this is all based on others'' statements and opinions that I''ve read.) Michael
While we''re on the topic, has anyone used ZFS much with Vormetric''s encryption product? Any feedback? Doug Linder ---------- Learn more about Merchant Link at www.merchantlink.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.
> Btw, if you want a commercially supported and maintained product, have > you looked at NexentaStor? Regardless of what happens with OpenSolaris, > we aren''t going anywhere. (Full disclosure: I''m a Nexenta Systems > employee. :-) > > -- GarrettHi Garrett, I would like to know why you think Nexenta would continue to stay if OpenSolaris goes away. I feel the fate of Nexenta is no different than the fate of my startup company. Both of us are heavily dependent on zfs. And we know OpenSolaris version of zfs is the most stable version. Any business that is dependent on zfs must plan for two things as a contingency: 1. Look for an alternative for zfs 2. Look for an alternative for OpenSolaris Preferably both need to be open source with no licenses attached. Ideally, zfs lawsuit will be put to rest and Oracle will commit for continuing to support OpenSolaris. Regards, Peter -- This message posted from opensolaris.org
On Wed, 2010-07-14 at 01:06 -0700, Peter Taps wrote:> > Btw, if you want a commercially supported and maintained product, have > > you looked at NexentaStor? Regardless of what happens with OpenSolaris, > > we aren''t going anywhere. (Full disclosure: I''m a Nexenta Systems > > employee. :-) > > > > -- Garrett > > Hi Garrett, > > I would like to know why you think Nexenta would continue to stay if OpenSolaris goes away. > > I feel the fate of Nexenta is no different than the fate of my startup company. Both of us are heavily dependent on zfs. And we know OpenSolaris version of zfs is the most stable version. > > Any business that is dependent on zfs must plan for two things as a contingency: > > 1. Look for an alternative for zfs > 2. Look for an alternative for OpenSolaris > > Preferably both need to be open source with no licenses attached. > > Ideally, zfs lawsuit will be put to rest and Oracle will commit for continuing to support OpenSolaris. > > Regards, > PeterNexenta is investing in the technology within OpenSolaris heavily -- and we are working on an effort which will decouple our product from a hard dependency on bits from Oracle''s Solaris. I can''t talk too much about this right now, but I will probably have a lot more to say about this early next month. Upshot of this is is that if OpenSolaris goes away, we will continue to be able to work with the source code we have (plus in house source code we are creating to replace certain bits we don''t have source to today!), so that our future is not so dependent on Oracle''s continued good will. We''re also hiring in engineering and growing a world class kernel team, so we can continue to sustain and improve the code even if Oracle were to pull the plug on OpenSolaris sources. We already have innovations in our code base which Oracle''s tree lacks -- even though we have made our sources for the OS available for Oracle. That said, I feel extremely confident that while Oracle *may* pull the plug on this "OpenSolaris" thing, the *source* code which makes up the critical platform bits (ON) for both Solaris and OpenSolaris will probably continue to be released as source code going forward. There are simply too many positive benefits to its customers, and frankly too many customers would leave Oracle (not just Solaris, but go from Oracle to DB2) if Oracle were to pull a stunt such as ceasing the delivery of source code. (And further, even though the "request-sponsor" process has been a dismal failure, I suspect that there will always be a way for contributors to send improvements back to Oracle, even if the formal OpenSolaris process for it were to go away.) Now, the question of ZFS is IMO a lot more concerning. If we were suddenly unable to continue to work with ZFS due to patent considerations, there is no question that this would have a devastating impact on our business. It would have a devastating impact on Solaris too. We have mitigation plans in place for that eventuality which I cannot discuss, but it would be extremely painful to us, as well as everyone else in this ecosystem. The good news is that so far it seems likely that NetApp''s suit will fail. - Garrett
On Wed, 14 Jul 2010, Peter Taps wrote:> > Any business that is dependent on zfs must plan for two things as a contingency: > > 1. Look for an alternative for zfs > 2. Look for an alternative for OpenSolarisThe existing OpenSolaris and zfs code bases are quite viable products today. If Oracle falters, there are lots of people familiar with SunOS source code and kernel development and it seems quite likely that OpenSolaris distributions would continue just as many other OS distributions do today (but under a new name). At the moment we are in a "wait and see" scenario, and it is not quite necessary to fork and create a truely independent distribution just yet. OpenSolaris is currently not left any more in the lurch than Solaris 10 is since paying Solaris 10 users are still wondering what happened to the U9 release which Sun had already promised. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/