>>>>> "t" == Tim <t...@tcsac.net> writes: t> I would like to believe it has more to do with Solaris's t> support of USB than ZFS, but the fact remains it's a pretty t> glaring deficiency in 2009, no matter which part of the stack t> is at fault.
maybe, but for this job I don't much mind glaring deficiencies, as long as it's possible to assemble a working system without resorting to trial-and-error, and possible to know it's working before loading data on it. Right now, by following the ``best practices'', you don't know what to buy, and after you receive the hardware you don't know if it works until you lose a pool, at which time someone will tell you ``i guess it wasn't ever working.'' Even if you order sun4v or an expensive FC disk shelf, you still don't know if it works. (though, I'm starting to suspect, ni the case of FC or iSCSI the answer is always ``it does not work'') The only thing you know for sure is, if you lose a pool, someone will blame it on hardware bugs surroudning cache flushes, or else try to conflate the issue with a bunch of inapplicable garbage about checksums and wire corruption. This is unworkable. I'm not saying glaring 2009 deficiencies are irrelevant---on my laptop I do mind because I got out of a multi-year abusive relationship with NetBSD/hpcmips, and now want all parts of my laptop to have drivers. And I guess it applies to that neat timeslider / home-base--USB-disk case we were talking about a month ago. but for what I'm doing I will actually accept the advice ``do not ever put ZFS on USB because ZFS is a canary in the mine of USB bugs''---it's just, that advice is not really good enough to settle the whole issue.
pgpFtPv2xfqGk.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss