Re: zfs on geli vs. geli on zfs (via zvol)
Thanks to both C. P. and Pete for your responses. Comments inline:
Case 1.) is probably harmless, because geli would return a
corrupted sectors' content to zfs... which zfs will likely detect
because it wouldn't checksum correctly. So zfs will correct it
out of redundant storage, and write it back through a new
encryption. BE CAREFUL: don't enable hmac integrity checks
in geli, as that would prevent geli from returning corrupted
data and would result in hangs!
Perhaps the hmac integrity checks were related to the lack of reporting of
problems back to zfs that Pete referred to? Maybe we need someone with more
technical experience with the filesystem / disk access infrastructure to weigh
in, but it still doesn't seem clear to me what the best option is.
Case 2.) is a bigger problem. If a sector containing vital
geli metadata (perhaps portions of keys?) gets corrupted,
and geli had no way to detect and/or correct this (e.g. by
using redundant sectors on the same .eli volume!), the whole
.eli, or maybe some stripes out of it, could become useless.
ZFS couldn't repair this at all... at least not automatically.
You'll have to MANUALLY reformat the failed .eli device, and
resilver it from zfs redundant storage later.
This is precisely the kind of thing that made me think about putting zfs
directly on the disks instead of geli... This, and other unknown issues that
could crop up and are out of geli's ability to guard against.
There may be other failure modes involved as well. I don't know.
But in most practical day to day uses, with enough redundancy
and regular backups, a zfs-over-geli should be good enough.
I understand the point here, but I'm specifically thinking about my backup
server. As I understand it, part of the purpose of zfs is to be reliable
enough to run on a backup server itself, given some redundancy as you say.
Perhaps asking for encryption as well is asking too much (at least, unless zfs
v30 with zfs-crypto ever gets open-sourced and ported) but I'd really like to
maintain zfs' stability while also having an option for encryption.
I wouldn't put {zfs,ufs}-over-geli-over-raw-zpool though, as this
would involve considerable overhead, IMHO. In this case, I'd
rather use a gmirror as a backend, as in a setup:
{zfs,ufs}-over-geli-over-{gmirror,graid3}
or something similar. But I've never tried this though.
I understand about the overhead, but I'm interested in using zfs via a zraid to
avoid using gmirror or graid3, because of the benefits (detection of silent
corruption, etc.) that you get with a zraid. I think your suggestion is a
pretty good one in terms of performance/reliability tradeoff, though. In my
specific case I'm more likely to pay a performance cost instead of a
reliability cost, but only because my server spends most of its time hanging
around idling, and throughput isn't really an issue. Thanks regardless, though.
Todd___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
zfs on geli vs. geli on zfs (via zvol)
I've been thinking about how to best combine encryption and zfs on freebsd, and though I've seen some discussion about each individual option, I haven't found an explicit compare/contrast. I'm thinking of either encryption the devices directly via geli and then making a zfs pool of the foo.eli devices once they're geli attached (zfs on geli) or making a zfs pool of the unencrypted devices and providing a zvol from the pool as a raw device which I can then use geli to encrypt, and lay a ufs (or even another zfs) filesystem down on this (geli on zfs). While zfs on geli is less complex (in the sense that geli on zfs involves two layers of filesystems), I'm concerned as to whether encrypting the device will somehow affect zfs' ability to detect silent corruption, self-heal, or in any other way adversely affect zfs' functionality. In my mind, if I use geli on zfs, then I've got zfs directly on a device and the zvol it's providing will be transparently gaining the benefits of zfs' various features, providing a safety layer against device failure and silent corruption that I'm not sure if geli would detect. In a simpler sense, the question is this: if there is some damage to the device that zfs could putatively work around, if I were to have geli directly on that device, is it the case that geli would _not_ provide this protection and the device would be less robust than if it had had zfs directly on it? If this is not the case, then it seems clear to me that the less complicated zfs on geli route is the way to go, but I'm curious if anyone has any input on this. Thanks! Todd ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
jdk15/jdk16 build problems on amd64, 7.2-RELEASE
I've recently been unable to get jdk15 and jdk16 to build, with some very cryptic errors (if any, really) being reported. I've pasted a build log for jdk16 here, since it's about 9100 lines long: http://paste2.org/p/224897 This seems to be the relevant portion: cd bsd_amd64_compiler2/product gmake -w gmake[4]: Entering directory `/usr/ports/java/jdk16/work/control/build/ bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. gmake[4]: *** [../generated/MakeDeps.class] Killed: 9 gmake[4]: *** Deleting file `../generated/MakeDeps.class' gmake[4]: Leaving directory `/usr/ports/java/jdk16/work/control/build/ bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' gmake[3]: *** [product] Error 2 gmake[3]: Leaving directory `/usr/ports/java/jdk16/work/control/build/ bsd-amd64/hotspot/outputdir' gmake[2]: *** [generic_build2] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk16/work/hotspot/make' gmake[1]: *** [product] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk16/work/hotspot/make' gmake: *** [hotspot-build] Error 2 *** Error code 2 Stop in /usr/ports/java/jdk16. *** Error code 1 Stop in /usr/ports/java/jdk16. I don't see anything about this in the PRs or google, so any help would be appreciated. I'm not sure how to do the -Xlint thing it suggests, so I haven't tried that yet, but I can do so if someone tells me what I need to tweak to pull it off. Thanks! Todd PS- I've written to ports-bugs about this as well, so please bear with me if this is the wrong forum; I just like my chances of getting a response here better. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: jdk15/jdk16 build problems on amd64, 7.2-RELEASE
Hmm... Well, this machine has 6GB of memory. I just killed firefox and other processes requiring significant memory and tried again, watching top. It didn't drop below 2GB inactive memory, and the 4GB of swap wasn't touched, so I kind of doubt that's the problem. For kicks, I'll try rebooting the machine and building again, just in case something funny is going on. Todd Dan Nelson wrote: In the last episode (May 26), Todd Wasson said: I've recently been unable to get jdk15 and jdk16 to build, with some very cryptic errors (if any, really) being reported. I've pasted a build log for jdk16 here, since it's about 9100 lines long: http://paste2.org/p/224897 This seems to be the relevant portion: cd bsd_amd64_compiler2/product gmake -w gmake[4]: Entering directory `/usr/ports/java/jdk16/work/control/build/ bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. gmake[4]: *** [../generated/MakeDeps.class] Killed: 9 Something sent a KILL signal to your process. Maybe you ran out of memory and the kernel killed the largest process it saw? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: jdk15/jdk16 build problems on amd64, 7.2-RELEASE
Unsurprisingly, rebooting made no difference. Dang. It is somewhat surprising that it's getting SIGKILLed and not SIGTERMed though; at least I presume that's what the 9 means... Todd Dan Nelson wrote: In the last episode (May 26), Todd Wasson said: I've recently been unable to get jdk15 and jdk16 to build, with some very cryptic errors (if any, really) being reported. I've pasted a build log for jdk16 here, since it's about 9100 lines long: http://paste2.org/p/224897 This seems to be the relevant portion: cd bsd_amd64_compiler2/product gmake -w gmake[4]: Entering directory `/usr/ports/java/jdk16/work/control/build/ bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. gmake[4]: *** [../generated/MakeDeps.class] Killed: 9 Something sent a KILL signal to your process. Maybe you ran out of memory and the kernel killed the largest process it saw? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
