For example, reiser4 has three allocators - journal overwriter like ext4, the full cow like wa, and the hybrid mode, which is default and which tries to minimize fragmentation, and this was invented like in 2004? The enormous fragmentation issue, which f2fs and btrfs have (here is an example), which btrfs tries to solve by autodefrag, which causes additional write overhead (critical for nand) and to solve which some research was done only last year for f2fs - it does not exist in reiser4, because the system tries to minimize fragmentation and write cycles by itself.
Originally posted by DusanC
View Post
I also find that Btrfs tries to cheat in read performance by using 16k optimized metadata units (remember, it DUPs them) , which allow it to read data much faster, but at same time cause huge write amplification. For example, f2fs uses only 4k with 2048 file inlining. reiser4 is already using 4k, plus it stores checksums inside metadata to further decrease write amplification - and it has inlining disabled, but its also possible.
The only thing I am missing on reiser4 seems to be some raid1-like data duplication (data dup in btrfs terms), but thats probably what reiser5 is trying to achieve. Too bad this awesome system is denied being used in kernel due to some political agenda. People seem to be reinventing the wheel today, which was done several decades old.
Leave a comment: