[pacman-dev] Diskspace checking thought- free space cushion

Dan McGee dpmcgee at gmail.com
Tue Dec 14 20:54:58 EST 2010

On Tue, Dec 14, 2010 at 7:51 PM, Allan McRae <allan at archlinux.org> wrote:
> On 15/12/10 10:01, Dan McGee wrote:
>> Code in question is diskspace.c, line ~300:
>>   for(i = mount_points; i; i = alpm_list_next(i)) {
>>     alpm_mountpoint_t *data = i->data;
>>     if(data->used == 1) {
>>       _alpm_log(PM_LOG_DEBUG, "partition %s, needed %ld, free %ld\n",
>>           data->mount_dir, data->max_blocks_needed,
>>           (unsigned long)data->fsp.f_bfree);
>>       if(data->max_blocks_needed>  data->fsp.f_bfree) {
>>         abort = 1;
>>       }
>>     }
>>   }
>> This does a strict check of max_blocks_needed>  fsp.f_bfree. do we
>> want to cushion this somehow, as having 1 block free could still spell
>> disaster given logging, post-install scripts, etc.? And if so, how
>> much? I don't want to make this something that has loads and loads of
>> configuration- we hardcode max delta ratio at 0.7, for instance. Is 5%
>> of total blocks, capped at something like 10 MB (in 4K blocks that
>> would be 2560 blocks) enough?
> I thought about that, especially given there is some handwaving about blocks
> taken for directories, database entries etc.  I did not using a percentage
> or a fixed size, but the combination might be good. max(5%,10M) sounds fine
> although maybe a bit more than 10MB would be good.

max, or min? 5% will be huge on big drives. I meant min without
actually saying it.

> Another possibility I thought of was using f_bavail instead of f_bfree.
>  That is the space available to unprivlidged users which is generally
> buffered.   I think I like that idea the least though...
Agreed, not a huge fan either.


More information about the pacman-dev mailing list