Sorry folks, the mail server is just too advanced for me. Tfhis email was in the server since 1/14/2009, and coming through now would be very misleading.
A side-method for Zhou is that (not for anyone to learn) when trouble comes and we are not ready to deal with the trouble, we just hide behind ladies since that wall provides better protection than any private network (due to the noise of my wall). This Daisy baby has no personal relationship with me. She is a professional. And Mohegan Sun is not my friend. [if you would like to play in that area, I say Foxwood, because Foxwood is my friend. Even though Daisy is my friend, I will not say Mohegan Sun is my friend because Mohegan Sun is not.] I used Daisy's name for cover, and that was all. [may not be a correct thing to do in many views, but what is done is done, if I should be punished, I will take that punishment from the sky with happiness, not a big deal.] So please, focus on the 义 part, not the Daisy baby part, in my post on that day. And again, I had limited respect for the Solaris mail server and tested the server policy with some ridiculous methods. If I had offended anyone in that process, I am sorry. Best, z ----- Original Message ----- From: "JZ" <j...@excelsioritsolutions.com> To: "A Darren Dunham" <ddun...@taos.com>; <zfs-discuss@opensolaris.org> Cc: <sc...@mohegansun.com>; "Marvin Wang, Min" <mail...@yahoo.com> Sent: Wednesday, January 14, 2009 10:40 PM Subject: Re: [zfs-discuss] a Min Wang person emailed me for free knowledge ok, you open folks are really 求知若渴. just one more, and I hope someone replies so we can save some open time. the code of 义. and what is the relationship between 义 and love? here, some public info - again, I am only saying this piece in Chinese is pretty-readable in my taste, not too much to attack, but hey, whoever wrote this, don't be a hot head. [to that blog writter: "darn", if you also know what that means] http://blog.ce.cn/html/04/101804-15445.html and, someone on the list can you please provide a translated url to save some open time? every darn hour multiplied by the number of readers here, the help better comes fast, before I darn all of you open folks. [for the beloved ones, attached an even better code. There has been a tough nut, let me see if I can crack that nut with this public code. :-) ] z, at home, wondering why Daisy baby is not calling... not interested in the list discussion anymore ----- Original Message ----- From: "JZ" <j...@excelsioritsolutions.com> To: "A Darren Dunham" <ddun...@taos.com>; <zfs-discuss@opensolaris.org> Sent: Wednesday, January 14, 2009 8:38 PM Subject: Re: [zfs-discuss] What are the usual suspects in data errors? > Folks, I am very sorry, for don't know how to be not misleading. > > I was not challenging the Ten Commandments. > That is a good code. And maybe the first one we need to follow. > > Vain and pride and arrogance and courage are all very different, but very > similar. > Before you can truely understand the code of love, you will have to be > very > careful. > > And then, there are beyond. > > Folks, this is a technology discussion, not a religious discussion. > I love you all. > I do not want to see you folks cannot make to your dream states with your > technology knowhow just because you don't even understand the basic code > of > love. > > Folks, I love you all. > OMG, I did not teach King and High anything beyond what I have said here > in > open. > It that not enough to make the darn open discussion go on? > Please. > > > [do you know if not because of the 400000 friends, I can be dead by now > talking this much to an open list???] > > best, > z > > > ----- Original Message ----- > From: "JZ" <j...@excelsioritsolutions.com> > To: "A Darren Dunham" <ddun...@taos.com>; <zfs-discuss@opensolaris.org> > Sent: Wednesday, January 14, 2009 7:48 PM > Subject: Re: [zfs-discuss] What are the usual suspects in data errors? > > >> folks, please, chatting on - don't make me stop you, we are all open >> folks. >> >> >> [but darn] >> >> ok, thank you much for the anticipation for something actually useful, >> here >> is another thing I shared with MS Storage but not with you folks yet -- >> >> we win with real advantages, not lies, not scales, but only real knowhow. >> >> cheers, >> z >> >> >> >> ----- Original Message ----- >> From: "JZ" <j...@excelsioritsolutions.com> >> To: "A Darren Dunham" <ddun...@taos.com>; <zfs-discuss@opensolaris.org> >> Sent: Wednesday, January 14, 2009 7:38 PM >> Subject: Re: [zfs-discuss] What are the usual suspects in data errors? >> >> >>> darn, Darren, learning fast! >>> >>> best, >>> z >>> >>> >>> ----- Original Message ----- >>> From: "A Darren Dunham" <ddun...@taos.com> >>> To: <zfs-discuss@opensolaris.org> >>> Sent: Wednesday, January 14, 2009 6:15 PM >>> Subject: Re: [zfs-discuss] What are the usual suspects in data errors? >>> >>> >>>> On Wed, Jan 14, 2009 at 04:39:03PM -0600, Gary Mills wrote: >>>>> I realize that any error can occur in a storage subsystem, but most >>>>> of these have an extremely low probability. I'm interested in this >>>>> discussion in only those that do occur occasionally, and that are >>>>> not catastrophic. >>>> >>>> What level is "extremely low" here? >>>> >>>>> Many of those components have their own error checking. Some have >>>>> error correction. For example, parity checking is done on a SCSI bus, >>>>> unless it's specifically disabled. Do SATA and PATA connections also >>>>> do error checking? Disk sector I/O uses CRC error checking and >>>>> correction. Memory buffers would often be protected by parity memory. >>>>> Is there any more that I've missed? >>>> >>>> Reports suggest that bugs in drive firmware could account for errors at >>>> a level that is not insignificant. >>>> >>>>> What can go wrong with the disk controller? A simple seek to the >>>>> wrong track is not a problem because the track number is encoded on >>>>> the platter. The controller will simply recalibrate the mechanism and >>>>> retry the seek. If it computes the wrong sector, that would be a >>>>> problem. Does this happen with any frequency? >>>> >>>> Netapp documents certain rewrite bugs that they've specifically seen. >>>> I >>>> would imagine they have good data on the frequency that they see it in >>>> the field. >>>> >>>>> In this case, ZFS >>>>> would detect a checksum error and obtain the data from its redundant >>>>> copy. >>>> >>>> Correct. >>>> >>>>> A logic error in ZFS might result in incorrect metadata being written >>>>> with valid checksum. In this case, ZFS might panic on import or might >>>>> correct the error. How is this sort of error prevented? >>>> >>>> It's very difficult to protect yourself from software bugs with the >>>> same >>>> piece of software. You can create assertions that are hopefully >>>> simpler >>>> and less prone to errors, but they will not catch all bugs. >>>> >>>>> Some errors might result from a loss of power if some ZFS data was >>>>> written to a disk cache but never was written to the disk platter. >>>>> Again, ZFS might panic on import or might correct the error. How is >>>>> this sort of error prevented? >>>> >>>> ZFS uses a multi-stage commit. It relies on the "disk" responding to a >>>> request to flush caches to the disk. If that assumption is correct, >>>> then there is no problem in general with power issues. The disk is >>>> consistent both before and after the cache is flushed. >>>> >>>> -- >>>> Darren >>>> _______________________________________________ >>>> 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 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
