>> All you need is a second magic block number. Block number zero is >> already reserved for holes. Making, say, block number 1, or -1, or >> some such, reserved to represent "block-of-zeros semantics for which >> all backing data has been accounted as allocated", so that writing >> such a block is guaranteed to have space available? > If youâ??re using a single magic block number for â??allocated, but uninitia$
You allocate a block then (the allocation routine needs to take a flag indicating whether you're allocating to replace a zero-but-reserved block). If none are available, the filesystem is corrupt. The blocks-free overhead figure gets redefined to "free block count minus zero-but-reserved block count". > Indirect blocks don't really complicated things much at all ... they would c$ You could do that. Creating a large hole would cost you the time to allocate and initialize the indirect blocks, but I suppose that's a factor of the block size smaller than the time it would take to allocate and initialize all the data blocks, so it would probably be a win, albeit not as much of a win as not allocating-and-filling any of it. I was imagining that a zero-but-reserved indirect block would be treated as representing not a block full of zeros but a block full of the zero-but-reserved magic value. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
