Artem Belevich wrote: > Log seems to be somewhat weak point in ZFS. If you lose your log > device, you will lose your pool. In ZFS losing *any* vdev causes a pool to fault! The log vdev is no different and is not a weak point in that regard. In ZFS *every* vdev should be redundant. In the case of a log this means a MIRROR since a log cannot be a RAIDZ. That's not a big deal since you really should put the MIRROR disks on different controllers, and preferably using different drives, independent cables & power supplies, etc. (I think a cache vdev is different and need not be reliable, but I have not tested to see what happens if it is not present when the pool is imported) The ZIL may have bugs but it's a very important feature to have, necessary in a transactional filesystem. A mythical "zfsck" program could probably wipe out the ZIL allowing the pool to import from the most recent uberblock state and losing a few seconds of sync's, better than nothing. Tricking ZFS into importing a pool with the log vdev missing is probably harder. > I'd say that SSD are probably the best fit for slog role. A PCI-e SSD like the OCZ P84 with sustained writes "up to" 600 MB/s might be a possibility for a high-throughput database server, if it uses an interface we have a driver for.Received on Fri Nov 13 2009 - 01:51:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC