From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44db37f075e341c3264601a498c2b4b7@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] fossil woe Date: Wed, 7 Dec 2005 21:03:34 +0000 From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: bdebb5b8-ead0-11e9-9d60-3106f5b1d025 > 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?