On 06/15/10 10:52, Erik Trimble wrote:
Frankly, dedup isn't practical for anything but enterprise-class
machines. It's certainly not practical for desktops or anything remotely
low-end.
We're certainly learning a lot about how zfs dedup behaves in practice.
I've enabled dedup on two desktops and a home server and so far
haven't regretted it on those three systems.
However, they each have more than typical amounts of memory (4G and up)
a data pool in two or more large-capacity SATA drives, plus an X25-M ssd
sliced into a root pool as well as l2arc and slog slices for the data
pool (see below: [1])
I tried enabling dedup on a smaller system (with only 1G memory and a
single very slow disk), observed serious performance problems, and
turned it off pretty quickly.
I think, with current bits, it's not a simple matter of "ok for
enterprise, not ok for desktops". with an ssd for either main storage
or l2arc, and/or enough memory, and/or a not very demanding workload, it
seems to be ok.
For one such system, I'm seeing:
# zpool list z
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
z 464G 258G 206G 55% 1.25x ONLINE -
# zdb -D z
DDT-sha256-zap-duplicate: 432759 entries, size 304 on disk, 156 in core
DDT-sha256-zap-unique: 1094244 entries, size 298 on disk, 151 in core
dedup = 1.25, compress = 1.44, copies = 1.00, dedup * compress / copies
= 1.80
- Bill
[1] To forestall responses of the form: "you're nuts for putting a slog
on an x25-m", which is off-topic for this thread and being discussed
elsewhere":
Yes, I'm aware of the write cache issues on power fail on the x25-m.
For my purposes, it's a better robustness/performance tradeoff than
either zil-on-spinning-rust or zil disabled, because:
a) for many potential failure cases on whitebox hardware running
bleeding edge opensolaris bits, the x25-m will not lose power and thus
the write cache will stay intact across a crash.
b) even if it loses power and loses some writes-in-flight, it's not
likely to lose *everything* since the last txg sync.
It's good enough for my personal use. Your mileage will vary. As
always, system design involves tradeoffs.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
