Date: Sun, 14 Jan 2007 01:26:02 +0100 (CET) From: Christian Baer <christian.baer@informatik.uni-dortmund.de> To: freebsd-geom@freebsd.org Subject: Re: What does geli attach -a do? Message-ID: <eobtaq$821$1@nermal.rz1.convenimus.net> References: <eobdq1$74h$1@nermal.rz1.convenimus.net> <20070113202018.GK90718@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Jan 2007 21:20:18 +0100 Pawel Jakub Dawidek wrote: > It'll tell you exact offset and size where corrupted data were detected. > It won't help you bring you data back, it's a security feature, not a > reliability feature, but can be used also to detect silent data > corruptions. Does that mean, it could probably tell me what file was affected >> Does it make sense to use this in combination with a mirror? > If you're afraid of silent data corruptions, then yes. When one half of > the mirror will be corrupted and geli will detect it, gmirror will read > the data from the other half. I'm not more afraid of those than of any other sort of breakdowns. :-) These are computers. They work but they also fail from time to time. I've lost quite a few HDs during the years that I've been working with computers now. Not all of the HDs went on friendly terms. :-) Basicly, the information is quite important but subject to constant changes. That is why I want to mirror the data, so I can have a pretty good chance of getting the changes back that were made between to backups. The question if this made sense in combination with a mirror went in another direction: Can gmirror detect which drive is holding the "right" data and retrieve it should a drive die? > Unfortunately authentication-only mode is not supported in geli at the > moment, so you have encryption/decription overhead. > If you don't care about this overhead, and don't care about security, > this is how you can create such configuration: Well, actually, I do care for security. Geli is already set up on the mirrors. I'm a little worried that this feature will however run the crap out of the CPUs. :-) This is a Sun U60 we are talking about. Not really what you'd call a CPU-monster. Copying a big file over the network onto an encrypted partition runs at about 5-6MB/s and uses 80-90% of both CPUs. There aren't many reserves to go around while doing that. Regards Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eobtaq$821$1>