Re: [zfs-discuss] Thumper Origins Q
Richard Elling wrote: One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. We had this fixed in T3 land awhile ago so I think most storage arrays don't do the 1:1 mapping anymore. It's striped down the drives. In theory, you could lose more then one drive in a T3 mirror and still maintain data in certain situations. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Tue, Jan 30, 2007 at 06:32:14PM +0100, Roch - PAE wrote: The only benefit of using a HW RAID controller with ZFS is that it reduces the I/O that the host needs to do, but the trade off is that ZFS cannot do combinatorial parity reconstruction so that it could only detect errors, not correct them. It would be cool if the host could offload the RAID I/O to a HW controller but still be able to read the individual stripes to perform combinatorial parity reconstruction. right but in this situation, if the cosmic ray / bit flip hits on the way to the controller, the array will store wrong data and we will not be able to reconstruct the correct block. So having multiple I/Os here improves the time to data loss metric. You missed my point. Assume _new_ RAID HW that allows the host to read the individual stripes. The ZFS could offload I/O to the RAID HW but, when a checksum fails to validate on read, THEN go read the individual stripes and parity and do the combinatorial reconstruction as if the RAID HW didn't exist. I don't believe such RAID HW exists, therefore the point is moot. But if such HW ever comes along... Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Nicolas Williams writes: On Tue, Jan 30, 2007 at 06:32:14PM +0100, Roch - PAE wrote: The only benefit of using a HW RAID controller with ZFS is that it reduces the I/O that the host needs to do, but the trade off is that ZFS cannot do combinatorial parity reconstruction so that it could only detect errors, not correct them. It would be cool if the host could offload the RAID I/O to a HW controller but still be able to read the individual stripes to perform combinatorial parity reconstruction. right but in this situation, if the cosmic ray / bit flip hits on the way to the controller, the array will store wrong data and we will not be able to reconstruct the correct block. So having multiple I/Os here improves the time to data loss metric. You missed my point. Assume _new_ RAID HW that allows the host to read the individual stripes. The ZFS could offload I/O to the RAID HW but, when a checksum fails to validate on read, THEN go read the individual stripes and parity and do the combinatorial reconstruction as if the RAID HW didn't exist. I don't believe such RAID HW exists, therefore the point is moot. But if such HW ever comes along... Nico -- I think I got the point. Mine was that if the data travels a single time toward the storage and is corrupted along the way then there will be no hope of recovering it since the array was given bad data. Having the data travel twice is a benefit for MTTDL. -r ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Tue, Jan 30, 2007 at 06:41:25PM +0100, Roch - PAE wrote: I think I got the point. Mine was that if the data travels a single time toward the storage and is corrupted along the way then there will be no hope of recovering it since the array was given bad data. Having the data travel twice is a benefit for MTTDL. Well, this is certainly true, so I missed your point :) Mirroring would help. A mirror with RAID-Z members would only double the I/O and still provide for combinatorial reconstruction when the errors arise from bit rot on the rotating rust or on the path from the RAID HW to the individual disks, as opposed to on the path from the host to the RAID HW. Depending on the relative error rates this could be a useful trade-off to make (plus, mirroring should halve access times while RAID-Z, if disk heads can be synchronized and the disks have similar geometries, can provide an N multiple increase in bandwidth, though I'm told that disk head synchronization is no longer a common feature). Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Nicolas Williams wrote: On Tue, Jan 30, 2007 at 06:41:25PM +0100, Roch - PAE wrote: I think I got the point. Mine was that if the data travels a single time toward the storage and is corrupted along the way then there will be no hope of recovering it since the array was given bad data. Having the data travel twice is a benefit for MTTDL. Well, this is certainly true, so I missed your point :) This technique is used in many situations where the BER is non-zero (pretty much always) and the data is very important. For example, consider command sequences being sent to a deep space probe -- you really, really, really want the correct commands to be received, so you use ECC and repeat the commands many times. There are mathematical models for this. Slow? Yes. Correct? More likely. Mirroring would help. A mirror with RAID-Z members would only double the I/O and still provide for combinatorial reconstruction when the errors arise from bit rot on the rotating rust or on the path from the RAID HW to the individual disks, as opposed to on the path from the host to the RAID HW. Depending on the relative error rates this could be a useful trade-off to make (plus, mirroring should halve access times while RAID-Z, if disk heads can be synchronized and the disks have similar geometries, can provide an N multiple increase in bandwidth, though I'm told that disk head synchronization is no longer a common feature). One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On 30-Jan-07, at 5:48 PM, Richard Elling wrote: ... One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. Yes, this is another feature for the Why ZFS can beat RAID FAQ. --T -- richard ___ 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] Thumper Origins Q
Richard Elling wrote: One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. This may well offer better protection against drive firmware bugs. Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. -- richard This does not seem to be enforced (! 1:1) in code anywhere that I can see. By not required are you pointing that this is able to be done in the future, or is this the case right now and I am missing the code that accomplishes this? I think he means that if a block fails to write on a VDEV, ZFS can write that data elsewhere and is not forced to use that location. As opposed to SVM as an example, where the mirror must try to write at a particular offset or fail. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. -- richard This does not seem to be enforced (! 1:1) in code anywhere that I can see. By not required are you pointing that this is able to be done in the future, or is this the case right now and I am missing the code that accomplishes this? I think he means that if a block fails to write on a VDEV, ZFS can write that data elsewhere and is not forced to use that location. As opposed to SVM as an example, where the mirror must try to write at a particular offset or fail. Understood, I am asking if the current code base actually does this as I do not see the code path that deals with this case. -Wade ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
I think he means that if a block fails to write on a VDEV, ZFS can write that data elsewhere and is not forced to use that location. As opposed to SVM as an example, where the mirror must try to write at a particular offset or fail. Understood, I am asking if the current code base actually does this as I do not see the code path that deals with this case. Got it. So what does happen with a block write failure now on one side of a mirror? Does it retry forever or eventually fail the device? -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
[EMAIL PROTECTED] wrote: One of the benefits of ZFS is that not only is head synchronization not needed, but also block offsets do not have to be the same. For example, in a traditional mirror, block 1 on device 1 is paired with block 1 on device 2. In ZFS, this 1:1 mapping is not required. I believe this will result in ZFS being more resilient to disks with multiple block failures. In order for a traditional RAID to implement this, it would basically need to [re]invent a file system. -- richard Richard, This does not seem to be enforced (! 1:1) in code anywhere that I can see. By not required are you pointing that this is able to be done in the future, or is this the case right now and I am missing the code that accomplishes this? IMHO, the best description of how mirrors work is: http://blogs.sun.com/bonwick/entry/smokin_mirrors The ditto block code is interesting, too. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On 1/25/07, Jason J. W. Williams [EMAIL PROTECTED] wrote: Having snapshots in the filesystem that work so well is really nice. How are y'all quiescing the DB? So the DBA has a cronjob that puts the DB (Oracle) into hot backup mode, takes a snapshot of all affected filesystems (i.e. log + datafile + binary) and then releases the database. Oracle lives in its own zone and the DBA gets root to the zone. The 2 ZFS datasets from 2 pools are datasets imported into the zone. -- Just me, Wire ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Thu, Jan 25, 2007 at 10:57:17AM +0800, Wee Yeh Tan wrote: On 1/25/07, Bryan Cantrill [EMAIL PROTECTED] wrote: ... after all, what was ZFS going to do with that expensive but useless hardware RAID controller? ... I almost rolled over reading this. This is exactly what I went through when we moved our database server out from Vx** to ZFS. We had a 3510 and were thinking how best to configure the RAID. In the end, we ripped out the controller board and used the 3510 as a JBOD directly attached to the server. My DBA was so happy with this setup (especially with the snapshot capability) he is asking for another such setup. The only benefit of using a HW RAID controller with ZFS is that it reduces the I/O that the host needs to do, but the trade off is that ZFS cannot do combinatorial parity reconstruction so that it could only detect errors, not correct them. It would be cool if the host could offload the RAID I/O to a HW controller but still be able to read the individual stripes to perform combinatorial parity reconstruction. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Nicolas Williams wrote: On Thu, Jan 25, 2007 at 10:57:17AM +0800, Wee Yeh Tan wrote: On 1/25/07, Bryan Cantrill [EMAIL PROTECTED] wrote: ... after all, what was ZFS going to do with that expensive but useless hardware RAID controller? ... I almost rolled over reading this. This is exactly what I went through when we moved our database server out from Vx** to ZFS. We had a 3510 and were thinking how best to configure the RAID. In the end, we ripped out the controller board and used the 3510 as a JBOD directly attached to the server. My DBA was so happy with this setup (especially with the snapshot capability) he is asking for another such setup. The only benefit of using a HW RAID controller with ZFS is that it reduces the I/O that the host needs to do, but the trade off is that ZFS cannot do combinatorial parity reconstruction so that it could only detect errors, not correct them. It would be cool if the host could offload the RAID I/O to a HW controller but still be able to read the individual stripes to perform combinatorial parity reconstruction. OK, not the *only* benefit :-) IMHO, the most visible benefit is the nonvolatile write cache. The RAID configuration is simply an implementation detail. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Thu, Jan 25, 2007 at 09:52:05AM -0800, Richard Elling wrote: Nicolas Williams wrote: The only benefit of using a HW RAID controller with ZFS is that it reduces the I/O that the host needs to do, but the trade off is that ZFS cannot do combinatorial parity reconstruction so that it could only detect errors, not correct them. It would be cool if the host could offload the RAID I/O to a HW controller but still be able to read the individual stripes to perform combinatorial parity reconstruction. OK, not the *only* benefit :-) IMHO, the most visible benefit is the nonvolatile write cache. The RAID configuration is simply an implementation detail. Well, yes, but NVRAM could be a generic device. The task of taking one I/O from the host and mapping it to N + parity I/Os to actual devices is very specific to RAID. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Wed, Jan 24, 2007 at 12:15:21AM -0700, Jason J. W. Williams wrote: Wow. That's an incredibly cool story. Thank you for sharing it! Does the Thumper today pretty much resemble what you saw then? Yes, amazingly so: 4-way, 48 spindles, 4u. The real beauty of the match between ZFS and Thumper was (and is) that ZFS unlocks new economics in storage -- smart software achieving high performance and ultra-high reliability with dense, cheap hardware -- and that Thumper was (and is) the physical embodiment of those economics. And without giving away too much of our future roadmap, suffice it to say that one should expect much, much more from Sun in this vein: innovative software and innovative hardware working together to deliver world-beating systems with undeniable economics. And actually, as long as we're talking history, you might be interested to know the story behind the name Thumper: Fowler initially suggested the name as something of a joke, but, as often happens with Fowler, he tells a joke with a straight face once too many to one person too many, and next thing you know it's the plan of record. I had suggested the name Humper for the server that became Andromeda (the x8000 series) -- so you could order a datacenter by asking for (say) two Humpers and five Thumpers. (And I loved the idea of asking would you like a Humper for your Thumper?) But Fowler said the name was too risque (!). Fortunately the name Thumper stuck... - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Actually, it was meant to hold the entire electronic transcript of the George Bush impeachment proceedings ... we were thinking ahead. Fortunately, larger disks became available in time. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On 24/1/07 9:06, Bryan Cantrill [EMAIL PROTECTED] wrote: But Fowler said the name was too risque (!). Fortunately the name Thumper stuck... I assumed it was a reference to Bambi... That's what comes from having small children :-) Cheers, Chris ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Chris, well, Thumper is actually a reference to Bambi The comment about being risque was refering to Humper as a codename proposed for a related server ( and e.g. leo.org confirms that is has a meaning labelled as [vulg.] :-) -- Roland Chris Ridd schrieb: On 24/1/07 9:06, Bryan Cantrill [EMAIL PROTECTED] wrote: But Fowler said the name was too risque (!). Fortunately the name Thumper stuck... I assumed it was a reference to Bambi... That's what comes from having small children :-) Cheers, Chris ___ 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] Thumper Origins Q
well, Thumper is actually a reference to Bambi You'd have to ask Fowler, but certainly when he coined it, Bambi was the last thing on anyone's mind. I believe Fowler's intention was one that thumps (or, in the unique parlance of a certain Commander-in-Chief, one that gives a thumpin'). - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Bryan Cantrill stated: well, Thumper is actually a reference to Bambi I keep thinking of the classic AC/DC song when Fowler and thumpers are mentioned.. s/thunder/thumper/ You'd have to ask Fowler, but certainly when he coined it, Bambi was the last thing on anyone's mind. I believe Fowler's intention was one that thumps (or, in the unique parlance of a certain Commander-in-Chief, one that gives a thumpin'). - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Sean. . ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Jan 24, 2007, at 12:41, Bryan Cantrill wrote: well, Thumper is actually a reference to Bambi You'd have to ask Fowler, but certainly when he coined it, Bambi was the last thing on anyone's mind. I believe Fowler's intention was one that thumps (or, in the unique parlance of a certain Commander-in-Chief, one that gives a thumpin'). You can take your pick of things that thump here: http://en.wikipedia.org/wiki/Thumper given the other name is the X4500 .. it does seem like it should be a weapon --- .je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
You can take your pick of things that thump here: http://en.wikipedia.org/wiki/Thumper I think it's safe to say that Fowler was thinking more along the lines of whomever dubbed the M79 grenade launcher -- which you can safely bet was not named after a fictional bunny... - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Wed, 24 Jan 2007, Sean McGrath - Sun Microsystems Ireland wrote: Bryan Cantrill stated: well, Thumper is actually a reference to Bambi I keep thinking of the classic AC/DC song when Fowler and thumpers are mentioned.. s/thunder/thumper/ Yeah, AC/DC songs seem to be most apropos for Sun at the moment: * Thumperstruck (the subject of this thread) * For those about to rock (the successor to the US-IV) * Back in back (Sun's return to profitability as announced yesterday) Although Queen is almost as good: * We will Rock you * We are the champions And what do M$ users have? Courtesy of the Rolling Stones: * (I can't get) no satisfaction * 19th Nervous breakdown :-) -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Wed, 24 Jan 2007, Bryan Cantrill wrote: I think it's safe to say that Fowler was thinking more along the lines Presumably, that's John Fowler? -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-group.com/rich ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Bryan Cantrill wrote: well, Thumper is actually a reference to Bambi You'd have to ask Fowler, but certainly when he coined it, Bambi was the last thing on anyone's mind. I believe Fowler's intention was one that thumps (or, in the unique parlance of a certain Commander-in-Chief, one that gives a thumpin'). me, I always thought of calling sandworms. sandworms use up a lot of space, you see... And bring in a lot of cash (IIRC, the worms caused the spice and the spice was mined) It was my association too. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
[EMAIL PROTECTED] wrote: Bryan Cantrill wrote: well, Thumper is actually a reference to Bambi You'd have to ask Fowler, but certainly when he coined it, Bambi was the last thing on anyone's mind. I believe Fowler's intention was one that thumps (or, in the unique parlance of a certain Commander-in-Chief, one that gives a thumpin'). me, I always thought of calling sandworms. sandworms use up a lot of space, you see... And bring in a lot of cash (IIRC, the worms caused the spice and the spice was mined) It was my association too. ...and if you imagine 48 head positioner arms moving at once one can imagine the vibration would travel through sand, is all. Just means it's a good name, I suppose! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
On Jan 24, 2007, at 04:06, Bryan Cantrill wrote: On Wed, Jan 24, 2007 at 12:15:21AM -0700, Jason J. W. Williams wrote: Wow. That's an incredibly cool story. Thank you for sharing it! Does the Thumper today pretty much resemble what you saw then? Yes, amazingly so: 4-way, 48 spindles, 4u. The real beauty of the match between ZFS and Thumper was (and is) that ZFS unlocks new economics in storage -- smart software achieving high performance and ultra-high If Thumper and ZFS were born independently, how were all those disks going to be used without ZFS? It seems logical that the two be mated, but AFAIK there is no hardware RAID available in Thumpers. Was normal software RAID the plan? Treating each disk as a separate mount point? Just curious. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re[2]: [zfs-discuss] Thumper Origins Q
Hello David, Thursday, January 25, 2007, 1:47:57 AM, you wrote: DM On Jan 24, 2007, at 04:06, Bryan Cantrill wrote: On Wed, Jan 24, 2007 at 12:15:21AM -0700, Jason J. W. Williams wrote: Wow. That's an incredibly cool story. Thank you for sharing it! Does the Thumper today pretty much resemble what you saw then? Yes, amazingly so: 4-way, 48 spindles, 4u. The real beauty of the match between ZFS and Thumper was (and is) that ZFS unlocks new economics in storage -- smart software achieving high performance and ultra-high DM If Thumper and ZFS were born independently, how were all those disks DM going to be used without ZFS? It seems logical that the two be mated, DM but AFAIK there is no hardware RAID available in Thumpers. DM Was normal software RAID the plan? Treating each disk as a separate DM mount point? I guess Linux was considered probably with LVM or something else. -- 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] Thumper Origins Q
Hi Wee, Having snapshots in the filesystem that work so well is really nice. How are y'all quiescing the DB? Best Regards, J On 1/24/07, Wee Yeh Tan [EMAIL PROTECTED] wrote: On 1/25/07, Bryan Cantrill [EMAIL PROTECTED] wrote: ... after all, what was ZFS going to do with that expensive but useless hardware RAID controller? ... I almost rolled over reading this. This is exactly what I went through when we moved our database server out from Vx** to ZFS. We had a 3510 and were thinking how best to configure the RAID. In the end, we ripped out the controller board and used the 3510 as a JBOD directly attached to the server. My DBA was so happy with this setup (especially with the snapshot capability) he is asking for another such setup. -- Just me, Wire ... ___ 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] Thumper Origins Q
Hi All, This is a bit off-topic...but since the Thumper is the poster child for ZFS I hope its not too off-topic. What are the actual origins of the Thumper? I've heard varying stories in word and print. It appears that the Thumper was the original server Bechtolsheim designed at Kealia as a massive video server. However, when we were first told about it a year ago through Sun contacts Thumper was described as a part of a scalabe iSCSI storage system, where Thumpers would be connected to a head (which looked a lot like a pair of X4200s) via iSCSI that would then present the storage over iSCSI and NFS. Recently, other sources mentioned they were told about the same time that Thumper was part of the Honeycomb project. So I was curious if anyone had any insights into the history/origins of the Thumper...or just wanted to throw more rumors on the fire. ;-) Thanks in advance for your indulgence. Best Regards, Jason ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Jason J. W. Williams wrote: Hi All, This is a bit off-topic...but since the Thumper is the poster child for ZFS I hope its not too off-topic. What are the actual origins of the Thumper? I've heard varying stories in word and print. It appears that the Thumper was the original server Bechtolsheim designed at Kealia as a massive video server. However, when we were first told about it a year ago through Sun contacts Thumper was described as a part of a scalabe iSCSI storage system, where Thumpers would be connected to a head (which looked a lot like a pair of X4200s) via iSCSI that would then present the storage over iSCSI and NFS. Recently, other sources mentioned they were told about the same time that Thumper was part of the Honeycomb project. So I was curious if anyone had any insights into the history/origins of the Thumper...or just wanted to throw more rumors on the fire. ;-) Thumper was created to hold the the entire electronic transcript of the Bill Clinton impeachment proceedings... Thanks in advance for your indulgence. 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
Re: [zfs-discuss] Thumper Origins Q
Neal Pollack wrote: Jason J. W. Williams wrote: So I was curious if anyone had any insights into the history/origins of the Thumper...or just wanted to throw more rumors on the fire. ;-) Thumper was created to hold the the entire electronic transcript of the Bill Clinton impeachment proceedings... Actually, it was meant to hold the entire electronic transcript of the George Bush impeachment proceedings ... we were thinking ahead. Yes thats a joke for those playing at home. Please take it with the humor it was intended. :-P ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Jason J. W. Williams wrote: Hi All, This is a bit off-topic...but since the Thumper is the poster child for ZFS I hope its not too off-topic. What are the actual origins of the Thumper? I've heard varying stories in word and print. It appears that the Thumper was the original server Bechtolsheim designed at Kealia as a massive video server. However, when we were first told about it a year ago through Sun contacts Thumper was described as a part of a scalabe iSCSI storage system, where Thumpers would be connected to a head (which looked a lot like a pair of X4200s) via iSCSI that would then present the storage over iSCSI and NFS. Recently, other sources mentioned they were told about the same time that Thumper was part of the Honeycomb project. That sounds more like the StorageTek 5320 systems. So I was curious if anyone had any insights into the history/origins of the Thumper...or just wanted to throw more rumors on the fire. ;-) Personally, I see it as a modern version of the SSA-100 (also designed by Andy) -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
This is a bit off-topic...but since the Thumper is the poster child for ZFS I hope its not too off-topic. What are the actual origins of the Thumper? I've heard varying stories in word and print. It appears that the Thumper was the original server Bechtolsheim designed at Kealia as a massive video server. That's correct -- it was originally called the StreamStor. Speaking personally, I first learned about it in the meeting with Andy that I described here: http://blogs.sun.com/bmc/entry/man_myth_legend I think it might be true that this was the first that anyone in Solaris had heard of it. Certainly, it was the first time that Andy had ever heard of ZFS. It was a very high bandwidth conversation, at any rate. ;) After the meeting, I returned post-haste to Menlo Park, where I excitedly described the box to Jeff Bonwick, Bill Moore and Bart Smaalders. Bill said something like I gotta see this thing and sometime later (perhaps the next week?) Bill, Bart and I went down to visit Andy. Andy gave us a much more detailed tour, with Bill asking all sorts of technical questions about the hardware (many of which were something like how did you get a supplier to build that for you?!). After the tour, Andy took the three of us to lunch, and it was one of those moments that I won't forget: Bart, Bill, Andy and I sitting in the late afternoon Palo Alto sun, with us very excited about his hardware, and Andy very excited about our software. Everyone realized that these two projects -- born independently -- were made for each other, that together they would change the market. It was one of those rare moments that reminds you why you got into this line of work -- and I feel lucky to have shared in it. - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Thumper Origins Q
Wow. That's an incredibly cool story. Thank you for sharing it! Does the Thumper today pretty much resemble what you saw then? Best Regards, Jason On 1/23/07, Bryan Cantrill [EMAIL PROTECTED] wrote: This is a bit off-topic...but since the Thumper is the poster child for ZFS I hope its not too off-topic. What are the actual origins of the Thumper? I've heard varying stories in word and print. It appears that the Thumper was the original server Bechtolsheim designed at Kealia as a massive video server. That's correct -- it was originally called the StreamStor. Speaking personally, I first learned about it in the meeting with Andy that I described here: http://blogs.sun.com/bmc/entry/man_myth_legend I think it might be true that this was the first that anyone in Solaris had heard of it. Certainly, it was the first time that Andy had ever heard of ZFS. It was a very high bandwidth conversation, at any rate. ;) After the meeting, I returned post-haste to Menlo Park, where I excitedly described the box to Jeff Bonwick, Bill Moore and Bart Smaalders. Bill said something like I gotta see this thing and sometime later (perhaps the next week?) Bill, Bart and I went down to visit Andy. Andy gave us a much more detailed tour, with Bill asking all sorts of technical questions about the hardware (many of which were something like how did you get a supplier to build that for you?!). After the tour, Andy took the three of us to lunch, and it was one of those moments that I won't forget: Bart, Bill, Andy and I sitting in the late afternoon Palo Alto sun, with us very excited about his hardware, and Andy very excited about our software. Everyone realized that these two projects -- born independently -- were made for each other, that together they would change the market. It was one of those rare moments that reminds you why you got into this line of work -- and I feel lucky to have shared in it. - Bryan -- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
