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