[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1080956: SaunaFS versus LizardFS versus MooseFS



Dear all,

Let me add some context with few insights regarding packaging of SaunaFS.

Years ago I introduced LizardFS into Debian, maintained it throughout
entirety of its life span (while being actively involved upstream),
then requested its removal (in favour of MooseFS).

LizardFS began as a fork of MooseFS with few added features (erasure coding,
master fail-over). LizardFS attracted a small community of users while its
developers undertaken aggressive code re-factoring (and conversion to C++)
which eventually got out of control, leading to grave/catastrophic bug
that caused massive loss of data (which burned me badly).

Shortly after that, development of LizardFS stagnated, then stopped, with
team of developers seemingly being dissolved, doing no public work for
number of years. LizardFS community ceased to exist, with most of its
former users moving to MooseFS or other technologies.

In the beginning, LizardFS had feature parity with Moosefs. But active
development of MooseFS continued in the meantime, with regular releases
as well as major release that added erasure coding and extraordinary
Storage Classes feature for tiered storage and precise control for data 
placement.

Feature-wise, MooseFS is certainly much ahead of a relatively new LizardFS 
fork. While SaunaFS is yet to prove itself, I personally vouch for
reliability of MooseFS that I recommend wholeheartedly.

MooseFS have been developed with competence. It is a trustworthy technology
with active community and good online support. MooseFS appears to be better
through and through.

Considering state of affairs with LizardFS, I find it hard to justify SaunaFS
for inclusion to Debian, especially given the fact that packaging of superior
MooseFS (introduced and maintained by yours truly) is already available.

IMHO it would make more sense to assist with maintenance of MooseFS as well
as to collaborate with its upstream developers rather than trying to revive
obsolete technology with no community behind it.

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

That which has always been accepted by everyone, everywhere, is almost
certain to be false.
 -- Paul Valery

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: