>>>>> "el" == Eugen Leitl <eu...@leitl.org> writes:
el> Wouldn't it be better investing these 300-350 EUR into 16
el> GByte or more of system memory, and a cheap UPS?
If you think the UPS is good enough that you never have to worry about
your machine rebooting then the extra memory isn't needed to match the
ACARD/hyperdrive performacne---just disable ZIL writing. AIUI there
is zero point to making a ramdisk slog because you are just copying
from one area of memory into another.
IMHO the overall disabling the ZIL is not dumb, but should be obvious
UPS is totally unequivalent to slog because it doesn't protect against
kernel panics, which are quite common on ZFS NAS if you include cases
where the system didn't actually panic but became unresponsive and had
to be hard-rebooted (ex., for something as simple as ``a drive went
bad by becoming slow''), or cases where you tried to shutdown but the
box got hung somewhere in SMF shutdown land because one of the hundred
little scriptletts decided never to finish.
Also in the real world people trip over cables, NYC mains is more
reliable than UPS power bc of equipment failures and botched battery
upgrades and nonserious sites without bypass switches, blah blah blah.
The interesting middle-ground someone brought up months ago was a
cluster with two RAMdisks, each host iscsi-exporting to the other, and
whichever node is active runs a mirrored slog of the two ramdisks.
The actual slog does not really need to be mirrored so much as `one
ramdisk stored on the inactive member', just 1 copy, just get the data
_off_ the node we're worried about panicing, then if something goes
wrong the inactive member ought to push a copy of the slog out
somewhere else before trying to force-import the pool in case one of
the main pool devices or its contents is poisonous, but then once
imported the newly-active member can discard its local slog ramdisk
and keep just the remote one attached. IMHO this general idea's got
long-term potential, the idea being: ``treat data stored in RAM on <n>
nodes as somewhat nonvolatile (given there exists a procedure to
follow if it's lost anyway, such as `restart all the NFS clients' or
`live with a little bit of lost email')''.
pgpPXhQP0hfmZ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
