From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <888dedc8db38b37430a0c1c44cc9c981@chula.quanstro.net> References: <20120113113026.GA419@polynum.com> <20120114003032.1C08F1CC8F@mail.bitblocks.com> <201201140201.51504.dexen.devries@gmail.com> <2ca6969da468ef7d305866d2c3c484f4@chula.quanstro.net> <888dedc8db38b37430a0c1c44cc9c981@chula.quanstro.net> From: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= Date: Sun, 15 Jan 2012 15:07:47 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] fossil pb: FOUND! Topicbox-Message-UUID: 5c8f735c-ead7-11e9-9d60-3106f5b1d025 > 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. =C2=A0this is because, a= s > an iscsi target, zfs will be addressing data by block offset rather > than hash. =C2=A0zfs could store its bits in venti, and it still would NO= T 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. --=20 Aram H=C4=83v=C4=83rneanu