Reiser4 does a disk write with even no disk activity during every fsync()
Hi!
I see a previous topic talking about sync(), I wrote a program write()
a 44B file, and then fsync()
I used #iostat -d 1 -p hda|grep hda3 monitored many times and found:
for a single fsync(), these sectors were wrote:
ext2 16
ext3j/o/w 32
jfs16
xfs 10
reiser3 48
reiser4 128
for multiple fsync(), I use while (1) {sleep(1); fsync()}
ext2 16/0/0/0/0/0.
ext3j/o/w 32/0/0/0/0/0.
jfs16/0/0/0/0/0.
xfs 10/0/0/0/0/0.
reiser3 48/0/0/0/0/0.
reiser4 128/48/48/48/48/48.
so you see while there is no other disk activities in /dev/hda3,
reiser4 continues writing something..?
Re: reiser4: reserved disk space
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
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
