ReiserFS tuning thread, the mother of all "ricer" threads ;)

[lightvhawk0]

which fiber mode is the fastest the lexicgraphic or the dot o one?

[note: ok I'll get off my ass and do some tests brb when complete]

Here are the results
dot_o_fibre is faster than lexic_fibre
I did a simple test cause i'm tired and sleepy

Code: Select all

mkfs.reiser4 -o compressMode=none,fibration=dot_o_fibre,formatting=extents,cluster=8K  /dev/sdd1

time cp -a /mnt/backup /media/pendrive
real	3m21.934s
user	0m0.570s
sys	0m1.053s

cd /media/pendrive

time find .

real	0m0.388s
user	0m0.020s

Then again

Code: Select all

mkfs.reiser4 -o compressMode=none,fibration=lexic_fibre,formatting=extents,cluster=8K  /dev/sdd1

time cp -a /mnt/backup /media/pendrive
real	3m27.727s
user	0m1.883s
sys	0m0.380s

cd /media/pendrive

time find .

real	0m0.390s
user	0m0.023s
sys	0m0.000s

one more time with ext_3_fibre vs ext_1_fibre

Code: Select all

ext3

real    2m8.483s
user    0m0.383s
sys     0m1.063s

find.

real    0m0.363s
user    0m0.020s
sys     0m0.000s

ext 1

cp -a


real    2m1.276s
user    0m0.387s
sys     0m1.123s

find.

real    0m0.388s
user    0m0.020s
sys     0m0.000s

After reviewing my results

Code: Select all

mkfs.reiser4 -o compressMode=none,formatting=extents,cluster=8K

Should be the fastest option.....

Which basically disables compression, and tail packing...

[costel78]

I plan to buy an SSD and I still have some questions:
1. Does reiser4 support out of the box TRIM ?
2. How accurate are the following statements ? What would you add ?
- cfdisk should be invoked with -h 224 -s 56 for partition alignment;
- noop should be used as disk scheduler for ssd disk - "block/sda/queue/scheduler = noop" in /etc/sysfs.conf, of course sda will be the ssd;
- write-caching should be disabled for SSD: hdparm -W0 /dev/sda, or sda_args="-W0" in /etc/conf.d/hdparm, and hdparm service set to start at boot;
- if the only file-systems that support trim are ext4 and btrfs, btrfs ssd mount flag are required/recommended, and discard for ext4. I use noatime,nodiratime anyway.

Any suggestion are appreciated. Thank you!

One more question: would you recommend use of compression ?

[dusanc]

AFAIK TRIM is not dependent on fs support.

Also IMHO I wouldn't use compression on SSDs that already compress data (sandforce controller SF1200), but I would on rest.

[costel78]

It would be nice if TRIM does not depend on filesystem. But then why ext4 have discard mount flag to allow TRIM ?
It will be an Intel 80GB so I'll use compression.

[dusanc]

It would be nice if TRIM does not depend on filesystem. But then why ext4 have discard mount flag to allow TRIM ?
It will be an Intel 80GB so I'll use compression.

I stand corrected
If you want online background TRIMing that is initiated from FS then FS has to support it.
If you want to use tols like wiper.sh http://www.ocztechnologyforum.com/forum ... TRIM-tool) etc. to TRIM AFAIK then FS support is not needed.

Intel 80GB G2 is still best buy in my opinion
I'm currently in the process of getting one.

[costel78]

Thank you for support.
So, I'll use btrfs with compression. I prefer to use reiser4 (I actually use it), but without trim support...

[jordanwb]

On a somewhat related note: where did reiser4 go? I can't find it in vanilla-sources-2.6.34-r5.

[costel78]

On a somewhat related note: where did reiser4 go? I can't find it in vanilla-sources-2.6.34-r5.

Reiser4 wasn't and is not included in the main kernel.
The patch can be found here http://www.kernel.org/pub/linux/kernel/ ... 4-for-2.6/ or, if you prefer 2.6.34, you can find it in mm-sources or zen-kernel-9999 unstable.

[jordanwb]

Reiser4 wasn't and is not included in the main kernel.

I am quite sure it was at one point. I remember using it to store the portage ebuilds on my old thinkpad. I know I used vanilla-sources.

[costel78]

Hmmm....
I think you used vanilla-sources but you patched it with Edward patch.
I'm sure that reiser4 wasn't in kernel mainline.

[jordanwb]

I don't recall patching it. Maybe portage did that in the background?

[costel78]

I don't know what to say about this.
But, on the other side, vanilla mean "as original" and to automatically patch "vanilla" with something unsupported does not seems to be right.

[kernelOfTruth]

I don't recall patching it. Maybe portage did that in the background?

perhaps you used reiser4-sources ?

[jordanwb]

I don't recall patching it. Maybe portage did that in the background?

perhaps you used reiser4-sources ?

Possibly. No matter, I don't intend to use Reiser4 anyways.

[AleXoundOS]

The second reason is efficiency in compression. If you have mid to large size files stored on the partition, Reiser4 will compress in <8K> parts. So if you know you are storing larger files, use 32K or 64K for increased compression.

I tested 4K and 64K cluster size in the case of compression:

Code: Select all

mkfs.reiser4 -L 40_Maxtor -f -o create=ccreg40,compress=gzip1,compressMode=force,formatting=tails,cluster=4K /dev/sdb

this resulted as 0.34 compression ratio on linux sources.

Code: Select all

mkfs.reiser4 -L 40_Maxtor -f -o create=ccreg40,compress=gzip1,compressMode=force,formatting=tails,cluster=64K /dev/sdb

64K cluster gives better compression ratio - 0.31.

Using formating=extents didn't changed results a lot, around 3-4 megabytes bigger with 4K cluster, and it didn't affect 64K at all.

I haven't tested big files but compression of small files with gzip and with 64K cluster was more efficient than with 4K cluster.

[DigitalCorpus]

AleXoundOS

I don't know how much has changed in the structure of R4 since I last did testing. AFAIK though, it's mostly been bug fixes. Over using R4 extensively I saw that I got random corruption and hash collisions using anything other than smart formatting. That option automatically picks between an extent and tail packing. I *highly* suggest letting R4 decide. It is hardly a performance deficit otherwise.

If your goal is to have greatest efficiency when storing files, then 64K clusters is best. Keep in mind that this will increase the latency of the system when accessing individual files as well as the fact that since R4 doesn't properly report file size until fsync is called, it reduces the sorting efficiency as every file that is smaller than 64K is reported as 64K to the kernel. This causes fsync to be called much more frequently and depending on available RAM and vm settings, can cause unnecessary writes to disk causing an overall slowdown in throughput. Choose which works best for you workload though.

There is a decent degree of customizability for the option in R4 allowing it to be tweaked pretty well to get the performance you want.


I know it's been a long while since I've been posting around here. I've suffered from major btrfs corruption on my server and have redone things once again. I was able to save most of TV shows etc. Anyhow, I noted that btrfs with compression is about 10-15% slower than reiser4 with cryptcompress. benchmark testing from phoronix actually netted the same results oddly enough even though I've never liked their benches. They've usually seemed to have methods that don't specifically test one variable. I would like to say that btrfs likes to do a few caching threads in the background and if previous file caches have been pushed out of RAM btrfs has to call up those caching threads before it'll start any real searching on a fs. This proved to be particularly annoying when I had to wait an additional 5 sec on top of the 10-15% slower performance when running a n emerge update for world and system every couple days.

[kernelOfTruth]

ok guys,

I've meanwhile again experimented a little with reiser4 on /usr/portage and one of my backup-disks:

for best results use it with 2.6.35 (especially with the vmscan fixes - this should limit lagging of your system during heavy flushes / writing to a minimum, besides that no synchronous writes are needed anymore with latest device-mapper improvements - even with LUKS volumes ! this should lead to a nice performance-improvement, too [this didn't work for me with later kernels]) -

be aware though that usage of loop-devices currently seems to be broken on 2.6.35 !!

mount -o noatime,nodiratime,tmgr.atom_max_flushers=30,dont_load_bitmap,tree.cbk_cache.nr_slots=256 /dev/foo /reiser4

*) I've observed that the concurrent maximal flushers are strangely limited to 1 - WTF ? - for these extra flushers to take effect you need to umount and freshly mount it (remounting doesn't work); this should speed up writing to the disk - above all flushing during umount or large i/o - significantly

<-- this was one of the major annoyances with reiser4 for me for some time, don't know when the default "0" (unlimited) changed to "1", avoid 0 since that perhaps might not work optimally - so setting a high value manually should be "better"

*) dont_load_bitmap should speed up mounting of large partitions A LOT (performance-wise you should omit it with /usr/portage)

*) raising the cbk-cache should speed up look-ups of leafs that are often accessed

enjoy !

[DigitalCorpus]

I need to look into how the dont_load_bitmap option affects performance these days. It's bee a long while since I've done testing on reiser4. Despite btrfs's developement, I still have a faster / and /usr/portage with reiser4 and dont_load_bitmap

I have noticed that with 2.6.37 there was a major update to the code of reiser4. Deleting files has been faster since somewhere around .35 where. I've been using:

Code: Select all

create=ccreg40,compress=gzip1,compressMode=ultim,cluster=32K,fibration=ext_3_fibre,formatting=smart

for /, and:

Code: Select all

create=ccreg40,compress=gzip1,compressMode=ultim,cluster=8K,fibration=lexic_fibre,formatting=smart

for /usr/portage since a long while back in this thread with no problems. I have moved the filesystems to new disks, but never had errors. ymmv.

I mount both partitions with:

Code: Select all

noatime,nodiratime,dont_load_bitmap,tmgr.atom_max_age=30

Preliminary tests with tree.cbk_cache.nr_slot never yielded measurable performance differences for me, but I'm running on a system with 8 GB of RAM. Due to the major updates in code associated with .37 I will revisit this and try some tests with tmgr.atom_max_flushers while I'm at it. It may be a few weeks before I produce any results for these as I tend to be much busier these days.

[kernelOfTruth]

ok, maybe I'm having the wrong usage-cases (or my kernel simply is too tweaked ) but after a uptime of 22+ hours and a s2ram in between I get the following:

[55834.153141] reiser4[locate(16369)]: parse_node40 (fs/reiser4/plugin/node/node40.c:672)[nikita-494]:
[55834.153144] WARNING: Wrong level found in node: 2 != 1
[55834.509146] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.509148] WARNING: Error for inode 69243 (-2)
[55834.566432] reiser4[locate(16369)]: parse_node40 (fs/reiser4/plugin/node/node40.c:672)[nikita-494]:
[55834.566435] WARNING: Wrong level found in node: 2 != 1
[55834.610639] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.610641] WARNING: Error for inode 113954 (-2)
[55834.610661] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.610663] WARNING: Error for inode 113954 (-2)
[55834.624509] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.624510] WARNING: Error for inode 95091 (-2)
[55834.624517] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.624518] WARNING: Error for inode 95091 (-2)
[55834.627510] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.627511] WARNING: Error for inode 92503 (-2)
[55834.629182] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.629183] WARNING: Error for inode 207958 (-2)
[55834.630618] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.630618] WARNING: Error for inode 149496 (-2)
[55834.630626] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.630626] WARNING: Error for inode 149496 (-2)
[55834.636803] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.636804] WARNING: Error for inode 140224 (-2)
[55834.636811] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.636811] WARNING: Error for inode 140224 (-2)
[55834.640958] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.640959] WARNING: Error for inode 204636 (-2)
[55834.640965] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.640965] WARNING: Error for inode 204636 (-2)
[55834.651243] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.651244] WARNING: Error for inode 120249 (-2)
[55834.651251] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.651252] WARNING: Error for inode 120249 (-2)
[55834.656497] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.656499] WARNING: Error for inode 68437 (-2)
[55834.657714] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.657715] WARNING: Error for inode 204242 (-2)
[55834.657976] reiser4[locate(16369)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55834.657977] WARNING: Error for inode 156545 (-2)
[55861.643803] reiser4[locate(16372)]: parse_node40 (fs/reiser4/plugin/node/node40.c:672)[nikita-494]:
[55861.643804] WARNING: Wrong level found in node: 2 != 1
[55861.705648] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.705648] WARNING: Error for inode 69243 (-2)
[55861.709147] reiser4[locate(16372)]: parse_node40 (fs/reiser4/plugin/node/node40.c:672)[nikita-494]:
[55861.709148] WARNING: Wrong level found in node: 2 != 1
[55861.711808] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.711808] WARNING: Error for inode 113954 (-2)
[55861.711814] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.711815] WARNING: Error for inode 113954 (-2)
[55861.713495] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.713495] WARNING: Error for inode 95091 (-2)
[55861.713501] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.713501] WARNING: Error for inode 95091 (-2)
[55861.715924] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.715925] WARNING: Error for inode 92503 (-2)
[55861.717280] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.717281] WARNING: Error for inode 207958 (-2)
[55861.718525] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.718526] WARNING: Error for inode 149496 (-2)
[55861.718531] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.718532] WARNING: Error for inode 149496 (-2)
[55861.723605] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:
[55861.723606] WARNING: Error for inode 140224 (-2)
[55861.723611] reiser4[locate(16372)]: key_warning (fs/reiser4/plugin/file_plugin_common.c:511)[nikita-717]:

for my portage-partition

and this is not the first time (afaik I also observed this in the past)


strange: after an umount and fsck - the filesystem "is consistent"

Reiser-filesystem are really data safers


so DO NOT PANICK if you get those messages:

1) make sure you have backups

2) fsck.reiser4 should take care of that (in most if not all cases)


edit:

anyone seen the following kind of error ?

[67309.515652] reiser4[emerge(13433)]: dc_check_checksum (fs/reiser4/plugin/file/cryptcompress.c:969)[edward-156]:
[67309.515653] WARNING: Bad disk cluster checksum 1697539431, (should be 1287039274) Fsck?
[67309.515655]
[67309.515658] reiser4[emerge(13433)]: reiser4_inflate_cluster (fs/reiser4/plugin/file/cryptcompress.c:1136)[edward-1460]:
[67309.515660] WARNING: Inode 217320: disk cluster 265 looks corrupted
[67309.515684] reiser4[emerge(13433)]: dc_check_checksum (fs/reiser4/plugin/file/cryptcompress.c:969)[edward-156]:
[67309.515685] WARNING: Bad disk cluster checksum 1697539431, (should be 1287039274) Fsck?
[67309.515686]
[67309.515689] reiser4[emerge(13433)]: reiser4_inflate_cluster (fs/reiser4/plugin/file/cryptcompress.c:1136)[edward-1460]:
[67309.515690] WARNING: Inode 217320: disk cluster 265 looks corrupted
[67309.515721] reiser4[emerge(13433)]: dc_check_checksum (fs/reiser4/plugin/file/cryptcompress.c:969)[edward-156]:
[67309.515723] WARNING: Bad disk cluster checksum 1697539431, (should be 1287039274) Fsck?
[67309.515724]
[67309.515727] reiser4[emerge(13433)]: reiser4_inflate_cluster (fs/reiser4/plugin/file/cryptcompress.c:1136)[edward-1460]:
[67309.515728] WARNING: Inode 217320: disk cluster 265 looks corrupted

emerge -uaDN world
Traceback (most recent call last):
File "/usr/bin/emerge", line 43, in <module>
retval = emerge_main()
File "/usr/lib64/portage/pym/_emerge/main.py", line 1327, in emerge_main
_global_updates(trees, mtimedb["updates"], quiet=("--quiet" in myopts)):
File "/usr/lib64/portage/pym/portage/_global_updates.py", line 50, in _global_updates
bindb.bintree.populate()
File "/usr/lib64/portage/pym/portage/dbapi/bintree.py", line 511, in populate
self._populate(getbinpkgs)
File "/usr/lib64/portage/pym/portage/dbapi/bintree.py", line 617, in _populate
metadata_bytes = portage.xpak.tbz2(full_path).get_data()
File "/usr/lib64/portage/pym/portage/xpak.py", line 480, in get_data
mydata[myname] = a.read(datalen)
IOError: [Errno 5] Input/output error

this kind of look familiar ...

I'm currently running a

Code: Select all

find -inum 13433

let's see who's the bad guy

find -inum 13433
find: `./home/matthias/.gvfs': Permission denied
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-tfmx': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-tonegen': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-voice': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-volnorm': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-vorbis': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-wakeup': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-wav': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-wma': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-wmdiscotux': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-xf86audio': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-xmmsd': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-plugins/xmms-xmmsmplayer': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/clementine': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/cplay': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/cue2tracks': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/dumb-xmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/efxmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/eq-xmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/exaile': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/falf': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/flacon': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/gcue2tracks': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/hydrogen': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/idjc': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/kirateradio': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/kirateradio-xmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/lmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/minitunes': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/modplugxmms': Input/output error
find: `./usr/gentoo/overlays/arcon/.hg/store/data/media-sound/pinkytagger': Input/output error
find: `./usr/gentoo/overlays/desktopevolution/x11-plugins/compiz-fusion-plugins-extra/.svn/text-base/ChangeLog.svn-base': Input/output error
find: `./usr/gentoo/overlays/desktopevolution/x11-plugins/compiz-fusion-plugins-extra/.svn/text-base/Manifest.svn-base': Input/output error
find: `./usr/gentoo/overlays/desktopevolution/x11-plugins/compiz-fusion-plugins-extra/.svn/text-base/metadata.xml.svn-base': Input/output error
find: `./usr/gentoo/overlays/desktopevolution/x11-plugins/compiz-fusion-plugins-extra/.svn/text-base/compiz-fusion-plugins-extra-0.5.2.ebuild.svn-base': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/hamcrest/files/.svn/text-base/hamcrest-1.2-empty_library.patch.svn-base': No such file or directory
find: `./usr/gentoo/overlays/java-experimental/dev-java/hamcrest/files/.svn/text-base/hamcrest-1.2-empty_integration.patch.svn-base': No such file or directory
find: `./usr/gentoo/overlays/java-experimental/dev-java/hamcrest/files/.svn/text-base/hamcrest-1.2-no_source_in_jar.patch.svn-base': No such file or directory
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-instantiated/.svn/entries': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-instantiated/.svn/tmp': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-misc/.svn': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-misc/ChangeLog': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-misc/Manifest': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/lucene-misc/metadata.xml': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/onion-common/.svn/text-base/metadata.xml.svn-base': Input/output error
find: `./usr/gentoo/overlays/java-experimental/dev-java/onion-common/.svn/text-base/onion-common-20020926.ebuild.svn-base': Input/output error
./sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ata8/power/autosuspend_delay_ms

all seem to be involved in VCS software such as svn, hg and git

edit2:

I'm following the advice from Edward from a similar case in the past:

Re: reiser4 w. cryptcompress data-corruption (?!)

fsck.reiser4 --build-fs

worked wonderfully

[Matias Jose Seco]

Hello, i would like to ask you about hash options that R4 offers: (i've seen that their was an initial analysis on page 1 )
The official options are five: Rupasov, R5, Tea, Fnv1, Degenerative. I'm interested about your opinion upon this informations i've founded about them:

• Rupasov: Fast with high collision probabilities that respects locality, mapping lexicographically (from mount's man, reiserfs section)
  R5: Modified version of Rupasov hash: default hash (from mount's man, reiserfs section)/ Note: it's not advised for huge directories or unusual file-name patterns (How huge shouldn't be, for you, reader^^ ? )
  Tea: Low collisions hash at cost of more CPU usage (from mount's man, reiserfs section)
  Fnv1: Fast maintaining low collision rate ( http://www.isthe.com/chongo/tech/comp/f ... lic_domain )
  Degenerative: ?

NOTES: at http://www.koders.com/c/fid4D8151FF9D43 ... aspx?s=crc they comment out that:
- Fnv1 printed version seems to preserve lexicographical order locally
- Degenerative hash is used to simplify testing of non-unique key handling

What you think about it? Did you have any experience about?

PS: i apologize if this post could be, in any way, out of thread