On 2008-02-07 06:18, Matthew Dillon wrote:
quoted text
> :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.

I might be wrong (and have misunderstood your reply) but I think he
asked whether it would be possible to disallow a user to access the
historical data (even if it is present on the disk). As I have not
studied the code I might be wrong, but should it not be quite easy to
create some switch which determines whether a @@0x<timestamp> will be
treated as a normal filename or the name or not?

-- 
Erik Wikström