On 17 apr 2010, at 20.51, Edward Ned Harvey wrote: >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- >> boun...@opensolaris.org] On Behalf Of Dave Vrona >> >> 1) Mirroring. Leaving cost out of it, should ZIL and/or L2ARC SSDs be >> mirrored ? ... > Personally, I recommend the latest build from genunix, and I recommend no > mirroring for log devices, except in the most critical of situations, such > as a machine that processes credit card transactions or stuff like that. ...
It depends if you think this is a risk or not. Personally I do - disk systems are always acting up at the same time as you have other problem, in addition to the other times. Those SSDs I have tried and read about seem to be a even more crappy than disks in general, and I wouldn't trust them for about anything that I want to keep. If you handle something that you really must not lose, you should probably have some other redundancy too, like parallel servers in different locations, and you may skip redundancy on many components in each individual server. If you have a more standard application, restricted budget, and still don't want to lose file system transactions, I believe you should have at least as good redundancy on your ZILs as on the rest of the disk system. Examples are: - Mail servers (you are not allowed to lose email). - NFS servers (to follow the protocol, not lose user data, and not leave clients in undefined/bad states). - A general file server or other application server where people expect the bits they have put in there to be there, even though the server happened to crash. - All other applications where you want to take as many steps as possible to not lose data. On 17 apr 2010, at 21.09, Edward Ned Harvey wrote: >>> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- >>> boun...@opensolaris.org] On Behalf Of Dave Vrona >>> >> >>> 2) ZIL write cache. It appears some have disabled the write cache on >>> the X-25E. This results in a 5 fold performance hit but it >> eliminates >>> a potential mechanism for data loss. Is this valid? If I can mirror >>> ZIL, I imagine this is no longer a concern? ... I'd say it is of concern - the X25-E does just straight ignore cache flush commands (idiots!), but disabling the write cache *seems* to put it in more of a write though mode, so that cache flushing shouldn't be needed. Some tests have shown that it *may* loose one or a few transactions anyway if it suddenly loses power. X25-E is, sadly, not a storage device worth the name, at least not until Intel has fixed the problems with it, which doesn't seem to be happening, sadly, Intel seems the just keep quiet and ignore those few that are actually checking out what their disks are doing - they still sell a lot to all the others, I guess. ... > The write cache is either the volatile memory on the disk, or the presumably > nonvolatile memory in the HBA. You should never enable volatile disk write > cache. This is not correct. Zfs normally enables the write cache, and assumes the devices are correctly honoring cache flush commands. Sadly, there are devices out there that ignores them, because they wan't to look like they have higher performance than they have, or because of bugs, or in some cases because of just plain ignorance from the implementors. Intel X25-E is sadly one of those bad devices. [Traditionally, Solaris has always tried to disable volatile disk write caches, zfs changes this.] > You should only enable the HBA writeback cache if (a) the HBA has > nonvolatile memory, such as battery backed up, and (b) you don't have a > dedicated ZIL log device. And (c) you don't mind having the same problem with non redundancy as for the ZIL device: If you have writeback caching enabled in your HBA and your HBA fails, some of your data will be lost in the HBA cache, a bit similar to the ZIL case. Your file system may be in a little worse state, since zfs is always consistent on storage, but if some of the recently written storage is lost in the HBA cache, it won't be consistent on disk. And HBAs do seem to fail a bit more often than most other computer boards, for some strange reason. /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
