reiser4: reserved disk space

reiser4: reserved disk space

[Ignatich]

Reiser4 reserves roughly 5% of partition size for it's internal use. 
This space can be tens of gigabytes for modern hard disks, and unlike 
ext2 reserve cannot be used even by root in any way.

I changed reserved block count in super.c to be 1% instead of 5%, 
formatted a test drive in reiser4 and stress tested it by copying many 
small or few huge files to almost full disk. Everything was working fine.

It there a reason for this reserve to be so big?

Re: reiser4: reserved disk space

[Edward Shishkin]

Hello.
This is a comment from block_alloc.c:

/*
 * SPACE RESERVED FOR UNLINK/TRUNCATE
 *
 * Unlink and truncate require space in transaction (to update stat data, at
 * least). But we don't want rm(1) to fail with "No space on device" error.
 *
 * Solution is to reserve 5% of disk space for truncates and
 * unlinks. Specifically, normal space grabbing requests don't grab 
space from
 * reserved area. Only requests with BA_RESERVED bit in flags are allowed to
 * drain it. Per super block delete mutex is used to allow only one
 * thread at a time to grab from reserved area.
 *
 * Grabbing from reserved area should always be performed with BA_CAN_COMMIT
 * flag.
 *
 */

Ignatich wrote:

> Reiser4 reserves roughly 5% of partition size for it's internal use. 
> This space can be tens of gigabytes for modern hard disks, and unlike 
> ext2 reserve cannot be used even by root in any way.


use compression ( http://dev.namesys.com/GettingStartedCryptcompress )
and you will save more then 5% of partition size

>
> I changed reserved block count in super.c to be 1% instead of 5%, 
> formatted a test drive in reiser4 and stress tested it by copying many 
> small or few huge files to almost full disk. Everything was working fine.


you will encounter problems when using serious workload

>
> It there a reason for this reserve to be so big?
>

this value is empirical: it is impossible to estimate this precisely

Thanks.

Re: reiser4: reserved disk space

[Ignatich]

Hello Edward,

Thank you for explanation. I'm still not convinced though. Cryptcompress 
is indeed awesome, but that doesn't change the fact that reserved block 
calculation can be improved. 5% of modern 500GB drive is 25GB and I 
can't see how that space will ever be used even if I will delete 
thousands of files. There is no point in reserving disk space if it will 
never be used. There are many ways to improve this situation: a upper 
and lower limit for reserved block count can be used, ability to 
manually set reserve can be added to mkfs or perhaps reserve usage 
patterns for various workloads can be analyzed and smarter algorithm can 
be developed.

Can you suggest how to simulate workload that will expose reserve block 
starvation?

Looking forward to your reply,
    Max Yudin