On Sat, 6 Jun 2009, Richard Elling wrote:
> The presumption is that you are using UFS for the CF, not ZFS.
> UFS is not COW, so there is a potential endurance problem for
> blocks which are known to be rewritten many times. ZFS will not
> have this problem, so if you use ZFS root, you are better served by
> ignoring the previous "advice."
My understanding was that all modern CF cards incorporate wear leveling,
and I was interpreting the recommendation as trying to prevent wearing out
the entire card, not necessarily particular blocks.
> of writes to the swap device. For OpenSolaris (enterprise support
> contracts now available!) which uses ZFS for swap, don't worry, be
As of U6, even luddite S10 users can avail of zfs for boot/swap/dump:
r...@ike ~ # uname -a
SunOS ike 5.10 Generic_138889-08 i86pc i386 i86pc
r...@ike ~ # swap -l
swapfile dev swaplo blocks free
/dev/zvol/dsk/ospool/swap 181,2 8 8388600 8388600
> In short, if you use ZFS for root, ignore the warnings.
How about the lack of redundancy? Is the failure rate for CF so low there's
no risk in running a critical server without a mirrored root pool? And what
about bit rot? Without redundancy zfs can only detect but not correct read
errors (unless, I suppose, configured with copies>1). How much more would
it have cost to include two CF slots that it wasn't warranted?
> 5 GBytes seems pretty large for a slog, but yes, I think this is a good
> idea.
What is the best formula to calculate slog size? I found a recent thread:
http://jp.opensolaris.org/jive/thread.jspa?threadID=78758&tstart=1
in which a Sun engineer (presumably unofficially of course ;) ) mentioned
10-18GB as more than sufficent. On the other hand:
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29
says "A rule of thumb is that you should size the separate log to be able
to handle 10 seconds of your expected synchronous write workload. It would
be rare to need more than 100 MBytes in a separate log device, but the
separate log must be at least 64 MBytes."
Big gap between 100MB and 10-18GB. The first thread also mentioned in
passing that splitting up an SSD between slog and root pool might have
undesirable performance issues, although I don't think that was discussed
to resolution.
> CFs designed for the professional photography market have better
> specifications than CFs designed for the consumer market.
CF is pretty cheap, you can pick up 16GB-32GB from $80-$200 depending on
brand/quality. Assuming they do incorporate wear leveling, and considering
even a fairly busy server isn't going to use up *that* much space (I have a
couple E3000's still running which have 4GB disk mirrors for the OS), if
you get a decent CF card I suppose it would quite possibly outlast the
server.
But I think I'd still rather have two 8-/. Show of hands, anybody with an
x4540 that's booting off non-redundant CF?
> This is not an accurate statement. Enterprise-class SSDs (eg. STEC Zeus)
> have DRAM write buffers. The Flash Mini-DIMMs Sun uses also have DRAM
> write buffers. These offer very low write latency for slogs.
Yah, that misconception has already been pointed out to me offlist. I
actually came upon it in correspondence with you, I had asked about using a
slice of an SSD for a slog rather than the whole disk, and you mentioned
that the advice for using the whole disk rather than a slice was only for
traditional spinning hard drives and didn't apply to SSD's, I thought
because of something to do with the write cache but I guess I
misunderstood. I didn't save that message, perhaps you could be kind
enough to refresh my memory as to why slices of SSD's are ok while slices
of hard disks are best avoided?
--
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
