On Tue, 2009-01-20 at 16:52 -0700, andrey mirtchovski wrote:
> for my personal $0.02 i will say that this argument seems to revolve
> around trying to bend fossil and venti to match the functionality of
> zfs and the design decisions of the team that wrote it.
That is NOT the conversation I'm interested in. My main objective is
to evaluate venti/fossil approach to storage and what kind of benefits
it might provide. It is inevitable that I will contrast venti/fossil
with ZFS, simply because it is the background I'm coming from.
> i, frankly, think that it should be the other way around; zfs should
> provide the equivalent of the fossil/venti snapshot/dump functionality
> to its users. that, to me would be a benefit.
Ok. It is fair to turn the tables. So now, let me ask you: what are
the benefits of fossil/venti that you want to see in ZFS? So far
the only real issue that you've identified is this:
||| where the second choice becomes a nuisance for me is in the
||| case where one has thousands of clones and needs to keep track
||| of thousands of names in order to ensure that when the right one
||| has finished the right clone disappears.
And I think it is a valid one. But is there anything else (execpt
the issues that have to do with the fact tha ZFS lives in UNIX
where fossil/venti in Plan9)?
As for me, here's my wish list so far. It is all about fossil, since
it looks like venti is quite fine (at least for my purposes) the
way it is:
1. Block consistency. Yes I know the argument here is that you
can always roll-back to the last known archival snapshot on venti.
But the point is to kown *when* to roll back. And unless fossil
warns you that a block has been corrupted you wouldn't know.
2. live "mounting" of arbitrary scores corresponding to vac
VtRoot's to arbitrary sub-directories in my fossil tree. After
all, if I can do "create" of regular files and sub-directories
via fossil's console why can't I create pointers to the existing
venti file-hierarchies?
3. Not sure whether this is a fossil requirement or not, but I
feel uneasy that a root score is sort of unrecoverable from the
pure venti archive. Its either that I know it or I don't.
> all this filesystem/snapshot/clone games are just a bunch of toys to
> make the admins happy and have little effective use for the end user.
I disagree. Remember that this whole conversation started from
a simple premise that a good archival system could be an
efficient replacement for the SCM. If your end users are
software developers -- that IS very relevant to them.
It is actually quite remarkable how similar the models of
fossil/venti and Git seem to be: both build on the notion
of the immutable history. Both address the history by the
hash index. Both have a mutable area whose only purpose
is to stage data for the subsequent commit to the permanent
history. Etc.
> > I see what you mean, but in case of venti -- nothing disappears, really.
> > From that perspective you can sort of make those zfs clones linger.
> > The storage consumption won't be any different, right?
>
> the storage consumption should be the same, i presume. my problem is
> that in the case of zfs having several hundred snapshots significantly
> degrades the performance of the management tools to the extend that
> zfs list takes 30 seconds with about a thousand entries.
Really?!?
> compared to
> fossil handling 5 years worth of daily dumps in less than a second.
> but that's not really a serious argument ;)
And what's the output of
term% ls -d <path-to-your-fossil>/archive/*/*/* | wc -l
> > Great! I tired to do as much homework as possible (hence the delay) but
> > I still have some questions left:
> > 0. A dumb one: what's the proper way of cleanly shutting down fossil
> > and venti?
>
> see fshalt.
Hm. There doesn't seem to be much of shutdown code for fossil/venti
in there. Does it mean that sync'ing venti and then just slay(1)'ing
it is ok?
Thanks,
Roman.
