An Update On Reiser4 For The Mainline Linux Kernel

[phoronix]

Phoronix: An Update On Reiser4 For The Mainline Linux Kernel

In November of 2009 we reported that the Reiser4 file-system may go into the mainline Linux kernel in late 2010. We're now into 2011 with the merge window having closed earlier this month for the Linux 2.6.38 kernel and there's no sign of this open-source file-system designed to succeed the popular ReiserFS. So what gives? Well, we have another update from its lead developer...

http://www.phoronix.com/vr.php?view=OTA2Mw

[kernelOfTruth]

folks shouldn't be so short-sighted and only focus on performance

do some data-integrity tests with reiser4 against ext4 and btrfs

especially cases like power outage, usage with device-mapper and cryptsetup

soon you'll see that there is corruption going on with btrfs (still regularly at the moment for me, during hardlocks the superblock get unrecoverable corrupted; data loss, etc.), ext4 (there might be but there were lots of fixes in the last merge window - in the past I regularly got corruptions or data loss during usage of suspend-to-disk and tuxonice), reiser4 (I had some due to upstream doing some serious changes in the kernel, currently no that I know of)

[89c51]

why would it need a vendor behind it if it is in fact ready

even if there is no official vendor behind it the community -and there are people that use it- might help

has he tried sending the patches to lkml or something???

[Abn0rmal]

The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?

[kernelOfTruth]

The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?

because it DOES NOT KILL your data RIGHT NOW ?

and it's simply superior due to its concept behind it ?

[FireBurn]

The most interesting part of the Reiser 4 FS was the idea of metadata handling via accessing files as if they were directories. Since that's never going to happen why use reiser4 instead of btrfs?

Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now

[MùPùF]

because it DOES NOT KILL your data RIGHT NOW ?

and it's simply superior due to its concept behind it ?

I've been using btrfs for about two months and so far, no data loss.

I can assure you I've tested the power outage problem, it works great for me so far

Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now

So does Btrfs in the 2.6.38 if I understood "make menuconfig" right.

[kernelOfTruth]

Reiser4 had huristics for determining which files should be compressed when using the compress option, it also allowed you to choose which compression you'd like to use zlib, lzo and another that I can't remember just now

during filesystem creation:
*) unix40 (regular filesystem mode)
*) ccreg40 (cryptcompress mode; compression with checksumming; encryption can be added)

**) compression algorithm: gzip and lzo
**) compression mode: conv, latt, force, ultim

*) choosing of cluster-size

*) fibration-mode: sorting of files by their ending (ext_1_fibre, ext_3_fibre)

*) extent-mode (for large files)
*) tails-mode (for lots of small files)
*) smart-mode heuristically determining whether to use extents or tails

*) there might be more that I forgot ...

during mount:

*) optional additional transaction lookaside buffer (tree.ckb_cache.nr_slots)
*) flush relocation threshold/distance
*) number of maximal flushers
*) number of maximal scanned nodes during flush
*) set up of optimal io-size
*) optional 32bit timestamps
*) BSD-style gid assignment
*) disabled pseudo files
*) single flushing (no concurrent flushing)
*) disabled loading of bitmap during mount (faster mounting of large volumes)

other characteristics:
*) dancing (balanced, ...) B-trees
*) atomic writes
*) light-weight load on harddrive mechanics
*) ...

[kernelOfTruth]

I've been using btrfs for about two months and so far, no data loss.

I can assure you I've tested the power outage problem, it works great for me so far

haha, nice

I had still serious problems and data corruption with 2.6.37

So does Btrfs in the 2.6.38 if I understood "make menuconfig" right.

they moved it ? - so that isn't set anymore during mount

[kernelOfTruth]

during filesystem creation:
*) unix40 (regular filesystem mode)
*) ccreg40 (cryptcompress mode; compression with checksumming; encryption can be added)

**) compression algorithm: gzip and lzo
**) compression mode: conv, latt, force, ultim

*) choosing of cluster-size

*) fibration-mode: sorting of files by their ending (ext_1_fibre, ext_3_fibre)

*) extent-mode (for large files)
*) tails-mode (for lots of small files)
*) smart-mode heuristically determining whether to use extents or tails

*) there might be more that I forgot ...

during mount:

*) optional additional transaction lookaside buffer (tree.ckb_cache.nr_slots)
*) flush relocation threshold/distance
*) number of maximal flushers
*) number of maximal scanned nodes during flush
*) set up of optimal io-size
*) optional 32bit timestamps
*) BSD-style gid assignment
*) disabled pseudo files
*) single flushing (no concurrent flushing)
*) disabled loading of bitmap during mount (faster mounting of large volumes)

other characteristics:
*) dancing (balanced, ...) B-trees
*) atomic writes
*) light-weight load on harddrive mechanics
*) ...

to make their clear: you have concurrent flushing by default but you can disable it for usb- and other slow devices