Hi, Miles! Hope, weather is fine at your place. :-) On Sat, Jun 20, 2009 at 5:09 AM, Miles Nordin wrote: > I understood Bogdan's post was a trap: ``provide bug numbers. Oh, > they're fixed? nothing to see here then. no bugs? nothing to see > here then.''
Would be great if you do not put a words in my mouth, please. All what I wanted to say (not to you, but to everyone, including myself): we have to be constructive and make common sense (which is not so common, unfortunately). Otherwise I am not sure we are welcomed here. > Does this mean ZFS was not broken before those bugs were filed? Does this mean ZFS has no more bugs? Does this mean that we have stop using it? Was flame throwing dragons real? Is there a life on a Mars?.. :) Just kidding, never mind. :-) > Also, as I said elsewhere, there's a barrier controlled by Sun to > getting bugs accepted. Looks like you're new here. :-) E.g. there is a list very nasty bugs in Sun Java that has been filled in 2006 or earlier and lots of people suffering (including me) now, in 2009. But hey, not our job to cry and FUD around, I think. How about this scenario: either let's find workaround (and provide on the same bugreport) or, if it is so critical (and Sun rejected it), let's make a nice PDF with exploit sources or step-by-step instruction how to crash your system down to italian spaghetti and publish on a Slashdot :-) to let "good" guys find the rest how to kill solarises in two seconds. Then I am 100.0% sure Sun will patch it just right immediately. It is exaggerated, but still do you like it? But instead to do this way, somewhat Slashdot folks more just talks vague blah-blah-blah (mostly being modded "insightful: 5" or "interesting: 5", while is a just a troll or FUD) rather then doing something really useful. I am pretty much sure, if there will be graphic comparisons with a source code on a Phoronix or similar resources like "FAT32 seriously beats ZFS in stability" or "How to DoS your ZFS from Google Android" or "Linux's ext2 is quince faster than ZFS" — then this would add more adrenaline to Sun's folks fixing it. However... there are only Slashdot talks that are nothing more than just a Slashdot talks. I understand you and other Slashdot folks had some problems. But I hadn't, including lots of other people that ZFS works for them just fine. Thus it is even/even. :-P > HTH. No, it does not. Just yet another e-mail posting that does not really helps fixing bugs. :-) > I think a better question would be: what kind of tests would be most > promising for turning some subclass of these lost pools reported on > the mailing list into an actionable bug? > > my first bet would be writing tools that test for ignored sync cache > commands leading to lost writes, and apply them to the case when iSCSI > targets are rebooted but the initiator isn't. > > I think in the process of writing the tool you'll immediately bump > into a defect, because you'll realize there is no equivalent of a > 'hard' iSCSI mount like there is in NFS. and there cannot be a strict > equivalent to 'hard' mounts in iSCSI, because we want zpool redundancy > to preserve availability when an iSCSI target goes away. I think the > whole model is wrong somehow. Now this DOES make sense! :-) Actually, iSCSI has lots of various small issues that grows into serious problems, thus that needs to be brought up, clearly described and I am sure suggestions are welcome. If you want to help with stress-tests, then I can help you in this, I think. For example, here is very nice article of iSCSI setup for Time Machine. The article is also very nice academic example to let Slashdot folks learn once how to make sense writing docs, complains and reports: http://www.kamiogi.net/Kamiogi/Frame_Dragging/Entries/2009/5/25_OpenSolaris_ZFS_iSCSI_Time_Machine_in_20_Minutes_or_Less.html So go check it out, follow the steps and make the same. Then write some scripts that can bring it down, find why, find where is the problem, suggest solution and publish this in Sun's bugs database. If you do that — my applauds and respect. How this sounds to you? :-) -- Kind regards, BM Things, that are stupid at the beginning, rarely ends up wisely. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
