However, we should look at how FreeBSD has implemented posix_fallocate
and see if we can incorporate that code. Or at least come up with a
compatable implementation so that there is a possibility of moving disks
between these systems.
>> You don't have to know where to write. Strictly speaking you only
>> need to know that the space is reserved.
Right.
> One thing that I am missing here is: if you would keep info about reservatio$
You don't need to know history. You just need to know how many blocks
are available to be newly allocated each of two ways.
In your example, you have 1200 blocks available and you posix_fallocate
1000 of them. Then you have 1200 blocks marked free with a free-block
count of only 200; how it got to that state is not relevant. (Whether
you need to have the number 1200 stored somewhere also - or instead -
is a question I would have to dig into FFS internals at some length to
answer, and indeed the answer would likely depend on the details of how
all this got implemented.)
Obviously, anything that deals with free blocks needs to be updated,
and you need two forms of allocate-a-block, one for replacing
"allocated hole" blocks with real content and one for allocating new
blocks.
> If you request block-allocator from fallocate to reserve these block, to mak$
No; there's no need to allocate specific blocks. All you need to do is
ensure that, when it comes time to put real data at that spot in the
file, a block will be available. Which block it is is not important.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B