On 16/05/15 17:10, Mark Campbell wrote:
I am also a huge fan of ZFS. I've been using it at home on my home
server's 10TB partition for a few years now (back when that was a bit
more impressive ;) ), and I even use it on some servers at work (big fan
of the deduplication feature for our backup server--BackupPC + ZFS Dedup
== Awesome).
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.
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.
For devices where a kernel and initramfs with zfs (fuse or otherwise)
can be provided as part of the image, OTOH, a zfs image allows for
skipping a couple of tedious steps (creating the pool, then copying the
rootfs over, making your initramfs with zfs-dracut module, and suchlike).
Having said all that, there are many, many more devices out there than
we could ever hope to support with kernels, and in those cases, if we
are lucky and the kernel that ships with the device just happens to
support fuse and initramfs, it might just be possible. In most cases it
probably won't be. But in those few cases where it would be workable I
am inclined to make it the default.
Plus, there's some other considerations. In my case, I am currently
using the RedSleeve OS as a base for a product I hope one day to
market. I chose RedSleeve because of the stability inherent in the
upstream's derivatives, including CentOS, and last I checked, RSEL is
one of a kind--there's just no other EL-based ARM OSes out there (which
surprises me). So stability is very important for me.
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).
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.
Performance too
(of which every little bit counts on an embedded device).
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.
But another
one that I think people often forget, is that license-wise, ZFS is not
technically compatible with linux.
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.
We are unlikely to be lucky with part 2 being implementable most of the
time, but I see no reason at all to not use zfs-fuse.
There are many who choose to ignore
it (myself included on my home server), but the fact is, if I want to
bring this to a commercial product eventually, I'm going to have to pay
attention to those licenses. Others in my boat will too.
There is a lot of FUD about the licensing in question. GPL is only
taking issue with static linking. zfs-fuse is an entirely standalone set
of binaries, so clearly not an issue.
Perhaps a compromise--what if two images were kept? One that's more
"vanilla", and another with ZFS? My guess is that it's a little extra
work, but that it wouldn't be that much--you would just create the
vanilla as usual, and branch it off to modify it with ZFS.
You'd get that anyway - a generic tar ball so the user can drop it onto
whatever FS they want and their frankenkernel (let's face it, most of us
with devices less mainstream than the likes of the Pi are running a
frankenkernel of some sort) supports. For the lucky few that are able to
stick with the devices for which the usable kernel source is available,
we might at least have an out of the box zfs option.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
