Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto
Bill Sommerfeld wrote: There also may be a reason to do this when confidentiality isn't required: as a sparse provisioning hack.. If you were to build a zfs pool out of compressed zvols backed by another pool, then it would be very convenient if you could run in a mode where freed blocks were overwritten by zeros when they were freed, because this would permit the underlying compressed zvol to free *its* blocks. A very interesting observation. Particularly given that I have just created such a configuration - with iSCSI in the middle. -- 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
Matthew Ahrens wrote: Darren J Moffat wrote: I believe that ZFS should provide a method of bleaching a disk or part of it that works without crypto having ever been involved. I see two use cases here: 1. This filesystem contains sensitive information. When it is freed, make sure it's really gone. I believe that the proper way to do this is to introduce a new zfs property (say, bleach) which, when set, will cause any blocks which are freed to be bleached. The value of the property can specify the type of bleach to use (ie, the overwrite pattern). To ease administrative complexity, this property should probably only be set at filesystem creation time (eg. 'zfs create -o bleach=maximum-strength pool/fs'). Furthermore, 'zfs promote fs' should not be run if the fs and its origin have different bleach settings (because the ownership of the shared blocks would change). However, clones do not in general pose any problems for this model (because it's always clear which fs owns each block, and only that fs can free it). 2. I've deleted some stuff at some point in the past, and now I want to make sure that it's really gone. To do this, we should have a zpool bleach command which would immediately go and bleach all unallocated blocks. Note that if both these features are implemented, it might make sense to allow changing the 'bleach' property on a fs after it has been created, and have that implicitly kick off a 'zpool bleach' to ensure that any space previously used for that fs is bleached. Also note that these bleaching features would not change the semantics of snapshots, clones, etc. A block will not be bleached until all references to it are removed, and the block is freed. You have it in a nutshell as far as I'm concerned, nice simplification that we only need this at the ZFS level and at the pool level. -- Darren J Moffat ___ 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
Not to add a cold blanket to this... This would be mostly a vanity erase not really a serious security erase since it will not over write the remnants of remapped sectors. Serious security erase software will unmap sectors and erase both locations using special microcode features. While getting access to these remnants may be considered exotic measures, it is becoming less so with the plenitude vendor specific microcode features, and the number of data recovery organizations that use spin stands. Sectors can be remapped without the data being completely bad. It may still be readable with recoverable errors in the drive. Jim On Dec 20, 2006, at 1:41 AM, Darren J Moffat wrote: Bill Sommerfeld wrote: There also may be a reason to do this when confidentiality isn't required: as a sparse provisioning hack.. If you were to build a zfs pool out of compressed zvols backed by another pool, then it would be very convenient if you could run in a mode where freed blocks were overwritten by zeros when they were freed, because this would permit the underlying compressed zvol to free *its* blocks. A very interesting observation. Particularly given that I have just created such a configuration - with iSCSI in the middle. -- Darren J Moffat ___ security-discuss mailing list [EMAIL PROTECTED] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[6]: [zfs-discuss] ZFS in a SAN environment
Hello Jason, Wednesday, December 20, 2006, 1:02:36 AM, you wrote: JJWW Hi Robert JJWW I didn't take any offense. :-) I completely agree with you that zpool JJWW striping leverages standard RAID-0 knowledge in that if a device JJWW disappears your RAID group goes poof. That doesn't really require a JJWW notice...was just trying to be complete. :-) JJWW The surprise to me was that detecting block corruption did the same JJWW thing...since most hardware RAID controllers and filesystems do a poor JJWW job of detecting block-level corruption, kernel panicking on corrupt JJWW blocks seems to be what folks like me aren't expecting until it JJWW happens. JJWW Frankly, in about 5 years when ZFS and its concepts are common JJWW knowledge, warning folks about corrupt blocks re-booting your server JJWW would be like notifying them what rm and mv do. However, until then JJWW warning them that corruption will cause a panic would definitely aid JJWW folks who think they understand because they have existing RAID and JJWW SAN knowledge, and then get bitten. Also, I think the zfsassist JJWW program is a great idea for newbies. I'm not sure how often it would JJWW be used by storage pros new to ZFS. Using the gal with the EMC DMX-3 JJWW again as an example (sorry! O:-) ), I'm sure she's pretty experienced JJWW and had no problems using ZFS correctly...just was not expecting a JJWW kernel panic on corruption and so was taken by surprise as to what JJWW caused the kernel panic when it happened. A warning message when JJWW creating a striped pool, would in my case have stuck in my brain so JJWW that when the kernel panic happened, corruption of the zpool would JJWW have been on my top 10 things to expect as a cause. Anyway, this is JJWW probably an Emacs/VI argument to some degree. Now that I've JJWW experienced a panic from zpool corruption its on the forefront of my JJWW mind when designing ZFS zpools, and the warning wouldn't do much for JJWW me now. Though I probably would have preferred to learn from a warning JJWW message instead of a panic. :-) But with other file systems you basically get the same - in many cases kernel crash - but in a more unpredictable way. Now not that I'm fond of current ZFS behavior, I would really like to specify like in UFS if system has to panic or just lock the filesystem (or a pool). As Eric posted some time ago (I think it was Eric) it's on a list to address. However I still agree that striped pools should be displayed (zpool status) with stripe keyword like mirrors or raidz groups - that would be less confusing for beginners. -- 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
[zfs-discuss] Honeycomb
Hello, I just wanted to know if there are any news regarding Project Honeycomb? Wasn´ it announced for end of 2006? Is there still development? I hope, this is the right place to post this question happy holidays This message posted from opensolaris.org ___ 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: Not to add a cold blanket to this... This would be mostly a vanity erase not really a serious security erase since it will not over write the remnants of remapped sectors. Indeed and as you said there is other software to deal with this for those types of customers that need that. There are also physical destruction methods as well. This is intended as a defense in depth measure and also a sufficiently good measure for the customers that don't need full compliance with NIST like requirements that need degausing or physical destruction. It is intended to make customers more comfortable about handing disks back to their vendor. Today we need to manually run format(1M)'s analyze/purge for that. Are you saying that you don't think this is sufficiently useful that we should implement this in ZFS or are you just pointing out that for a some security policies this is not enough ? -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can't find my pool
On Tue, Dec 19, 2006 at 10:29:24PM -0500, Rince wrote: What exactly did it say? Did it say there are some pools that couldn't be imported, use zpool import -f to see them, or just no pools available? no pools available If not, then I suspect that Solaris install didn't see the relevant disk slices. devfsadm -c disk should populate /dev/dsk or others as appropriate. Richard has this to say on the matter: IIRC, Solaris expects only one Solaris-labelled (fdisk) partition per disk. Having more than one parition has been a thorn in my side for more than just this (I can't upgrade, it doesn't see my old instance) so I'm going to take this oppourtunity to re-install and give Solaris the whole disk. I just hope Xen can do diskimage files like VMWare does or I'm screwed on getting XP in a virtual machine. ;) -brian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Honeycomb
On Wed, Dennis wrote: Hello, I just wanted to know if there are any news regarding Project Honeycomb? Wasn?? it announced for end of 2006? Is there still development? http://www.sun.com/storagetek/honeycomb/ ___ 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 Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote: In case it wasn't clear I am NOT proposing a UI like this: $ zfs bleach ~/Documents/company-finance.odp Instead ~/Documents or ~ would be a ZFS file system with a policy set something like this: # zfs set erase=file:zero Or maybe more like this: # zfs create -o erase=file -o erasemethod=zero homepool/darrenm The goal is the same as the goal for things like compression in ZFS, no application change it is free for the applications. 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 for one would prefer encryption, which may turns out to be much faster than bleaching and also more secure. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpbmTXIeqnBE.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re[2]: ZFS in a SAN environment
On Dec 20, 2006, at 00:37, Anton B. Rang wrote: INFORMATION: If a member of this striped zpool becomes unavailable or develops corruption, Solaris will kernel panic and reboot to protect your data. OK, I'm puzzled. Am I the only one on this list who believes that a kernel panic, instead of EIO, represents a bug? I agree as well - did you file a bug on this yet? Inducing kernel panics (like we also do on certain sun cluster failure types) to prevent corruption can often lead to more corruption elsewhere, and usually ripples to throw admins, managers, and users in a panic as well - typically resulting in more corrupted opinions and perceptions of reliability and usability. :) --- .je ___ 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 writes: The goal is the same as the goal for things like compression in ZFS, no application change it is free for the applications. 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 for one would prefer encryption, which may turns out to be much faster than bleaching and also more secure. I think the idea here is that since ZFS encourages the use of lots of small file systems (rather than one or two very big ones), you'd have just one or two very small file systems with crucial data marked as needing bleach, while the others would get by with the usual complement of detergent and switch fabric softener. Having _every_ file modification result in dozens of I/Os would probably be bad, but perhaps not if it's not _every_ modification that's affected. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ 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 Wed, 20 Dec 2006, Pawel Jakub Dawidek wrote: On Tue, Dec 19, 2006 at 02:04:37PM +, Darren J Moffat wrote: In case it wasn't clear I am NOT proposing a UI like this: $ zfs bleach ~/Documents/company-finance.odp Instead ~/Documents or ~ would be a ZFS file system with a policy set something like this: # zfs set erase=file:zero Or maybe more like this: # zfs create -o erase=file -o erasemethod=zero homepool/darrenm The goal is the same as the goal for things like compression in ZFS, no application change it is free for the applications. 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 for one would prefer encryption, which may turns out to be much faster than bleaching and also more secure. 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). FrankH. ___ 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
On Dec 20, 2006, at 04:41, Darren J Moffat wrote: Bill Sommerfeld wrote: There also may be a reason to do this when confidentiality isn't required: as a sparse provisioning hack.. If you were to build a zfs pool out of compressed zvols backed by another pool, then it would be very convenient if you could run in a mode where freed blocks were overwritten by zeros when they were freed, because this would permit the underlying compressed zvol to free *its* blocks. A very interesting observation. Particularly given that I have just created such a configuration - with iSCSI in the middle. over ipsec? wow - how many layers is that before you start talking to the real (non-psuedo) block storage device? --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Advice Wanted - sharing across multiple non global zones
Hi.. After searching hi low, I cannot find the answer for what I want to do (or at least understand how to do it). I am hopeful somebody can point me in the right direction. I have (2) non global zones (samba www) I want to be able to have all user home dir's served from zone samba AND be visable under zone www as the users public_html dir. I have looked at delegating a dataset to samba and creating a new fs for each user but then I cannot share that with www. I also tried creating the fs under the global zone and mounting that via lofs but that did not seem to carry over each underlying fs and lost the quota capability. I cannot share via NFS since non global zones cannot mount from the same server. How can I achieve what I want to do? The requirements are: User Quotas (needs a file system for each user) Share file systems across multiple non global zones (rw) I have close to 3000 users so it must be a manageable approach and hopefully allow me to use the root preexec of samba to auto create user dir's. tia for any help, Daren 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: Re[2]: ZFS in a SAN environment
Dennis Clarke wrote: Anton B. Rang wrote: INFORMATION: If a member of this striped zpool becomes unavailable or develops corruption, Solaris will kernel panic and reboot to protect your data. Is this the official, long-term stance? I don't think it is. I think this is an interpretation of current state. OK, I'm puzzled. Am I the only one on this list who believes that a kernel panic, instead of EIO, represents a bug? Nope. I'm with you. no no .. its a feature. :-P If it walks like a duck and quacks like a duck then its a duck. a kernel panic that brings down a system is a bug. Plain and simple. I disagree (nit). A hardware fault can also cause a panic. Faults != bugs. I do agree in principle, though. Panics should be avoided whenever possible. Incidentally, we do track the panic rate and collect panic strings. The last detailed analysis I saw on the data showed that the vast majority were hardware induced. This was a bit of a bummer because we were hoping that the tracking data would lead to identifying software bugs. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
Jason J. W. Williams wrote: INFORMATION: If a member of this striped zpool becomes unavailable or develops corruption, Solaris will kernel panic and reboot to protect your data. This is a bug, not a feature. We are currently working on fixing it. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re[2]: ZFS in a SAN environment
no no .. its a feature. :-P If it walks like a duck and quacks like a duck then its a duck. a kernel panic that brings down a system is a bug. Plain and simple. I disagree (nit). A hardware fault can also cause a panic. Faults != bugs. ha ha .. yeah. If the sysadm walks over to a machine an pour coffee in it then I guess it will fault all over the place. No appreciation for coffee I guess. however ... when it comes to storage I expect that a disk failure or hot swap will not cause a fault if and only if there still remains some other storage device that holds the bits in a redundant fashion. so .. disks can fail. That should be okay. even memory and processors can fail. within reason. I do agree in principle, though. Panics should be avoided whenever possible. coffee spillage also .. Incidentally, we do track the panic rate and collect panic strings. The last detailed analysis I saw on the data showed that the vast majority were hardware induced. This was a bit of a bummer because we were hoping that the tracking data would lead to identifying software bugs. but it does imply that the software is way better than the hardware eh ? -- Dennis Clarke ___ 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
Jonathan Edwards wrote: On Dec 20, 2006, at 04:41, Darren J Moffat wrote: Bill Sommerfeld wrote: There also may be a reason to do this when confidentiality isn't required: as a sparse provisioning hack.. If you were to build a zfs pool out of compressed zvols backed by another pool, then it would be very convenient if you could run in a mode where freed blocks were overwritten by zeros when they were freed, because this would permit the underlying compressed zvol to free *its* blocks. A very interesting observation. Particularly given that I have just created such a configuration - with iSCSI in the middle. over ipsec? wow - how many layers is that before you start talking to the real (non-psuedo) block storage device? It's turtles all the way down. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
On 19-Dec-06, at 11:51 AM, Jonathan Edwards wrote:
On Dec 19, 2006, at 10:15, Torrey McMahon wrote:
Darren J Moffat wrote:
Jonathan Edwards wrote:
On Dec 19, 2006, at 07:17, Roch - PAE wrote:
Shouldn't there be a big warning when configuring a pool
with no redundancy and/or should that not require a -f flag ?
why? what if the redundancy is below the pool .. should we
warn that ZFS isn't directly involved in redundancy decisions?
Yes because if ZFS doesn't know about it then ZFS can't use it to
do corrections when the checksums (which always work) detect
problems.
We do not have the intelligent end-to-end management to make these
judgments. Trying to make one layer of the stack {stronger,
smarter, faster, bigger,} while ignoring the others doesn't help.
Trying to make educated guesses as to what the user intends
doesn't help either.
Hi! It looks like you're writing a block
Would you like help?
- Get help writing the block
- Just write the block without help
- (Don't show me this tip again)
somehow I think we all know on some level that letting a system
attempt to guess your intent will get pretty annoying after a while ..
I think what you (hilariously) describe above is a system that's *too
stupid* not a system that's *too smart*...
--Toby
___
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] ZFS and SE 3511
On 18-Dec-06, at 11:18 PM, Matt Ingenthron wrote: Mike Seda wrote: Basically, is this a supported zfs configuration? Can't see why not, but support or not is something only Sun support can speak for, not this mailing list. You say you lost access to the array though-- a full disk failure shouldn't cause this if you were using RAID-5 on the array. Perhaps you mean you've had to take it out of production because it couldn't keep up with the expected workload? You are gonna laugh, but do you think my zfs configuration caused the drive failure? You mention this is a new array. As one Sun person (whose name I can't remember) mentioned to me, there's a high 'infant mortality' rate among semiconductors. Components that are going to fail will either do so in the first 120 days or so, or will run for many years. I'm no expert in the area though and I have no data to prove it, but it has felt somewhat true as I've seen new systems set up over the years. A quick search for semiconductor infant mortality turned up some interesting results. You might have even more luck with tub curve. --Toby Chances are, it's something much more mundane that got your disk. ZFS is using the same underlying software as everything else to read/write to disks on a SAN (i.e. the ssd driver and friends)-- it's just smarter about it. :) Regards, - Matt ___ 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: ZFS and SE 3511
On 19-Dec-06, at 2:42 PM, Jason J. W. Williams wrote: I do see this note in the 3511 documentation: Note - Do not use a Sun StorEdge 3511 SATA array to store single instances of data. It is more suitable for use in configurations where the array has a backup or archival role. My understanding of this particular scare-tactic wording (its also in the SANnet II OEM version manual almost verbatim) is that it has mostly to do with the relative unreliability of SATA firmware versus SCSI/FC firmware. That's such a sad sentence to have to read. Either prices are unrealistically low, or the revenues aren't being invested properly? --Toby Its possible that the disks are lower quality SATA disks too, but that was not what was relayed to us when we looked at buying the 3511 from Sun or the DotHill version (SANnet II). Best Regards, Jason ___ 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] B54 and marvell cards
We just put together a new system for ZFS use at a company, and twice in one week we've had the system wedge. You can log on, but the zpools are hosed, and a reboot never occurs if requested since it can't unmount the zfs volumes. So, only a power cycle works. In both cases, we get this: Dec 20 10:59:36 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:36 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:36 kona port 2: device reset Dec 20 10:59:37 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: device reset Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link lost Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link established Dec 20 10:59:37 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device disconnected Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device connected The first time was on port 1 (Sunday) and now this has occurred on port 2. Is there a known unrecoverable condition with the marvell card. We adopted this card because the adaptec 16 port card was discontinued. Everyday there seems to be less in the way of workable SATA cards for Solaris (sigh). Here's the output on startup, which always occurs: Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 0: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 1: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 3: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 4: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 5: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered
Re: [zfs-discuss] Re: ZFS and SE 3511
Hi Toby, My understanding on the subject of SATA firmware reliability vs. FC/SCSI is that its mostly related to SATA firmware being a lot younger. The FC/SCSI firmware that's out there has been debugged for 10 years or so, so it has a lot fewer hiccoughs. Pillar Data Systems told us once that they found most of their SATA failed disks were just fine when examined, so their policy is to issue a RESET to the drive when a SATA error is detected, then retry the write/read and keep trucking. If they continue to get SATA errors, then they'll fail the drive. Looking at the latest Engenio SATA products, I believe they do the same thing. Its probably unfair to expect defect rates out of SATA firmware equivalent to firmware that's been around for a long time...particularly with the price pressures on SATA. SAS may suffer the same issue, though they seem to have 1,000,000 MTBF ratings like their traditional FC/SCSI counterparts. On a side-note, we experienced a path failure to a drive in our SATA Engenio array (older model), simply popping the drive out and back in fixed the issue...haven't had any notifications since. A RESET and RETRY would have been nice behavior to have, since popping and reinserting triggered a rebuild of the drive. Best Regards, Jason On 12/19/06, Toby Thain [EMAIL PROTECTED] wrote: On 19-Dec-06, at 2:42 PM, Jason J. W. Williams wrote: I do see this note in the 3511 documentation: Note - Do not use a Sun StorEdge 3511 SATA array to store single instances of data. It is more suitable for use in configurations where the array has a backup or archival role. My understanding of this particular scare-tactic wording (its also in the SANnet II OEM version manual almost verbatim) is that it has mostly to do with the relative unreliability of SATA firmware versus SCSI/FC firmware. That's such a sad sentence to have to read. Either prices are unrealistically low, or the revenues aren't being invested properly? --Toby Its possible that the disks are lower quality SATA disks too, but that was not what was relayed to us when we looked at buying the 3511 from Sun or the DotHill version (SANnet II). Best Regards, Jason ___ 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: B54 and marvell cards
On 12/20/06, Joe Little [EMAIL PROTECTED] wrote: We just put together a new system for ZFS use at a company, and twice in one week we've had the system wedge. You can log on, but the zpools are hosed, and a reboot never occurs if requested since it can't unmount the zfs volumes. So, only a power cycle works. In both cases, we get this: Note to group.. Is the tekram 834A (SATA-II card w/ sil3124-1 and sil3124-2) supported yet? Seems like marvell is not the way to go.. Dec 20 10:59:36 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:36 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:36 kona port 2: device reset Dec 20 10:59:37 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: device reset Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link lost Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link established Dec 20 10:59:37 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device disconnected Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device connected The first time was on port 1 (Sunday) and now this has occurred on port 2. Is there a known unrecoverable condition with the marvell card. We adopted this card because the adaptec 16 port card was discontinued. Everyday there seems to be less in the way of workable SATA cards for Solaris (sigh). Here's the output on startup, which always occurs: Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 0: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 1: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 3: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 4: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 5: Dec 17
[zfs-discuss] Re: B54 and marvell cards
Some further joy: http://bugs.opensolaris.org/view_bug.do?bug_id=6504404 On 12/20/06, Joe Little [EMAIL PROTECTED] wrote: On 12/20/06, Joe Little [EMAIL PROTECTED] wrote: We just put together a new system for ZFS use at a company, and twice in one week we've had the system wedge. You can log on, but the zpools are hosed, and a reboot never occurs if requested since it can't unmount the zfs volumes. So, only a power cycle works. In both cases, we get this: Note to group.. Is the tekram 834A (SATA-II card w/ sil3124-1 and sil3124-2) supported yet? Seems like marvell is not the way to go.. Dec 20 10:59:36 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:36 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:36 kona port 2: device reset Dec 20 10:59:37 kona marvell88sx: [ID 331397 kern.warning] WARNING: marvell88sx0: device on port 2 still busy Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: device reset Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link lost Dec 20 10:59:37 kona sata: [ID 801593 kern.notice] NOTICE: /[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci11ab,[EMAIL PROTECTED]: Dec 20 10:59:37 kona port 2: link established Dec 20 10:59:37 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device disconnected Dec 20 10:59:37 kona marvell88sx: [ID 517869 kern.info] device connected The first time was on port 1 (Sunday) and now this has occurred on port 2. Is there a known unrecoverable condition with the marvell card. We adopted this card because the adaptec 16 port card was discontinued. Everyday there seems to be less in the way of workable SATA cards for Solaris (sigh). Here's the output on startup, which always occurs: Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 0: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 1: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 2: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 3: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] 10-bit to 8-bit decode error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Disparity error Dec 17 11:23:15 kona marvell88sx: [ID 812950 kern.warning] WARNING: marvell88sx0: error on port 4: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] SError interrupt Dec 17 11:23:15 kona marvell88sx: [ID 131198 kern.info] SErrors: Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] Recovered communication error Dec 17 11:23:15 kona marvell88sx: [ID 517869 kern.info] PHY ready change Dec 17 11:23:15 kona marvell88sx: [ID 517869
Re: [zfs-discuss] ZFS in a SAN environment
Jason J. W. Williams wrote: I agree with others here that the kernel panic is undesired behavior. If ZFS would simply offline the zpool and not kernel panic, that would obviate my request for an informational message. It'd be pretty darn obvious what was going on. What about the root/boot pool? James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
James C. McPherson wrote: Jason J. W. Williams wrote: I agree with others here that the kernel panic is undesired behavior. If ZFS would simply offline the zpool and not kernel panic, that would obviate my request for an informational message. It'd be pretty darn obvious what was going on. What about the root/boot pool? The default with ufs today is onerror=panic, so having ZFS do likewise is no backwards step. What other mechanisms do people suggest be implemented to guarantee the integrity of your data on zfs? James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
Not sure. I don't see an advantage to moving off UFS for boot pools. :-) -J On 12/20/06, James C. McPherson [EMAIL PROTECTED] wrote: Jason J. W. Williams wrote: I agree with others here that the kernel panic is undesired behavior. If ZFS would simply offline the zpool and not kernel panic, that would obviate my request for an informational message. It'd be pretty darn obvious what was going on. What about the root/boot pool? James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Very strange performance patterns
Hello, Short version: Pool A is fast, pool B is slow. Writing to pool A is fast. Writing to pool B is slow. Writing to pool B WHILE writing to pool A is fast on both pools. Explanation? Long version: I have an existing two-disk pool consisting of two SATA drives. Call this pool pool1. This has always been as fast as I would have expected; 30-50 MB/second write, 105 MB/second read. I have now added four additional drives (A, B, C and D) to the machine, that I wanted to use for a raidz. For initial testing I chose a striped pool just to see what kind of performance I would get. The initial two drives (pool1) are on their own controller. A and B are on a second controller and C and D on a third controller. All of the controllers are SiL3512. Here comes the very interesting bit. For the purpose of the diagram below, good performance means 20-50 mb/sec write and ~70-80 mb/sec read. Bad performance means 3-5 mb/sec () write and ~70-80 mb/sec read. disk layout in pool | other I/O | performance A + B | none | good C + D | none | good A + B + C + D | none | bad A + B + C | none | bad A + B + C + D | write to pool1 | goodish (!!!) (some tested combinations omitted) In other words: Initially it looked like write performance went down the drain as soon as I combined drives from multiple controllers into one pool, while performance was fine as long as I stayed within one controller. However, writing to the slow A+B+C+D pool *WHILE ALSO WRITING TO POOL1* actually *INCREASES* performance. The write to pool1 and the otherwise slow pool are not quite up to normal good level, but that is probably to be expected even under normal circumstances. CPU usage during the writing (when slow) is almost non-existent. There is no spike similar to what you seem to get every five second or so normally (during transaction commits?). Also, at least once I saw the write performance on the slow pool spike at 19 mb/second for a single second period (zpool iostat) when I initiated the write, then it went down again and remains very constant, not really varying outside 3.4-4.5. Often EXACTLY at 3.96. writing and reading means dd:ing (to /dev/null, from /dev/zero) with bs=$((1024*1024)). Pools created with zpool create speedtest c4d0 c5d0 c6d0 c7d0 and variations of that for the different combinations. The pool with all four drives is 1.16T in size. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ 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
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, with more intensive bleaching reserved for when disks are taken out of service. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS in a SAN environment
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... -= Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Honeycomb
Dennis wrote: I just wanted to know if there are any news regarding Project Honeycomb? Wasn´ it announced for end of 2006? Is there still development? We're still going ;-) There has been some limited releases so far. Stanford bought a Honeycomb system for a Digital Library project. If you search in Google News there is a bunch of recent articles. We should be having a General Access release next year. peter ___ 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
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, with more intensive bleaching reserved for when disks are taken out of service. When SunFed first implemented format-analyze-purge to the Magnetic Remnance specification of, IIRC, 3 overwrites each of , , , the instructions to the admins went something like: When you first put the disk in service, record the factory flaw map and retain it. When you later purge the disk, read out and record the current flaw map. Purge the disk. If the factory flaw map and current flaw map differ, remap the difference to active and re-purge the disks. I've been told, but haven't verified, that the current format - disk driver - disk combinations no longer support both reporting the flaw map and remapping flawed sectors back to active. Gary.. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: disk failure on raidz pool defies fixing
Hi Eric, I'm experience the same problem. However, I don't know how to dd the first and the last sector of the disk. may I have the command? How do you decode file /var/fm/fmd/errlog and /var/fm/fmd/fltlog? Thanks Giang 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] Can't find my pool
On Tue, Dec 19, 2006 at 02:55:59PM -0500, Rince wrote: zpool import should give you a list of all the pools ZFS sees as being mountable. zpool import [poolname] is also, conveniently, the command used to mount the pool afterward. :) If it doesn't show up there, I'll be surprised. I have a similar situation. Zpool list shows all ZFS, but zfs list shows nothing. # zfs get all # zfs list no datasets available # zpool import no pools available to import # zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT home 10G 7.64G 2.36G76% ONLINE - stage 7.56G 6.49G 1.07G85% ONLINE - # zpool status -v pool: home state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM homeONLINE 0 0 0 c0d0s5ONLINE 0 0 0 errors: No known data errors pool: stage state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM stage ONLINE 0 0 0 c0d0s7ONLINE 0 0 0 errors: No known data errors # zpool status -x all pools are healthy Further more, zpool core dumps on me. # zpool export stage # zpool import pool: stage id: 2924019764990342234 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: stage ONLINE c0d0s7ONLINE # zpool import stage internal error: No such device Abort - core dumped All is strange... Andrew IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. ___ 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
I've heard from old-old-oldtimers, back in the epoxy-disk days, that even after this type of erase the old epoxy disks could sometimes be read via etching combined with electron microscopes -- the (relatively) new sputtered aluminum finishes probably changed that. So back in the epoxy days, disks could never move down in classification, they were always either kept at the same or higher classification or else bathed in acid until no more coating remained. Or slagged. I can see why gov't customers would ideally like a better solution but I know that in my disk drive programming days, an alternate disk controller had to be used in order to do such things, and I hear that's still the case, except that since disk controllers are little teensy chips instead of refrigerator-sized external boxes, it might not be worth the money to bother trying to get the disk factories to do this. What might be doable is to get someone to manufacture a disk where this is controlled by a jumper (even a hidden, covered, jumper) so that the jumper could be moved instead of trying to pry chips out of the card in order to replace the controller logic. Bottom line: if all I hear is true, it is the drive manufacturers who are in a position to address this. Date: Wed, 20 Dec 2006 15:32:48 -0800 (PST) From: Gary Winiger [EMAIL PROTECTED] Subject: Re: [security-discuss] Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: zfs-discuss@opensolaris.org, [EMAIL PROTECTED] Delivered-to: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] List-Unsubscribe: http://mail.opensolaris.org/mailman/listinfo/security-discuss, mailto:[EMAIL PROTECTED] List-Id: OpenSolaris Security Discussions security-discuss.opensolaris.org 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, with more intensive bleaching reserved for when disks are taken out of service. When SunFed first implemented format-analyze-purge to the Magnetic Remnance specification of, IIRC, 3 overwrites each of , , , the instructions to the admins went something like: When you first put the disk in service, record the factory flaw map and retain it. When you later purge the disk, read out and record the current flaw map. Purge the disk. If the factory flaw map and current flaw map differ, remap the difference to active and re-purge the disks. I've been told, but haven't verified, that the current format - disk driver - disk combinations no longer support both reporting the flaw map and remapping flawed sectors back to active. Gary.. ___ security-discuss mailing list [EMAIL PROTECTED] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS
So, I've read the wikipedia, and have done a lot of research on google about it, but it just doesn't make sense to me. Correct me if I'm wrong, but you can take a simple 5/10/20 GB drive or whatever size, and turn it into exabytes of storage space? If that is not true, please explain the importance of this other than the self heal and those other features. Thank you very much, Andrew 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: disk failure on raidz pool defies fixing
On 20 December, 2006 - storage-disk sent me these 0,4K bytes:
Hi Eric,
How do you decode file /var/fm/fmd/errlog and /var/fm/fmd/fltlog?
fmdump -e, fmdump
/Tomas
--
Tomas Ögren, [EMAIL PROTECTED], http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS
Andrew Summers wrote: So, I've read the wikipedia, and have done a lot of research on google about it, but it just doesn't make sense to me. Correct me if I'm wrong, but you can take a simple 5/10/20 GB drive or whatever size, and turn it into exabytes of storage space? If that is not true, please explain the importance of this other than the self heal and those other features. I'm probably to blame for the image of endless storage. With ZFS Sparse Volumes (aka: Thin Provisioning) you can make a 1G drive _look_ like a 500TB drive, but of course it isn't. See my entry on the topic here: http://www.cuddletech.com/blog/pivot/entry.php?id=729 With ZFS Compression you can, however, potentially store 10GB of data on a 5GB drive. It really depends on what type of data your storing and how compressible it is, but I've seen almost 2:1 compression in some cases by simply turning compression on. benr. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: ZFS
Thanks Ben, and thanks Jason for clearing everything up for me via e-mail! Hope you two, and everyone here have a great Christmas and a happy holiday! This message posted from opensolaris.org ___ 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
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? 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. - Bill ___ 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
On Dec 20, 2006, at 5:46 AM, Darren J Moffat wrote: james hughes wrote: Not to add a cold blanket to this... This would be mostly a vanity erase not really a serious security erase since it will not over write the remnants of remapped sectors. Indeed and as you said there is other software to deal with this for those types of customers that need that. There are also physical destruction methods as well. This is intended as a defense in depth measure and also a sufficiently good measure for the customers that don't need full compliance with NIST like requirements that need degausing or physical destruction. Govt, finance, healthcare all require the NIST overwrite... It is intended to make customers more comfortable about handing disks back to their vendor. These are the people that have the tools to get the data back. Today we need to manually run format(1M)'s analyze/purge for that. Most banks do not return the disks, they return the top plate to get the warrantee credit and then just keep the disks... Are you saying that you don't think this is sufficiently useful that we should implement this in ZFS or are you just pointing out that for a some security policies this is not enough ? I think more the former. Lets also discuss who this policy will be enough for. The load on the system may be as large as encrypting the data if you purge all files, and if you don't then you have the problem of finding all former copies of the data. The complexity of implementation may be on par with encryption. The caveats that need to be placed in the man pages on when this is not enough are problematic, and if the customer doesn't read it... It just seems to be a lot of work for not a lot of benefit. My mind is not make up here, so these discussions are good... -- Darren J Moffat ___ security-discuss mailing list [EMAIL PROTECTED] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] What SATA controllers are people using for ZFS?
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
Re: [zfs-discuss] Thoughts on ZFS Secure Delete - without using Crypto
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? Darrn ___ 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? 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? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
