Re: [MooseFS-Users] Real experiences from real users

[Marin B. <li...@ol...>]

> Il giorno mar 22 mag 2018 alle ore 14:39 Marco Milano <marco.milano@g
> mx.com>
> ha scritto:
> > What is wrong with saying that if you want compression use ZFS and
> > turn
> 
> on compression?
> > ZFS is available on both Linux and FreeBSD.
> > Why does compression need to be on the MooseFS level ?
> 
> ZFS on Linux is not "native", it's an external project. It require a
> DKMS
> or Ubuntu, that provide an already built module as default.

So does Proxmox VE.

Nothing is "native" on Linux. Any distro is a sum of external projects.
Btrfs used to be such an external project. The only reason why ZFS is
not included in most distros is because it is released under the CDDL
license, which is not compatible with the GPL.

> If you only need compression, forcing users to use ZFS is like
> shooting
> fish in barrel.
> ZFS requires tons of (ECC) RAM that could be used for something else 

That's a myth. ZFS never required ECC RAM, and I run it on boxes with
as little as 1GB RAM. Every bit of it can be tuned, including the size
of the ARC.

> (ie,
> putting mfsmaster on chunkservers),
> and, on average, is slower than other FS due to checksumming (already
> done
> by MooseFS, thus it's a
> redundant check)
> 

Checksumming and duplication (ditto blocks) of pool metadata are NOT
provided by the master. This is a much appreciated feature when you
come from an XFS background where a single urecoverable read can crash
an entire filesystem. I've been there before; never ever!

MooseFS background verification may take months to check the whole
dataset. ZFS does scrub a whole chunkserver within a few hours, with
adaptive, tunable throughput to minimize the impact on the cluster.

Speed is a very complex topic. ZFS is actually faster than most non-COW 
file systems in sequential I/O, but less efficient in other scenarios.
The same story goes on with btrfs. This has nothing to do with
checksumming, especially with recent AES-NI-capable chips with hardware
checksum offloading.

Low latency is what the ARC was designed for, and where is shines. It
can also be tuned to prioritize speed if this is wished. A chunkserver
with enough RAM is able to serve recently requested chunks at the speed
of light. And as a bonus, the ARC tries to make the best use of memory
by caching compressed data.

> I'm not against ZFS (probably i'll use ZFS in my cluster), but if the
> only
> used feature is compression, having it in MooseFS is not a bad idea.
> 

There are a lot of benefits in using ZFS. People wrote entire books
about it. Of course, it may not always be the best answer: there are
always those few edge cases where it's not worth it, but there's not a
lot of them.

Personally, I no longer wonder why I should use it; I rather try to
find reasons to go without it. If there are none, why not use it ?

> In this case, MooseFS will be really hardware and software
> indipendent.
> 
> Obviously, i'm talking after reading that adding compression "is
> quite
> simple to implement".
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _________________________________________
> moosefs-users mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moosefs-users