4+ cores on linux

Misfit138 · 2010-04-20 01:13:45

whaler wrote:

I was shocked the other day to hear that ReiserFs is not a good fit for multicore CPUs.
Guess I have to reinstall Arch yet again. Should I go with ext4?

NO.

ngoonee · 2010-04-20 01:30:56

Kiwi wrote:

This is not windows, you do not have to reinstall for something so trivial.
And what is wrong with reiserfs on multi core? Never had a problem and have run it on multi core systems for years...

+1. Check your source carefully, there's lots of 'OMG we lose 2%' type information on the internet.

broch · 2010-04-20 02:47:45

Check your source carefully, there's lots of 'OMG we lose 2%' type information on the internet.

ReiserFS3 is designed for single core as some operations will run one at a time irrelevant of number of cores and ReiserFS4 still uses BKL though some changes are available since 2.6.33. Evidently this is unknown. BLK defies advantages of multicore which is a reason why contemporary kernels are BLK (mostly) free with exception os older stuff that is mostly dormant (different reasons, not always something can be done fast)

Last edited by broch (2010-04-20 03:35:16)

ngoonee · 2010-04-20 04:22:29

broch wrote:

Check your source carefully, there's lots of 'OMG we lose 2%' type information on the internet.
ReiserFS3 is designed for single core as some operations will run one at a time irrelevant of number of cores and ReiserFS4 still uses BKL though some changes are available since 2.6.33. Evidently this is unknown. BLK defies advantages of multicore which is a reason why contemporary kernels are BLK (mostly) free with exception os older stuff that is mostly dormant (different reasons, not always something can be done fast)

Well, if the filesystem is limited to one core, the others will still be used for applications (I guess), so is it REALLY an issue? Or rather, does reiser not being able to use more than 1 core for FS-related operations carry any real meaning for use of the system as a whole?

whaler · 2010-04-20 10:01:47

I haven't had any problems either, as such, but perhaps we've been missing some performance? According to this article

http://maketecheasier.com/choosing-the- … 2010/04/13

"Reiser3 has problems, however when it comes to handling things like multicore PCs, as the design only allows for some operations to run one at a time."

I have not been able to find any corroboration of this claim, nor another discussion of better/best FS match for multicore CPUs, but if the claim is correct, I'd like to try another FS for /.

What is the easy method for changing FS on the root partition? Making an image, reformat and copy back from the image?

Last edited by whaler (2010-04-20 10:11:36)

whaler · 2010-04-20 10:07:08

Misfit138 wrote:

whaler wrote:
Should I go with ext4?
NO.

OK, thanks

Which would you suggest?

broch · 2010-04-20 12:37:50

ngoonee wrote:

broch wrote:
Check your source carefully, there's lots of 'OMG we lose 2%' type information on the internet.
ReiserFS3 is designed for single core as some operations will run one at a time irrelevant of number of cores and ReiserFS4 still uses BKL though some changes are available since 2.6.33. Evidently this is unknown. BLK defies advantages of multicore which is a reason why contemporary kernels are BLK (mostly) free with exception os older stuff that is mostly dormant (different reasons, not always something can be done fast)
Well, if the filesystem is limited to one core, the others will still be used for applications (I guess), so is it REALLY an issue? Or rather, does reiser not being able to use more than 1 core for FS-related operations carry any real meaning for use of the system as a whole?

well in the case of fs this is an issue: what is the point of having fast app if this specific app has to wait for file system to do the job? whole OS is affected, this is not slow app that works in the background but file system which affects many things if it is not fit for a job.

whole discussion is about things that does not have much effect on desktop performance: fast single CPU will do better than slow dual core, this will more affect server than desktop. However if you ask if BKL has an effect on multicore performance, then yes and and that is big one. This has nothing to do with desktop benchmarks but scalability.
Intel and AMD at some point hit the roof and can't simply increase HZ on desktop CPUs, so they switched to multicore and 64-bit not because this is better for desktop but because current CPU arch is limited. So desktop got instead of higher CPU HZ multicore CPU.

I was shocked the other day to hear that ReiserFs is not a good fit for multicore CPUs.

whaler asked if ReiserFS is suitable for multicore. Simple answer is no and your answer is incorrect. As is Kiwi's
This mostly affects servers, but is some situations desktop will suffer too. But this also goes with choice of multicore cpus on desktop or 64-bit on desktops.
If one configure desktop with Reiserfs with extended attributes, ACL then fs will get slow . Obviously this is not major concern of most of desktop users. But OO.org or firefox and a lot of other apps will not really profit from 64-bit CPUs still users "demand" nowadays multicore, 64-bit CPUs.

@whaler:

I haven't had any problems either, as such, but perhaps we've been missing some performance? According to this article

no, if you don't have any problems, then stay where you are. No need to switch to another fs.

Last edited by broch (2010-04-20 12:50:23)

whaler · 2010-04-20 13:16:00

broch wrote:

no, if you don't have any problems, then stay where you are. No need to switch to another fs.

Thanks for straightening this out somewhat, broch, but _might I gain _some performance boost with another fs?

You've already said that e.g. OpenOffice does not benefit noteworthy from 64bit/multicores, but as I am working with very large calc documents, every little speed increase would be welcome. In short: what is the best fs match under Linux for a multicore CPU (quad core, in my case)?

broch · 2010-04-20 14:35:52

ReiserFS4 is best for small files
ext3 is o.k, very stable and proven working reliably.
ext4 is buggy version of xfs
xfs is designed for big files (multimedia) and for multicpu systems with high parallelism.
btrfs is still in testing so you would have smaller or bigger problems witch almost each kernel upgrade
jfs is o.k. but has some outstanding bugs not yet resolved completely (read only fs after unexpected shutdown)

I don't think that I would be able to give a good advice for your setup.
Personally I am using xfs with a lot of format flags that are not included in default formatting rutine and this works for me.
In addition there is plenty of system calls (sysctl) that might help to squeeze max fs performance.
In ideal situation, I would suggest create partition for testing different fs. If you decide to go this way, learn about best format flags for each file system (for example although xfs is best fitted for big files, you can make it perform very well also for small files).

Users are pretty happy with ReiserFS.
If you have almost database size Calc files maybe xfs with optimized format flags will suit you better. I must warn you though that with each file system you will gain some and you will loose some so consider all pros and cons before diving into format (fs converting will not work if you want max performance). While you can also tune db for best fs/cpu performance I am not sure how this will go with openoffice files.
I would suggest to check also openoffice site, they may suggest ext3/4 also

pseudonomous · 2010-04-20 17:49:16

broch wrote:

ReiserFS4 is best for small files
ext3 is o.k, very stable and proven working reliably.
ext4 is buggy version of xfs
xfs is designed for big files (multimedia) and for multicpu systems with high parallelism.
btrfs is still in testing so you would have smaller or bigger problems witch almost each kernel upgrade
jfs is o.k. but has some outstanding bugs not yet resolved completely (read only fs after unexpected shutdown)

This is a huge over-simplification of a comparison of the filesystems, and I would argue it's particularly inaccurate to characterize ext4 as merely "a buggy version of xfs". Certainly, ext4 and xfs differ significantly in their capabilities and performance at various tasks, though I don't know if they share similarities at the implementation level.

Basically, to find what filesystems are best suited for a particular purpose, there doesn't seem to be any better way than doing/reading some benchmarks, guessing and using trial and error; for a desktop it's pretty questionable whether it's worth the trouble to migrate filesystems to gain some negligible performance benefit.

Kiwi · 2010-04-20 18:41:52

Lol, claim I am wrong (which I really am not, but whatever) and then make wild over simplifications and spread some FUD at the same time. Niiiice.

broch · 2010-04-20 19:39:13

pseudonomous wrote:

broch wrote:
ReiserFS4 is best for small files
ext3 is o.k, very stable and proven working reliably.
ext4 is buggy version of xfs
xfs is designed for big files (multimedia) and for multicpu systems with high parallelism.
btrfs is still in testing so you would have smaller or bigger problems witch almost each kernel upgrade
jfs is o.k. but has some outstanding bugs not yet resolved completely (read only fs after unexpected shutdown)
This is a huge over-simplification of a comparison of the filesystems, and I would argue it's particularly inaccurate to characterize ext4 as merely "a buggy version of xfs". Certainly, ext4 and xfs differ significantly in their capabilities and performance at various tasks, though I don't know if they share similarities at the implementation level.
Basically, to find what filesystems are best suited for a particular purpose, there doesn't seem to be any better way than doing/reading some benchmarks, guessing and using trial and error; for a desktop it's pretty questionable whether it's worth the trouble to migrate filesystems to gain some negligible performance benefit.

from post #34

In ideal situation, I would suggest create partition for testing different fs.

You did not say anything more.
Whole thread is not about superiority of specific fs, i pointed out that every fs will have some advantages/disadvantages. benchmarks aren't informative although for some reason seem to be good enough for posting results (and not much more).
The main ext4 developer moved from xfs, major ext4 bugs resemble early xfs for linux development, except that xfs at least for now has better solution.
Of course this is oversimplification but this is not a thread about file systems only.

Lol, claim I am wrong (which I really am not, but whatever) and then make wild over simplifications and spread some FUD at the same time. Niiiice.

yes, you are wrong. (and learn what FUD means)

pseudonomous · 2010-04-20 20:41:53

en.wikipedia.org wrote:

FUD is generally a strategic attempt to influence public perception by disseminating negative and dubious/false information designed to undermine the credibility of their beliefs

Would you like to substantiate your claim that xfs is "a buggy verson of xfs"? Personally, I've never experienced any data loss on ext3, though I know there was an issue with data loss in KDE4 apps, that was eventually attributed to those apps not calling fsync. I could believe there might have been some other bugs since it's a new FS, but I haven't seen them in my personal use.

I have experienced some file corruption using reuser3, I would find that lines in text files had been permuted if I had been modifying them shortly before an unsafe poweroff.

How about the "version of xfs" part? Well, you can shrink an ext4 partition, but you can't shrink an xfs partition, you can convert ext2/3 partitions to ext4 partitions, but you can't do the same with an xfs partition, there are benchmarks, e.g at Phoronix (yes, not always so reputable, but this particular set isn't so bad:

http://www.phoronix.com/scan.php?page=a … 2_fs&num=1

And you can see marked differences in the performance of XFS vs ext4. I'm not saying one is better than the other. But I am saying ext4 is a significantly different beast from XFS and that it has been, at least in my experience, reasonably safe to use. In fact, at least in my experience, it has been safer to use than reiser3.

Also xfs wasn't so much designed for machines with "high parallelism" as it was designed for machines running Irix, which certainly included sbot ingle core and many core mips machines. It does have some interesting features for maximizing I/O when used on raid arrays, though.

whaler · 2010-04-21 02:41:29

We clearly need to discuss file systems more

broch wrote:

ReiserFS4 is best for small files
Users are pretty happy with ReiserFS.
(...)
I would suggest to check also openoffice site, they may suggest ext3/4 also

I, too, have been happy with ReiserFS (3). However, we generally want the best tool for the job and I think I will try ext3 on my next clean Arch install, when a new image is available. Perhaps ext4 would be even better, but opinons vary about its maturity...

I am not qualified for serious tweaking of XFS, but I can say that JFS has been very reliable here the last 10 years or so (including with LVM under OS/2, way back...). Thank you for good advice!

Last edited by whaler (2010-04-21 02:46:46)

flamelab · 2010-04-21 03:13:53

Ext4 "a buggy version of XFS" ? <laughing>

Kiwi · 2010-04-21 04:05:37

I think broch is confusing "optimal" and "good." Just because reiserfs is not "optimal" on multi core CPUs does not mean it is not "good" on them...sure it may not take full advantage of having multiple CPUs but that does not mean it does not have other redeeming qualities, nor does it invalidate that in some cases it does perform better than its competitors.

I have had (in some cases very major) problems with every file system I have used, but reiserfs has had the least amount of them and I have used it the longest and in the most places. I have used ext2, ext3, reiser4, reiserfs, btrfs, the various fats, and, ofc, ntfs for Windows stuff.

Ghost1227 · 2010-04-21 05:18:43

In my experience, reiserfs is infinitely more stable than most (if not all) other filesystems... extx all caused problems with my computer, i don't trust btrfs yet (although the concept is interesting), etc... but reiser has never given me an issue.

broch · 2010-04-21 12:32:37

@pseudonomous

Would you like to substantiate your claim that xfs is "a buggy verson of xfs"?

no problem: kindly check kernel changelogs dealing with ext4 bugs: each almost time this is the reference to xfs (including possible solutions), if you also check lkml then you would see that ext4 is often compared to xfs.

Phoronix benchmarks: this one was criticized so many times (including the fact that some test measuerd in fact CPU load, not fs, and it is not clear how fs were set up, and why testers settled with specific setup). In addition, currently the only safe way to run ext4 is with enabled barriers which was reported that ext4 perform worse in some tests than ext3.
Because you at first propose Phoronix benchmarks then you dismiss them then eventually accept (in part) Phoronix results, I think that you are mostly confused.

@Kiwi
question is not what is good but if multicore can be efficiently used by linux. Answer is simple Reiserfs3/4 is not optimal for multicore because of BKL. Evidently you did not know (now you do) about BKL and what this means for system performance.
@whaler
For new system, I would go with reiserfs4 (particularly now when devs are removing BKL from reiserfs4), ext4 is simply buggy/unstable (there are funny and harsh Torvalds) and no Phoronix benchmarks will help. In the end this is going to be your setup so whatever works best for you it counts.

Personally, I doubt that switching from one fs to another is worth an effort (reason why I pointed flaws, not merits if any of specific fs). One would have to have really compelling reasons to change file system.

falconindy · 2010-04-21 13:24:13

Until the BKL is removed in its entirety, it won't matter if a filesystem doesn't use it. There's too many other hurdles for the removal of BKL in one place to have an effect. Given that the patchset to remove the BKL only surfaced a few weeks ago, we probably won't see it until the release of 2.6.35 (if we're lucky) which is likely, at a minimum, 5 months away.

Cdh · 2010-04-21 22:08:01

broch wrote:

jfs is o.k. but has some outstanding bugs not yet resolved completely (read only fs after unexpected shutdown)

Uhm no. My father often halts the PC with the power button (I can't get him to stop that...) and I have seen this happening only once in what has to be over a year...
On my eee I didn't see this once at all despite sometimes being powered off because of low battery or dirty filesystem because of some glitches in hibernate (which are now completely resolved).

whaler · 2010-04-21 22:22:49

broch wrote:

@whaler
For new system, I would go with reiserfs4 (particularly now when devs are removing BKL from reiserfs4), ext4 is simply buggy/unstable (there are funny and harsh Torvalds) and no Phoronix benchmarks will help. In the end this is going to be your setup so whatever works best for you it counts.
Personally, I doubt that switching from one fs to another is worth an effort (reason why I pointed flaws, not merits if any of specific fs). One would have to have really compelling reasons to change file system.

Well, having read the various comments here, and looked at the interesting Phoronix test results (they do measure *something*, on the same hardware...), I am in less of a hurry to change fs. A bit surprised, though, that you would recommend ReiserFS4 over, say, ext3. I thought the ReiserFS team was completely dormant/incapacitated and hence that ReiserFS4 was not being maintained/improved at this time.

I have only used ext2/3, Reiser3 and JFS under Linux, and only Reiser3 on my root partition, and been lucky enough almost never to encounter any fs problems. The exception has been JFS on an external hdd, caused by failing memory sticks resulting in forced shutdowns before the failure was detected...

Ranguvar · 2010-04-23 03:43:38

Reiser4 is being maintained. I'm not sure how willing I'd be to recommend it, but it is definitely being maintained.

http://kerneltrap.org/mailarchive/reiserfs-devel/2010

Arch Linux

#26 2010-04-20 01:13:45

Re: 4+ cores on linux

#27 2010-04-20 01:30:56

Re: 4+ cores on linux

#28 2010-04-20 02:47:45

Re: 4+ cores on linux

#29 2010-04-20 04:22:29

Re: 4+ cores on linux

#30 2010-04-20 10:01:47

Re: 4+ cores on linux

#31 2010-04-20 10:07:08

Re: 4+ cores on linux

#32 2010-04-20 12:37:50

Re: 4+ cores on linux

#33 2010-04-20 13:16:00

Re: 4+ cores on linux

#34 2010-04-20 14:35:52

Re: 4+ cores on linux

#35 2010-04-20 17:49:16

Re: 4+ cores on linux

#36 2010-04-20 18:41:52

Re: 4+ cores on linux

#37 2010-04-20 19:39:13

Re: 4+ cores on linux

#38 2010-04-20 20:41:53

Re: 4+ cores on linux

#39 2010-04-21 02:41:29

Re: 4+ cores on linux

#40 2010-04-21 03:13:53

Re: 4+ cores on linux

#41 2010-04-21 04:05:37

Re: 4+ cores on linux

#42 2010-04-21 05:18:43

Re: 4+ cores on linux

#43 2010-04-21 12:32:37

Re: 4+ cores on linux

#44 2010-04-21 13:24:13

Re: 4+ cores on linux

#45 2010-04-21 22:08:01

Re: 4+ cores on linux

#46 2010-04-21 22:22:49

Re: 4+ cores on linux

#47 2010-04-23 03:43:38

Re: 4+ cores on linux

Board footer