Yes, I think that was the original intent of the project proposal. It
could probably be reworded to decrease emphasis on a single algorithm,
but I read it as a generic exploration of alternative algorithms.
Pluggable algorithms is tricky, because compression is encoded as a
single 8-bit quantity in the block pointer. This doesn't make it
impossible, just difficult. One could imagine, for example, reserving
the top bit to indicate that the remainder of the value is an index into
some auxiliary table that can identify compression schemes in some
extended manner. This avoids the centralized repository, but introduces
a number of interesting failure modes, such as being unable to open a
pool because it uses an unsupported compression scheme. All very
doable, but it's a lot of work for (IMO) little gain, not to mention
increased difficulty maintaining compatibility across disparate
versions (what is the set of compression algorithms needed to be 100%
On Sun, Oct 14, 2007 at 03:28:24AM -0700, me@xxxxxxxxxxx wrote:
> > I haven't heard from any other core contributors, but this sounds like a
> > worthy project to me. Someone from the ZFS team should follow through
> > to create the project on os.org
> > Its sounds like like Domingos and Roland might constitute the initial
> > "project team".
> In my opinion, the project should also include an effort in getting LZO
> into ZFS. As an advanced fast but efficient variant.
> For that matter, if it were up to me, there should be an effort in
> modularizing the ZFS compression algorithms into loadable kernel modules,
> also allowing easy addition of algorithms. I suppose the same should apply
> to other components where possible, e.g. the spacemap allocator discussed
> on this list. But I'm a mere C# coder, so I can't really help with that.
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
zfs-discuss mailing list