Re: [9fans] fossil pb: FOUND!

["Aram Hăvărneanu" <aram.h@mgk.ro>]

> you've confused the internal implementation
> with the public programming interface.

The properties we're discussing here (dedup, fragmentation,
performance) are an artifact of the implementation, not of the
interface. Fossil+Venti would perform the same if Venti exported its
interface only to Fossil, and not to the whole world.

In ZFS terms, Fossil is akin to ZPL (ZFS POSIX layer), it implements
filesystem semantics over another layer, DMU for ZFS and Venti for
Plan9.

Please not that ZFS exports more than the filesystem interface,
there's also iSCSI (as you noticed), zfs send/recv (remarcably similar
to venti/write venti/read, even in their use of standard input/output
interface), even bits of the DMU are exported. Hell, even the VFS
concrete implementation is exported (though only in kernel mode), else
you could not write layered filesystems (not as nice and simple as
Plan9 bind(2) but akin to STREAMS filters at filesystem layer). You
know I've worked at writing the SMB/CIFS in-kernel filesystem that
sits on top of ZFS, right? Well, when you're doing this you have to be
careful around this content-addressed thing. I've used the interface
you claim it doesn't exist. It's not public? Why is this relevant to
the properties of the system?

> on the other hand, zfs is not content addressed.  this is because, as
> an iscsi target, zfs will be addressing data by block offset rather
> than hash.  zfs could store its bits in venti, and it still would NOT be
> content addressed nor would it be venti-addressed.

That's not fair at all, I could be claiming that venti is not content
addressed because you use hierarchical names to address data in a vac
archive. Vac is just a layer over venti, like ZPL and iSCSI is a layer
over DMU.

In this case the properties of the system depend on the properties of
the underlying layer, not of the interface, and this layer is content
addressed, even by your definition.

-- 
Aram Hăvărneanu