this misses the point. a cache must cope with an "I'm full" condition otherwise it can and will fail. i'd much rather a long delay on a file-op when fossil does a "I'm nearly full" snap than a few days to rescue a smashed system.
brucee On 12/8/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Fossil needs some notion of being close to full, at which point > > its behavior would change. Automatic snapshots would stop, > > as would mtime updates and any other source of automatic > > dirtying of blocks. There should be a few blocks reserved for > > snapshots taken in response to manual console commands. > > Then when fossil fills, you can remove recently written data > > (if some runaway program has filled the disk) or connect to > > the console and delete old snapshots or take an archival > > snapshot. > > this seems fine, but... it still seems somewhat arduous when all > one really wants to do is copy a load of data to venti. > > one idea: > > why not make it possible to directly insert vac archives into > a fossil filesystem? > > e.g. with a new fossilcons command: > > createvac path score uid gid perm > > fossil could remap the (possibly spurious) usernames in the > vac archive, for instance by mapping all user and group ids to > the given uid and gid. > > then a large quantity of new data could be "vac"ed directly > onto venti, and then made available within fossil. > > in combination with the "vac" console command, this could make > other previously hard things straightforward; for example replicating > or moving huge directories from place to place without > copying all the data. > > would this be very hard within the current fossil structure? > >
