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

Message

DigitalCorpus · Post by **DigitalCorpus** » Fri Oct 02, 2009 7:00 pm

This is probably why I experience a massive slow down in my workflow when trying to test BFS then. I was hoping that Reiser4 would be introduced into the mainline by now as predicted at the beginning of summer.
*crosses fingers*
btrfs is similar in performance, but still doesn't match R4 for small files.

kernelOfTruth · Post by **kernelOfTruth** » Fri Oct 02, 2009 7:10 pm

zen-sources bug-tracker: "Reiser4 errors"

energyman76b · Post by **energyman76b** » Sat Oct 03, 2009 5:43 am

'normal' sources are ok. So it is either a bug with zen or a bug in mmotm-reiser4 which is AFAIK pretty broken.

seqizz · Post by **seqizz** » Sat Oct 03, 2009 6:03 pm

unK wrote:
seqizz wrote:i don't know why this is happening, but since i've started to using reiser4 for my root folder (/) , i'm taking some lockups when using resources heavily. Also i made a change on fs (e.g edit a file) and after one reboot, it's turning back to old one, like i've never touched the file.. (wtf? ) i think i should change my mount options, btw i'm using KernelOfTruth's last recipe..
what kernel do you use? I once had such behaviour with zen-sources.

Using 2.6.31-zen1..

energyman76b · Post by **energyman76b** » Sat Oct 03, 2009 6:13 pm

seqizz wrote:
unK wrote:
seqizz wrote:i don't know why this is happening, but since i've started to using reiser4 for my root folder (/) , i'm taking some lockups when using resources heavily. Also i made a change on fs (e.g edit a file) and after one reboot, it's turning back to old one, like i've never touched the file.. (wtf? ) i think i should change my mount options, btw i'm using KernelOfTruth's last recipe..
what kernel do you use? I once had such behaviour with zen-sources.
Using 2.6.31-zen1..

seriously, stay away from that. Reiser4 in mmotm is broken. They use reiser4 from mmotm. Use vanilla-sources, patch them with reiser4-for-2.6.30 and you won't have any problems.

unK · Post by **unK** » Sat Oct 03, 2009 6:20 pm

Well, then take gentoo/vanilla sources, patch it with reiser4 from here (afaik 2.6.30 version applies cleanly to 2.6.31) and see if the problem still occurs. Ah, and check your partition with fcsk immediately, I suspect your fs is far from being clean after these hang-ups.

Ant P. · Post by **Ant P.** » Sat Oct 03, 2009 7:25 pm

seqizz wrote:Also i made a change on fs (e.g edit a file) and after one reboot, it's turning back to old one, like i've never touched the file.. (wtf? )

This is a Good Thing. You don't get so lucky when ext4 crashes, it eats your files and you get a zero-byte .bash_history (hope you don't get a crash after reinstalling glibc!). ext4's behaviour is technically acceptable according to POSIX (and xfs also does it), but you can probably agree it's a really idiotic thing to do to 99% of users.

DigitalCorpus · Post by **DigitalCorpus** » Sun Oct 04, 2009 11:07 am

Okay, so I decided to do a full on emerge -e just for kicks and giggles despite the problems you all have had with the current/prior R4 patch with 2.6.31 and zen sources. Watching the clock and /proc/meminfo it turns out that R4 would not flush to disk when /proc/sys/vm/ dirty_ratio was being hit. It was only engaging when dirty_expire_centisecs was reached. I know you guys have a fix already, but seriously looking at what is configured here can greatly affect how your system responds with pending disk activity. A couple of these affect how much data you'll loose too if you loose power

One other thing workaround to use if this happens in a future release. just copy and paste this code into your command line and it'll force the kernel to sync any dirty pages:

Code: Select all

echo 1 > /proc/sys/vm/drop_caches

kernelOfTruth · Post by **kernelOfTruth** » Tue Oct 06, 2009 10:55 pm

the problem should be fixed - at least with 2.6.31-zen* (zen-stable) - all of you who are/were affected by this problem and using zen-sources:

please update to 2.6.31-zen2

if the fix isn't included yet:
http://thread.gmane.org/gmane.comp.file ... ocus=22626

<-- this fixes the introduced problem with reiser4-for-2.6.31 that reiser4-specific mount-options aren't recognized

kudos to Edward

darklegion · Post by **darklegion** » Thu Dec 03, 2009 2:32 am

I'm having a problem with saving a file with vim to a reiser4 + lzo compression filesystem.It is taking 5-10+ seconds to save a simple text file.If I save it to an ext2/ext3 partition it saves near instantly.If I use nano to save to the r4+lzo filesystem, it also saves instantly.

So this is probably an issue with vim, but since you guys are more familiar with the issues of transparent compression, I feel I'll get better answers here.

Thanks

DigitalCorpus · Post by **DigitalCorpus** » Thu Dec 03, 2009 6:31 am

run a check on your R4 partition

Code: Select all

fsck.reiser4 -y --fix --build-fs --build-sb

Just make sure you tack on the /dev path to your unmounted partition. That shouldn't be happening. I've not experienced delays like that. Can you give us more information like the size of the file and your mount options?

darklegion · Post by **darklegion** » Thu Dec 03, 2009 8:23 am

DigitalCorpus wrote:run a check on your R4 partition
Code: Select all
fsck.reiser4 -y --fix --build-fs --build-sb
Just make sure you tack on the /dev path to your unmounted partition. That shouldn't be happening. I've not experienced delays like that. Can you give us more information like the size of the file and your mount options?

File could be 1 byte or 100MB, it makes no difference (I just tested with a 0 byte file with nothing in it; same result).I should note that the drive is a 8GB Sandisk Ultra II SDHC card, and is in an Acer Aspire One netbook, which uses an Intel Atom N270 @ 1.6ghz.Write speed is 16-19 MB/s when copying a file from an ext2 fs to the r4-lzo filesystem.I don't have any other drives to test with, but copying data from the ext2 fs to the same ext2 fs, results in a write speed of 26.9 MB/s.So there is a performance hit, but it shouldn't be enough to cause these symptoms.

Filesystem is mounted with 'noatime' ; no other options are used.

EDIT: I just checked the filesystem.It had errors and they were fixed but it didn't help the issue.

DigitalCorpus · Post by **DigitalCorpus** » Thu Dec 03, 2009 10:43 am

I would venture to guess since you're writing to flash media, that is then your problem

normal flash memory use in USB sticks responds extrememly poorly to random reads and write. Even sequential reads and writes that are close to cluster size. Reiser4 is a journaled filesystem. this means before or while data is being written, the journal is being written to as well. journal transactions are tiny. you should only be using ext2 or btrfs w/ ssd mount option, or another flash-specific file system on that memory card.

darklegion · Post by **darklegion** » Thu Dec 03, 2009 11:39 am

DigitalCorpus wrote:I would venture to guess since you're writing to flash media, that is then your problem

normal flash memory use in USB sticks responds extrememly poorly to random reads and write. Even sequential reads and writes that are close to cluster size. Reiser4 is a journaled filesystem. this means before or while data is being written, the journal is being written to as well. journal transactions are tiny. you should only be using ext2 or btrfs w/ ssd mount option, or another flash-specific file system on that memory card.

Is there a benchmark for random writes? I'd like to see if it's a general system issue, or just a problem with vim, as nano saving instantly is still giving me pause.Perhaps vim's heaviness is the problem, maybe there are some tweaks to help it perform better?

Anyway, I'll check out btrfs, I've always wanted to try it out.It does have compression support, too, but zlib is probably a bit too heavy for the Atom.Shame really, as I could really use the space that compression saves.

gerardo · Post by **gerardo** » Sat Dec 05, 2009 5:42 pm

kernelOfTruth wrote: best reiser4-partition creating options are so far:

mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=ultim,cluster=8K,fibration=lexic_fibre,formatting=smart for /usr/portage

and

mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=ultim,cluster=8K,formatting=smart (without the lexic ordering) for / (root / or system how you like to call it)

mount-options are so far:

noatime,nodiratime,tree.cbk_cache.nr_slots=48 (you might need to lower tree.cbk_cache.nr_slots to 24 or 32 if you have low memory, dunno right now how memory usage depends on it)

And what about the home partition?
I have a lot of mp3, avi, zip...

DigitalCorpus · Post by **DigitalCorpus** » Sat Dec 05, 2009 9:44 pm

Use something other than reiser4 for your home partition is you have already compressed content since the data will not compress further

kernelOfTruth · Post by **kernelOfTruth** » Sat Dec 05, 2009 10:17 pm

DigitalCorpus wrote:Use something other than reiser4 for your home partition is you have already compressed content since the data will not compress further

++

someone also wrote about hash collisions when using the default r5 hash and recommends using the tea hash

so I'd go the safe road for now and use reiserfs v3.6 or any other long tested filesystem ...

darklegion · Post by **darklegion** » Sun Dec 06, 2009 7:18 am

DigitalCorpus wrote:I would venture to guess since you're writing to flash media, that is then your problem

normal flash memory use in USB sticks responds extrememly poorly to random reads and write. Even sequential reads and writes that are close to cluster size. Reiser4 is a journaled filesystem. this means before or while data is being written, the journal is being written to as well. journal transactions are tiny. you should only be using ext2 or btrfs w/ ssd mount option, or another flash-specific file system on that memory card.

I just tried out Btrfs with compress and ssd mount options enabled, and vim now saves at a reasonable speed (around 1 sec).Space usage is about the same as reiser4+lzo although I expect cpu usage will probably be higher with zlib.

HecHacker1 · Post by **HecHacker1** » Sun Dec 13, 2009 3:17 am

Just as a warning, I wouldn't use btrfs yet. It is absolutely not stable and still randomly segfaults. Basically the devs have only started on working on all the edge cases and problems.

I myself was using btrfs w/compression in a Virtual Machine and the FS panics after a hard reset.

fsck.btrfs also segfaults when trying to check that filesystem. Luckily I didn't loose any data because I was able to mount it in read only mode to retrieve it.

If you check out the btrfs mailing list you will see daily errors and problems people have. The devs have not even responded to my problem.

Right now I'm trying to decide between reiserfs/ext4/xfs/ and reiser4/w lzo compression.

So I am actually going to copy my / partiton to each filesystem and compare. This is on a laptop, 320GB disk split into 8 partitons. 5400rpm.

I've already done:

BTRFS w/compress: Much slower to boot (over a minute). Slower to the desktop. But fsync's (and small random r/w) are surprisingly fast. Without compression the speed is not much better on 2.6.31. I tried 2.6.32 which is supposed to have improvements, but my laptop doesn't boot because of a bug in 2.6.32. It did survive hard resets and I never had to fsck.

XFS: Pretty good performance. Much faster than btrfs w/compression (on my older pentium-m 1.7GHz). bootchart 49s. Opens Firefox/chrome faster than reiser4. 20GB used.

Reiser4 w/lzo: Fastest when working with portage (syncing, searching). However I get small lag spikes when something like tracker is indexing. With xfs, Tracker doesn't distract. bootchart 40s. 10GB used. I should warn that I am getting compression errors in my dmesg, Reiser4 is saying the file/block is corrupt. Yet when I do a reiser4.fsck it comes back clean. I think this might be a 2.6.31/2.6.32-zen problem.

Reiserfs: 17GB used, 3GB improvement from XFS. Still haven't tested it. Will update.

Ext4: Feels like less lag when using a web-browser than reiser4 w/lzo. Portage sync is alright, similar to xfs, but reiser4 blows it away. A stable FS and I have never lost data with ext4. Still need to test bootchart.

darklegion · Post by **darklegion** » Sun Dec 13, 2009 7:48 am

HecHacker1 wrote:Just as a warning, I wouldn't use btrfs yet. It is absolutely not stable and still randomly segfaults. Basically the devs have only started on working on all the edge cases and problems.

I'm doing daily backups, so I'm not too worried.

I also didn't see any slowdowns when booting or anywhere else.I don't think fsck is supported at all yet, but that doesn't necessarily mean it will fail during the first hard reset/power failure (although I guess it did, for you).
I'm using 2.6.32, BTW.

dusanc · Post by **dusanc** » Tue Dec 15, 2009 11:04 am

HecHacker1 wrote:...

Right now I'm trying to decide between reiserfs/ext4/xfs/ and reiser4/w lzo compression.

So I am actually going to copy my / partiton to each filesystem and compare. This is on a laptop, 320GB disk split into 8 partitons. 5400rpm.
...

Ofcourse you tested all filesystems on same partition?

Dont Panic · Post by **Dont Panic** » Wed Dec 30, 2009 4:52 pm

What are the current solutions for Reiser4 for the 2.6.32 kernel.

I see where Edward Shishkin has a brief comment that the reiser4 in the zen-sources 2.6.32 kernel may not work correctly.

http://kerneltrap.org/mailarchive/reise ... 703/thread

At any rate, I am having a hard time finding a stable configuration for a zen-sources kernel.

Are there other options?

kernelOfTruth · Post by **kernelOfTruth** » Wed Dec 30, 2009 5:07 pm

Dont Panic wrote:What are the current solutions for Reiser4 for the 2.6.32 kernel.

I see where Edward Shishkin has a brief comment that the reiser4 in the zen-sources 2.6.32 kernel may not work correctly.

http://kerneltrap.org/mailarchive/reise ... 703/thread

At any rate, I am having a hard time finding a stable configuration for a zen-sources kernel.

Are there other options?

your best bet is to start from the following topic:

http://thread.gmane.org/gmane.comp.file ... eral/22676

http://news.gmane.org/gmane.comp.file-s ... fs.general

currently I'm not using reiser4 at all so I can't say much but the following:

* reiser4 with cryptcompress seems to work reasonably well enough (last time I used it only on /usr/portage; large partitions or file-transaction seem to result in BUG)

* reiser4 without cryptcompress seems to be broken - at least fsync, it will sync data to the partition during umount but in addition to that seems to handle it in a wrong way [I'm referring to zen-kernels !; try the latest if it got fixed - from what I read it works again !]

lightvhawk0 · Post by **lightvhawk0** » Thu Apr 15, 2010 1:14 am

anyways I decided to rice out reiser4

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

I decided to hell with compression, and tail packing since I have 500gb hdd I'm running reiser4 on.

So far it seems to be immensely fast.

I was wondering if it would be better to change the hash algorithm as well?

kernelOfTruth · Post by **kernelOfTruth** » Thu Apr 15, 2010 1:28 am

better don't mess with the hash-algo unless you're fond of collisions

for /usr/portage you could try another algo for a data-partition (with safety in mind) I wouldn't risk it,

r5 or tea should be safe

*) tea for less collisions

*) r5 [=default] for more performance in directory-lookups

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

Warning

Re: Warning

Re: Warning