DragonFly kernel List (threaded) for 2008-02
Re: HAMMER update 06-Feb-2008
:Just curious: what was the write performance issue? I mean, what was the use
:case and how bad was the performance? I don't think it was described in any
:detail in your past HAMMER update mails, but please point me to the mail if
There were two issues. First there were numerous buffer dependancies
that required a synchronous write to 'open' the cluster before the rest
of the buffers could be flushed. It got messy really fast.
The second issue was that I found it really hard to predict the key range
for a new cluster to get a reasonable fill ratio before HAMMER would have
to allocate another cluster.
:> Everything else now works, and works well, including and most especially
:> the historical access features. I've already fallen in love with being
:> able to create a softlink to a '@@0x<timestamp>' string to access
:As long as I'm asking HAMMER-related questions... This may be obvious from the
:code but I haven't looked at it yet. Will it be possible to disable the
:historical access feature and still have the possibility to take a snapshot
:(of the filesystem or a directory tree) at some point in time?
Hmm. I think the answer is no, historical access must be turned on
(especially now with the FIFO mechanic). There's no random bitmap free
any more so 'nohistory' won't work anyway in the initial release.
In otherwords, if your disk fills up the only way to clear space is to
cycle the fifo. That will ultimately be improved by a future backing
store behind the fifo (the blockmap idea I talked about before), and/or
out of band data references, allowing some immediate gratification for
e.g. large files.
Personally speaking I think the blockmap idea may be the best way to go.
It would be theoretically possible to immediately reuse a block that
becomes completely free by unmapping it from the fifo (creating a 'hole'
in the fifo) and freeing it for reuse. One would thus not have to cycle
the fifo to reach the block in order to reuse it.