On Wed, 13 May 2009, Richard Elling wrote: > I didn't find that exact part number, but I notice that manufacturing part > 371-4196 32GB Solid State Drive, SATA Interface > is showing up in a number of systems. IIRC, this would be an Intel X25-E.
Hmm, the part number I provided was off an official quote from our authorized reseller, googling it comes up with one sun.com link: http://www.sun.com/executives/iforce/mysun/docs/Support2a_ReleaseContentInfo.html and a bunch of Japanese sites. List price was $1500, if it is actually an OEM'd Intel X25-E that's quite a markup, street price on that has dropped below $500. If it's not, it sure would be nice to see some specs. > Generally, Sun doesn't qualify new devices with EOLed systems. Understood, it just sucks to have bought a system on its deathbed without prior knowledge thereof. > Today, you can remove a cache device, but not a log device. You can > replace a log device. I guess if we ended up going this way replacing the log device with a standard hard drive in case of support issues would be the only way to go. Those log device replacement also require the replacement device be of equal or greater size? If I wanted to swap between a 32GB SSD and a 1TB SATA drive, I guess I would need to make a partition/slice on the TB drive of exactly the size of the SSD? > Before you start down this path, you should take a look at the workload > using zilstat, which will show you the kind of work the ZIL is doing. If > you don't see any ZIL activity, no need to worry about a separate log. > http://www.richardelling.com/Home/scripts-and-programs-1/zilstat Would a dramatic increase in performance when disabling the ZIL also be sufficient evidence? Even with only me as the only person using our test x4500 disabling the ZIL provides markedly better performance as originally described for certain use cases. > Usually, the log device does not need to be very big. A good strategy > would be to create a small partition or slice, say 1 GByte, on an idle disk. If the log device was too small, you potentially could end up bottlenecked waiting for transactions to be committed to free up log device blocks? > Intel claims > 3,300 4kByte random write iops. Is that before after the device gets full and starts needing to erase whole pages to write new blocks 8-/? > My rule of thumb is to have a hot spare. Having lots of hot > spares only makes a big difference for sites where you cannot > service the systems within a few days, such as remote locations. Eh, they're just downstairs, and we have 7x24 gold on them. Plus I have 5, each with 2 hot spares. I wouldn't have an issue trading a hot spare for a log device other than potential issues with the log device failing if not mirrored. > Yes, and this is what would happen in the case where the log device > completely failed while the pool was operational -- the ZIL will revert > to using the main pool. But would then go belly up if the system ever rebooted? You said currently you cannot remove a log device, if the pool reverts to an embedded log upon slog failure, and continues to work after a reboot, you've effectively removed the slog, other than I guess it might keep complaining and showing a dead slog device. > This is the case where the log device fails completely while > the pool is not operational. Upon import, the pool will look > for an operational log device and will not find it. This means > that any committed transactions that would have been in the > log device are not recoverable *and* the pool won't know > the extent of this missing information. So is there simply no recovery available for such a pool? Presumably the majority of the data in the pool would probably be fine. > OTOH, if you are paranoid and feel very strongly about CYA, then by all > means, mirror the log :-). That all depends on the outcome in that rare as it might case where the log device fails and the pool is inaccessible. If it's just a matter of some manual intervention to reset the pool to a happy state and the potential loss of any uncommitted transactions (which, according to the evil zfs tuning guide don't result in a corrupted zfs filesystem, only in potentially unhappy nfs clients), I could live with that. If all of the data in the poll is trashed and must be restored from backup, that would be problematic. > [editorial comment: it would be to Sun's benefit if Sun people would > respond to Sun product questions. Harrrummppff.] Maybe they're too busy running in circles trying to figure out what life under Oracle dominion is going to be like :(. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
