very interesting post.
> this is an example of the design decision difference between
> fossil/venti and zfs: venti commits storage permanently and everything
> becomes a snapshot, while the designers of zfs decided to create a
> two-stage process introducing a read-only intermediary between the
> original data and a read-write access to it independent of other
> clients.
a big difference between the decisions is in data integrety.
it's much easier to break a fs that rewrites than it is a worm-based
fs. even if the actual media are the same. and a broken rewriting
fs is much harder to recover. russ wrote up a bit on recovering one
good venti from an old copy and a damaged current venti. this
same approach, (basically fs | fs') works for any worm fs.
> from a remote node. if i create a zfs cloned volume i need to arrange
> an iscsi method of access from a remote node. both nfs and iscsi have
> a host of nasty settings that need to be correct on both ends in order
> for things to work right. i can never hope to export an nfs share
> outside my DMZ.
>
> i don't see a solution to this problem: the unix world is committed to
> nfs and a bit less so to iscsi. i'm more of a 9p guy myself though, so
> i listed it as a complaint.
oh, my perfect chance to shill aoe! how to configure aoe on plan 9
echo bind /net/ether0>/dev/aoe/ctl
now for the hard part
# (this space intentionally left blank.)
- erik
