so it should be made clear that fossil is not appropriate for large files or file system traffic. if i wish to create a 5G file and fossil is 10G can i? well it depends on what has happened since the last snap.
brucee On 12/7/05, Russ Cox <[EMAIL PROTECTED]> wrote: > > of course. or don't call it a cache but "something that may > > fill up and screw you over". the machine was far too hosed > > to connect to fscons and in any case telling a user "if you > > do too much stuff you will have to call me to fix fossil" is > > not aacceptable. > > I'm not claiming, under any circumstances, that fossil > becoming unusable is acceptable. However, the solution > is not as simple as "just write the blocks to venti". > First, writing blocks to venti requires some knowledge > of the rest of the file server state, and you can't always > write any block to venti. Second, some people don't even > use venti and they can fill their fossils too. > > There are plenty of subtle things going on in fossil that make > it much harder to handle the disk being full than in a conventional > file system. > > 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. > > If someone wants to work on making this happen, I would be > happy to provide further details. > > Russ >
