Re: HAMMER update 06-Feb-2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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 
:it was.

    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
:>     snapshots.
:
: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?
:
:Thanks,
:Aggelos

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>