[pacman-dev] Diskspace checking thought- free space cushion
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? -Dan
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. 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... Allan
On Tue, Dec 14, 2010 at 7:51 PM, Allan McRae <allan@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.
-Dan
On 15/12/10 11:54, Dan McGee wrote:
On Tue, Dec 14, 2010 at 7:51 PM, Allan McRae<allan@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.
Yes... I meant min while saying max. Allan
It is the minimum of 5% of disk capacity or 20 MiB on a per-partition basis. Signed-off-by: Dan McGee <dan@archlinux.org> --- lib/libalpm/diskspace.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/libalpm/diskspace.c b/lib/libalpm/diskspace.c index 5ed8e0b..bf5d389 100644 --- a/lib/libalpm/diskspace.c +++ b/lib/libalpm/diskspace.c @@ -294,10 +294,15 @@ int _alpm_check_diskspace(pmtrans_t *trans, pmdb_t *db_local) 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, + /* cushion is min(5% capacity, 20MiB) */ + long fivepc = data->fsp.f_blocks / 20; + long twentymb = 20 * 1024 * 1024 / data->fsp.f_bsize; + long cushion = fivepc < twentymb ? fivepc : twentymb; + + _alpm_log(PM_LOG_DEBUG, "partition %s, needed %ld, cushion %ld, free %ld\n", + data->mount_dir, data->max_blocks_needed, cushion, (unsigned long)data->fsp.f_bfree); - if(data->max_blocks_needed > data->fsp.f_bfree) { + if(data->max_blocks_needed + cushion > data->fsp.f_bfree) { abort = 1; } } -- 1.7.3.3
participants (3)
-
Allan McRae
-
Dan McGee
-
Dan McGee