On Tue, Dec 14, 2010 at 7:51 PM, Allan McRae <[email protected]> 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. -Dan
