[zfs-discuss] Why root zone can't be on ZFS for upgrade ?
Hi, Something is unclear in Solaris containers and Solaris ZFS docs Two extracts : http://docs.sun.com/app/docs/doc/819-5461/6n7ht6qsm?q=zonea=view Consider the following interactions when working with ZFS on a system with Solaris zones installed: A ZFS file system that is added to a non-global zone must have its mountpoint property set to legacy. A ZFS file system cannot serve as zone root because of issues with the Solaris upgrade process. Do not include any system-related software that is accessed by the patch or upgrade process in a ZFS file system that is delegated to a non-global zone. http://docs.sun.com/app/docs/doc/817-1592/6mhahuop2?a=view 4. Set the zone path, /export/home/my-zone in this procedure. zonecfg:my-zone set zonepath=/export/home/my-zone Do not place the zonepath on ZFS for this release. I can't understand why the upgrade process need to have non-global root zone on anything else than zfs. Does the boot cdrom can't mount ZFS volumes ? This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] creating zvols in a non-global zone (or 'Doctor, it hurts when I do this')
On 06/09/06, Eric Schrock [EMAIL PROTECTED] wrote: On Wed, Sep 06, 2006 at 04:23:32PM +0100, Dick Davies wrote: a) prevent attempts to create zvols in non-global zones b) somehow allow it (?) or c) Don't do That I vote for a) myself - should I raise an RFE? Yes, that was _supposed_ to be the original behavior, and I thought we had it working that way at one point. Apparently I'm imagining things, or it got broken somewhere along the way. Please file a bug. For the record, it's filed as : http://bugs.opensolaris.org/view_bug.do?bug_id=6498038 -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Pawel Jakub Dawidek wrote: I like the idea, I really do, but it will be s expensive because of ZFS' COW model. Not only file removal or truncation will call bleaching, but every single file system modification... Heh, well, if privacy of your data is important enough, you probably don't care too much about performance. I'm not sure it will be that slow, the bleaching will be done in a separate (new) transaction group in most (probably all) cases anyway so it shouldn't really impact your write performance unless you are very I/O bound and already running near the limit. However this is speculation until someone tries to implement this! I for one would prefer encryption, which may turns out to be much faster than bleaching and also more secure. At least NIST, under I believe the guidance of the NSA, does not consider that encryption and key destruction alone is sufficient in all cases. Which is why I'm proposing this as complementary. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Frank Hofmann wrote: And this kind of deep bleaching would also break if you use snapshots - how do you reliably bleach if you need to keep the all of the old data around ? You only could do so once the last snapshot is gone. Kind of defeating the idea - automatic but delayed indefinitely till operator intervention (deleting the last snapshot). Right that doesn't break snapshots at all in fact it is working exactly like snapshots work today anyway. With user delegation (when is this integrating BTW?) the file system operator might be the end user anyway. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
On Thu, Dec 21, 2006 at 03:31:59PM +, Darren J Moffat wrote: Pawel Jakub Dawidek wrote: I like the idea, I really do, but it will be s expensive because of ZFS' COW model. Not only file removal or truncation will call bleaching, but every single file system modification... Heh, well, if privacy of your data is important enough, you probably don't care too much about performance. I'm not sure it will be that slow, the bleaching will be done in a separate (new) transaction group in most (probably all) cases anyway so it shouldn't really impact your write performance unless you are very I/O bound and already running near the limit. However this is speculation until someone tries to implement this! Yes, bleaching lazily would help with performance. You might even delay bleaching for very long periods of time if you want, as long as there's an interface by which to request that all outstanding free-but-not-yet- bleached blocks be bleached immediately and synchronously. I for one would prefer encryption, which may turns out to be much faster than bleaching and also more secure. At least NIST, under I believe the guidance of the NSA, does not consider that encryption and key destruction alone is sufficient in all cases. Which is why I'm proposing this as complementary. James makes a good argument that this scheme won't suffice for customers who need that level of assurance. I'm inclined to agree. For customers who don't need that level of assurance then encryption ought to suffice. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [security-discuss] Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto
james hughes wrote: On Dec 20, 2006, at 1:37 PM, Bill Sommerfeld wrote: On Wed, 2006-12-20 at 03:21 -0800, james hughes wrote: This would be mostly a vanity erase not really a serious security erase since it will not over write the remnants of remapped sectors. Yup. As usual, your milage will vary depending on your threat model. My gut feel is that there's a cost-benefit sweet spot near a mechanism which provides for the prompt overwrite of recently deallocated blocks with either zeros or newly allocated data, What happens when the machine crashes after the blocks are deallocated but before they are scrubbed? Is that covered? I would hope so, and I believe this would fall out from the all ways consistent on disk transactional nature of ZFS. with more intensive bleaching reserved for when disks are taken out of service. If I had a choice of destroying disks or running a program that will take hours to complete (with dubious quality), I would (and do) choose to destroy the disk. Not all customers can make that same choice though. Some times you need to give the broken disk back to the vendor as part of the replacement otherwise you are buying a new disk. We aren't talking about very high security environments here, and even in those the NIST recommendations suggest you do something like this AND physically destroy the disk. This is more targeted at the financial, education and home user worlds than military or other high sensitive environments. It is all about using the appropriate tool given the risks you are willing to take for a given cost of physical and time resources. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Torrey McMahon wrote: Darren Reed wrote: Darren, A point I don't yet believe that has been addressed in this discussion is: what is the threat model? Are we targetting NIST requirements for some customers or just general use by everyday folks? Even higher level: What problem are you/we trying to solve? Solving the erase that data form this disk problem while leaving the disk usable. Without requiring it be done to the whole disk, or even whole disk like thing that format(1M) can see. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Darren Reed wrote: Darren, A point I don't yet believe that has been addressed in this discussion is: what is the threat model? There are several and this is about providing functionality so that customers can choose what they want to use when it is appropriate. Using format(1M) for whole disk erasure isn't always suitable or even possible. Are we targetting NIST requirements for some customers or just general use by everyday folks? Both, NIST requires disk overwrite in addition to physical destruction in some cases. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Difference between ZFS and UFS with one LUN from a SAN
Hello Shawn, Thursday, December 21, 2006, 4:28:39 PM, you wrote: SJ All, SJ I understand that ZFS gives you more error correction when using SJ two LUNS from a SAN. But, does it provide you with less features SJ than UFS does on one LUN from a SAN (i.e is it less stable). With only one LUN you still get error detection which UFS doesn't give you. You still can use snapshots, clones, quotas, etc. so in general you still have more features than UFS. Now when in comes to stability - depends. UFS is for years in use while ZFS much younger. More and more people are using ZFS in production and while there're some corner cases mostly performance related, it works really good. And I haven't heard of verified data lost due to ZFS. I've been using ZFS for quite some time (much sooner than it was available in SX) and I haven't also lost any data. -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Nicolas Williams wrote: James makes a good argument that this scheme won't suffice for customers who need that level of assurance. I'm inclined to agree. For customers who don't need that level of assurance then encryption ought to suffice. Has anyone other than me actually read the current NIST guidelines on this ? [ the url was in my original email message ]. The current NIST guidelines, or at least my reading of it, says that even if you are using encryption and even if you are going to do physical destruction you still need to do something like this. So this is complementary to encrypting the data - not that we can't in ZFS encryption ALL ZFS metadata (we should be able to encrypt all the file system relevant meta data) at least thats my current belief based on my knowledge of ZFS. Maybe doing this in ZFS isn't necessary and what we have with format(1M) purge/analyze is the correct user interface. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
On Thu, Dec 21, 2006 at 03:47:07PM +, Darren J Moffat wrote: Nicolas Williams wrote: James makes a good argument that this scheme won't suffice for customers who need that level of assurance. I'm inclined to agree. For customers who don't need that level of assurance then encryption ought to suffice. Has anyone other than me actually read the current NIST guidelines on this ? [ the url was in my original email message ]. The current NIST guidelines, or at least my reading of it, says that even if you are using encryption and even if you are going to do physical destruction you still need to do something like this. I think it's a bit nuanced. Pages 15-16 obliquely mention encryption in the description of clearing: ... It must be resistant to keystore recovery attempts executed from standard input devices and from data scavenging tools. ... I'm not sure how to interpret that in the case of ZFS encryption. The actual keys used to encrypt file are not typed in by users, and data scavenging tools could only get at them if: a) they recovered user passwords from which master FS keys are derived, b) have access to the media. On page 4 (errata), it says that on 9-11-06 (version 10-06) text was deleted that had once declared encryption insufficient. So, altogether I would read this as allowing deletion of keys as a method of clearing. Since clearing is all we can hope to do in ZFS then I think this should be sufficient. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Why root zone can't be on ZFS for upgrade ?
Jeff wrote : The installation software does not yet understand ZFS, and is not able to upgrade a Solaris 10 system with a ZFS root file system. Further, it is not able to upgrade a Solaris 10 system with a non-global zone that has a ZFS file system as its zonepath. Thanks Jeff. Any idea on when Install Software will be able to see zfs vol ? This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
One other area where is is useful is when you are in a jurisdiction where a court order may require you to produce your encryption keys - yes such jurisdictions exist and I don't want to debate the human rights angle or social engineering aspects of this just state that it exists. For such environments you may not want to use encryption, because you could be forced to give up your key, or even if you are you want a background method of destroying the cipher text without doing full disk destruction. Think of court cases between companies rather than criminal activity. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
Bart Smaalders wrote: Jason J. W. Williams wrote: Not sure. I don't see an advantage to moving off UFS for boot pools. :-) -J Except of course that snapshots clones will surely be a nicer way of recovering from adverse administrative events... and make live upgrade and patching so much nicer. lucopy is often one of the most time consuming parts of doing live upgrade. The other HUGE advantage from ZFS root is that you don't need to prepare in advance for live upgrade because file systems are cheap and easily added in ZFS unlike with UFS root where you need at least one vtoc slice per live upgrade boot environment you want to keep around. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: Re: ZFS related kernel panic
At a minimum use the QLA2200 HBAs. As they were only recently EOLd. If you tried to give me a QLA2100 series HBA, I would not accept it. It's 5 generations behind the current FC hardware. At least with a QLA2200 HBA you will get qlc support and MPXIO. Lyle This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: What SATA controllers are people using for ZFS?
AFAIK there are Sata controllers from Areca and HP where you have a native Solaris 10 driver. I don´ t have them, but the Areca controller had a very positive test in a German computer magazine. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What SATA controllers are people using for ZFS?
Hi Naveen, I believe the newer LSI cards work pretty well with Solaris. Best Regards, Jason On 12/20/06, Naveen Nalam [EMAIL PROTECTED] wrote: Hi, This may not be the right place to post, but hoping someone here is running a reliably working system with 12 drives using ZFS that can tell me what hardware they are using. I have on order with my server vendor a pair of 12-drive servers that I want to use with ZFS for our company file stores. We're trying to use Supermicro PDSME motherboards, and each has two Supermicro MV8 sata cards. Solaris 10U3 he's found doesn't work on these systems. And I just read a post today (and an older post) on this group about how the Marvell based cards lock up. I can't afford lockups since this is very critical and expensive data that is being stored. My goal is a single cpu board that works with Solaris, and somehow get 12-drives plus 2 system boot drives plugged into it. I don't see any suitable sata cards on the Sun HCL. Are there any 4-port PCIe cards that people know reliably work? The Adaptec 1430SA looks nice, but no idea if it works. I could potentially get two 4-port PCIe cards, a 2 port PCI sata card (for boot), and 4-port motherboard - for 14 drives total. And cough up the extra cash for a supported dual-cpu motherboard (though i'm only using one cpu). any advice greatly appreciated.. Thanks! Naveen This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: zfs list and snapshots..
Hola folks, I am new to the list, please redirect me if I am posting to the wrong location. I am starting to use ZFS in production (Solaris x86 10U3 -- 11/06) and I seem to be seeing unexpected behavior for zfs list and snapshots. I create a filesystem (lets call it a/b where a is the pool). Now, if I store 100 gb of files on a/b and then snapshot a/[EMAIL PROTECTED] then delete about 50 gb of files from a/b -- I expect to see ~50 gb USED on both a/b and a/[EMAIL PROTECTED] via zfs list output -- instead I only seem to see the delta block adds as USED (~20mb) on a/[EMAIL PROTECTED] Is this correct behavior? how do you track the total delta blocks the snap is using vs other snaps and live fs? Thanks! Wade Stuart ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Re: ZFS failover without multipathing
Hey, #First question to ask -- are you using the emlxs driver for #the Emulex card? Im using what I believe is the latest version of SFS. I got it from a link on the Emulex website. to http://www.sun.com/download/products.xml?id=42c4317d #Second question -- are you up to date on the SAN Foundation #Kit (SFK) patches? I think the current version is 4.4.11. If #you're not running that version, I strongly recommend that #you upgrade your patch levels to it. Ditto for kernel, sd #and scsi_vhci. I downloaded all of the patches and the latest SFS from sun. Here is a list of patches I have recently downloaded and installed this week: 119130 120222 119470 119715 Also, since my last posting I have found that I get slow 'zpool create' and 'zpool import' times when I have mpxio enabled. Running truss duing the 'zpool import' displays delays on system calls like pread() fstat(), stat64() and ioctl() calls. I have receiver similar test results, i.e. slow zpool creates/imports, on two differnet drivers now. The Emulex 1DC 2GB HBA and the QLOGIC x6727a (SUN) HBA. Would it also help if I purchased the latest 4GB HBA from Sun. Maybe the Qlogic HBA doesn't function well with the Leadville (scsi_vhci) driver. Luke This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What SATA controllers are people using for ZFS?
and specific models, and the driver used? Looks like there may be stability issues with the marvell, which appear to go unanswered.. On 12/21/06, Jason J. W. Williams [EMAIL PROTECTED] wrote: Hi Naveen, I believe the newer LSI cards work pretty well with Solaris. Best Regards, Jason On 12/20/06, Naveen Nalam [EMAIL PROTECTED] wrote: Hi, This may not be the right place to post, but hoping someone here is running a reliably working system with 12 drives using ZFS that can tell me what hardware they are using. I have on order with my server vendor a pair of 12-drive servers that I want to use with ZFS for our company file stores. We're trying to use Supermicro PDSME motherboards, and each has two Supermicro MV8 sata cards. Solaris 10U3 he's found doesn't work on these systems. And I just read a post today (and an older post) on this group about how the Marvell based cards lock up. I can't afford lockups since this is very critical and expensive data that is being stored. My goal is a single cpu board that works with Solaris, and somehow get 12-drives plus 2 system boot drives plugged into it. I don't see any suitable sata cards on the Sun HCL. Are there any 4-port PCIe cards that people know reliably work? The Adaptec 1430SA looks nice, but no idea if it works. I could potentially get two 4-port PCIe cards, a 2 port PCI sata card (for boot), and 4-port motherboard - for 14 drives total. And cough up the extra cash for a supported dual-cpu motherboard (though i'm only using one cpu). any advice greatly appreciated.. Thanks! Naveen This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: What SATA controllers are people using for ZFS?
Thanks for the Areca recommendation. My vendor was initially proposing the Areca as well. I had thought that the Supermicro MV8 would be better since two cards total only $200 vs the $700 for a 12-port Areca card, and thought that the MV8 would have good support since Thumper uses the Marvell 88sx6081 sata chipset (which I believe is what the MV8 uses as well). We've gotten Solaris to load on a newer motherboard - the Supermicro PDSME+ which is an update to the Supermicro PDSME. I guess I will stick with the MV8 for now, and if issues arise - replace them with an Areca card or whatever else ppl suggest. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What SATA controllers are people using for ZFS?
On Thu, 21 Dec 2006, Joe Little wrote: and specific models, and the driver used? Looks like there may be stability issues with the marvell, which appear to go unanswered.. I've tested a box running two Marvell based 8-port controllers (which has been running great on Update 2) on the solaris Update 3 beta without issues. The specific card is the newer version of the SuperMicro board: http://www.supermicro.com/products/accessories/addon/AoC-SAT2 but have yet to test them under the released Update 3 code. I'll post a followup after the box is upgraded or re-installed. [I'm waiting for the next 48-hour day so that I can do the upgrade without affecting the user community!!] AFAIR the reported Marvell issues were with ON B54 - not Update 3. Or do I have this wrong? In any case, if you discover a bug with the Sun proprietary Marvell driver and Update 3 and you have a support contract, you can log a service request and get it fixed. Since the Marvell chipset is used in Thumper, I think its a pretty safe bet that the Marvell driver will continue to work very nicely (Thanks Lori). And yes, I would feel better if this driver was open sourced but that is Suns' decision to make. Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
RE: [zfs-discuss] What SATA controllers are people using for ZFS?
So are there any PCI-Express cards based on the Marvell chipset? And/or is there something with native SATA support that is the same general specifications (8 ports, non-raid) just based on a different chipset but using a PCI-E interface? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Hopper Sent: Thursday, December 21, 2006 4:15 PM To: Joe Little Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] What SATA controllers are people using for ZFS? On Thu, 21 Dec 2006, Joe Little wrote: and specific models, and the driver used? Looks like there may be stability issues with the marvell, which appear to go unanswered.. I've tested a box running two Marvell based 8-port controllers (which has been running great on Update 2) on the solaris Update 3 beta without issues. The specific card is the newer version of the SuperMicro board: http://www.supermicro.com/products/accessories/addon/AoC-SAT2 but have yet to test them under the released Update 3 code. I'll post a followup after the box is upgraded or re-installed. [I'm waiting for the next 48-hour day so that I can do the upgrade without affecting the user community!!] AFAIR the reported Marvell issues were with ON B54 - not Update 3. Or do I have this wrong? In any case, if you discover a bug with the Sun proprietary Marvell driver and Update 3 and you have a support contract, you can log a service request and get it fixed. Since the Marvell chipset is used in Thumper, I think its a pretty safe bet that the Marvell driver will continue to work very nicely (Thanks Lori). And yes, I would feel better if this driver was open sourced but that is Suns' decision to make. Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: [security-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Darren J Moffat wrote: One other area where is is useful is when you are in a jurisdiction where a court order may require you to produce your encryption keys - yes such jurisdictions exist and I don't want to debate the human rights angle or social engineering aspects of this just state that it exists. I think in these cases you want plausable deniability where different encryption keys produce different view of the disk, none of which give away that there are any other correct views of the data. If it is possible to destroy a small piece of the ZFS meta data (key material) and that makes it thereafter impossible to encrypt data, sure, but otherwise, bleaching is probably going to take a bit too long once you hear the knock on the door... For such environments you may not want to use encryption, because you could be forced to give up your key, or even if you are you want a background method of destroying the cipher text without doing full disk destruction. Think of court cases between companies rather than criminal activity. For corporations there are different requirements, for examples laws that regulate data retention. Not only this but you also need to make sure that the data you want to make unavailable never got backed up or that those backups get wiped... Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What SATA controllers are people using for ZFS?
On 12/21/06, Al Hopper [EMAIL PROTECTED] wrote: On Thu, 21 Dec 2006, Joe Little wrote: and specific models, and the driver used? Looks like there may be stability issues with the marvell, which appear to go unanswered.. I've tested a box running two Marvell based 8-port controllers (which has been running great on Update 2) on the solaris Update 3 beta without issues. The specific card is the newer version of the SuperMicro board: http://www.supermicro.com/products/accessories/addon/AoC-SAT2 but have yet to test them under the released Update 3 code. I'll post a followup after the box is upgraded or re-installed. [I'm waiting for the next 48-hour day so that I can do the upgrade without affecting the user community!!] AFAIR the reported Marvell issues were with ON B54 - not Update 3. Or do I have this wrong? Yes, this is all OpenSolaris based, so the areca seems to be for Solaris 10 proper and the marvell may have issues at least at B54. In any case, if you discover a bug with the Sun proprietary Marvell driver and Update 3 and you have a support contract, you can log a service request and get it fixed. Since the Marvell chipset is used in Thumper, I think its a pretty safe bet that the Marvell driver will continue to work very nicely (Thanks Lori). And yes, I would feel better if this driver was open sourced but that is Suns' decision to make. Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] What SATA controllers are people using for ZFS?
On Thu, 21 Dec 2006, Al Hopper wrote: On Thu, 21 Dec 2006, Joe Little wrote: and specific models, and the driver used? Looks like there may be stability issues with the marvell, which appear to go unanswered.. I've tested a box running two Marvell based 8-port controllers (which has been running great on Update 2) on the solaris Update 3 beta without issues. The specific card is the newer version of the SuperMicro board: http://www.supermicro.com/products/accessories/addon/AoC-SAT2 Correction :( http://www.supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm ... snip ... Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
