> > Deduplication is a fairly niche feature, IMO, but just about everything > else I use on all of my deployments every time; unlimited snapshots without > a performance hit, compression, zfs send/receive. ZFS is one of those > things that once you've used it, after 5 minutes you simply struggle how > you ever managed to make do without it. It's one of those "I was blind; now > I can see." moments.
Agreed. I don't use the dedup just anywhere, due to its high performance/resource requirements, but combined with BackupPC, I found an awesome combination (BackupPC does file-based dedup, and when combined with ZFS-based compression and block-level dedup, it does particularly well deduping snapshots of VM images. End result is it takes multiple TBs of backups, and puts them on a sub-TB partition--wicked cool). So that said, I'm highly in favor of the OPTION of ZFS on RedSleeve. As >> you've mentioned, there are some cons to it, especially to embedded >> devices with limited resources. I think these types of devices should >> have the ability to stay on ext. >> > > Perhaps this is a matter of opinion but for non-zfs cases I am struggling > to figure out why an .img is advantageous over a generic .tar.gz in the > first place. We aren't really aiming this distribution at people who don't > already know how to mkfs.ext4 and extract the tarball onto it. > I'm not sure I understand what this has to do with my text you quoted. But as for your question, I use the .img file when flashing my SD cards in Windows using win32diskimager. At least in the Windows world, that's how I've had the best success in getting these SD cards created. If reliability is a concern, I'm surprised you don't consider ext* a > liability, especially on ARM, considering that things like parts of > e2fsprogs (like fsck) do things that are unbelievably dangerous on > architectures without transparent automatic alignment fixup. What happens > all over that codebase is that they keep allocating a buffer as an array of > char[4096] (char being byte aligned), then cast it into a struct (which > will be at least word aligned, possibly to an bigger boundary depending on > what the first element is). > My statement about stability/reliability was more about the code itself; so in other words, choosing the more mature, stable code set of EL, vs something a bit more bleeding edge/untested, like Fedora. But you make a fair point about ext in that regard. I wasn't actually aware of automatic alignment fixup. > The net result is that unless you have set your kernel to automatically > fix up alignment problems (and take the ~20x speed penalty for it), there > is a decent chance that fsck-ing your ext* file system on an ARM machine > will irreversibly trash the fs. The only reason there isn't a massive > outcry about this is because most distros ship with kernels configured to > automatically do alignment fixup. The performance hit from it is generally > being ignored. > > So I'd dispute the implication that ext* is somehow safer than anything > else out there. Wasn't implying that ext* was safer than anything else out there, just that in my experience, it's been pretty stable, and has bounced back pretty well from anything I've thrown at it. But then again, most of that experience is on x86-based systems, where you say automatic alignment fixup is enabled. > In fairness, the only two cases in which I find that I am running out of > CPU with zfs-fuse is when doing a scrub or zfs send/receive. Neither of > these are even possible with a different file system, so it is debatable > whether you actually have a real use-case where you are even bottlenecked > by the FS a significant fraction of the time. > > And all that ignores the safety aspects of zfs' checksumming. > > Also, most embedded devices run off SD cards and on those compression and > the fact that ZFS tries to combine writes into large (128KB) blocks is > likely to actually get you ahead overall. My primary concern for performance is that I intend to do a level of processing & calculations that will likely stretch the boundaries of embedded devices somewhat, so my goal is to keep the system/OS from contributing to the load any more than it has to, so that more CPU is available for those calculations. Maybe I'm overstating the performance hit ZFS will actually have on an embedded system, but it seemed like something that should be brought up. Nobody is talking about statically linking CDDL code with GPL code (which > would break the licensing). > > This is so much of a non-issue that even the Debian licensing zealots have > decided to ship with zfs and support it as the rootfs. The way they are > working around it is to ship the installer with zfs-fuse, get that to do > the initial setup, and then build the kernel based ZoL implementation at > first boot using dkms, rebuild the initramfs, and switch for the 2nd boot. > Interesting. I hadn't heard of that. If that's the case, then I withdraw that point. -- --Mark
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
