2 cores vs. 4 cores in Linux [Archive]

View Full Version : 2 cores vs. 4 cores in Linux

Mickeydi

08-04-2009, 07:32 AM

Hello all.

I intend to purchase a new desktop, and would like your opinion/advice on whether a 2 core 3Ghz system, or a slower quad core are best suited for me.

I'm a physics grad student, so at the office i usually use software like Lyx, Octave and such. I know that currently octave can not utilize well a multi core processor (like MatLab can), and Lyx is not a demanding software. So when it comes to office work, i am more concerned as to how Linux deals with more then 2 cores. Is there any advantage in using more than 2 cores? If i use a kernel compiled with smp how much will i benefit from a quad processor? Can Linux use it to run several programs more efficiently? What about Linux applications in general?

Thanks in advance

RealNC

08-04-2009, 02:23 PM

I recommend a faster 2-core because there are freezing issues in Linux due to I/O blockage, meaning that even though a program would run on its own core, it would get slowed down when there's heavy I/O load. A faster 2-core will make these freezes shorter due to its higher clock speed.

kraftman

08-04-2009, 02:48 PM

RealNC

08-04-2009, 03:31 PM

Related to clock speed, which is why I recommend a fast 2-core rather than a slow 4-core.

frantaylor

08-04-2009, 05:06 PM

I have an 8-core machine for running many simultaneous VMware images, and it runs without a hitch. My VMware images are single files of about 30 Gb and I have never had any problems copying them.
I use XFS with optimization tweaks on my disk and it is VERY fast.

pbzip can use all your cores to compress or uncompress files, it is very impressive with 8 cores.

The Adobe flash plugin appears to be multithreaded because it chews up several cores when I play hi-res youtube videos at full screen 1920x1200.

If your crunching jobs use lots of memory then memory speed will be more important than CPU clock speed. My 2.5 GHz machine stomps all over my 2.6 GHz machine because its RAM is twice as fast.

frantaylor

08-04-2009, 11:04 PM

It seems like a I/O bug when copying large files. Rather not related to number of cores.

I have run processes that saturate the drive I/O. You can see huge numbers in gkrellm. If you try to run another process that touches the same drive, it will bog down terribly. For example, I put my /home on its own drive. If I start a backup of a big subdirectory of my home directory and then launch a gnome program, the gnome program will take FOREVER to boot up because the OS will not give it the I/O bandwidth it needs to read its ~/.gnome-whatever file.

This is a problem in Linux with scheduling I/O and many cores. One process gets all the bandwidth and others can't get a word in edgewise.

Kano

08-05-2009, 05:10 AM

@Mickeydi

For desktop use 3 GHz dual is usually enough (using E8400). When you use Intel Quad with 2.5 GHz it is usally no problem to OC that to 3 GHz too, thats what I did with my Q9300. When you are used to 3 GHz you never want something slower again, but more cores are mainly used for compiling and some apps which scale well with more cores like 7zip. If i would need to buy a new cpu today i would go for a Q9550 (2.83 GHz) and OC that a bit. OC requires a good board, so go for P45 or wait till next month for first i5 systems. I guess those will rock too.

kraftman

08-05-2009, 06:23 AM

I have run processes that saturate the drive I/O. You can see huge numbers in gkrellm. If you try to run another process that touches the same drive, it will bog down terribly. For example, I put my /home on its own drive. If I start a backup of a big subdirectory of my home directory and then launch a gnome program, the gnome program will take FOREVER to boot up because the OS will not give it the I/O bandwidth it needs to read its ~/.gnome-whatever file.

This is a problem in Linux with scheduling I/O and many cores. One process gets all the bandwidth and others can't get a word in edgewise.

It seems it's the bug I was talking about :/ It's rather not related to many cores. It's very well known and strange bug:

http://bugzilla.kernel.org/show_bug.cgi?id=12309

Thanksfully not everyone is affected, but sadly I am... There's workaround, but I didn't tried it. If you're interested let me know :) You see, it's probably not design problem, but a bug.

lordmozilla

08-05-2009, 07:37 AM

A slower 4 core will get you further. If anything you will have more cache (true of phemom IIs where the cache is shared and not on core2quads) and clockspeeds arent much lower, the only advantage of dual cores is they are cheaper in the real low end, but apart from that...

Also all current Core2s and phenomIIs overclock really well so you could do that if you wanted to match the 3.0ghz core2duos.

frantaylor

08-05-2009, 10:00 AM

It seems it's the bug I was talking about :/ It's rather not related to many cores. It's very well known and strange bug:

http://bugzilla.kernel.org/show_bug.cgi?id=12309

Thanksfully not everyone is affected, but sadly I am... There's workaround, but I didn't tried it. If you're interested let me know :) You see, it's probably not design problem, but a bug.

Did you see the status of that bug report: RESOLVED INSUFFICIENT_DATA

Did you read the comments in the bug report?

"this bug has long past the point where it is useful.
There are far too many people posting with different issues.
There is too much noise to filter through to find a single bug.
There aren't any interested kernel developers following the bug."

It is not even a bug report, it is just a random flame fest.

kraftman

08-05-2009, 10:15 AM

Did you see the status of that bug report: RESOLVED INSUFFICIENT_DATA

Did you read the comments in the bug report?

"this bug has long past the point where it is useful.
There are far too many people posting with different issues.
There is too much noise to filter through to find a single bug.
There aren't any interested kernel developers following the bug."

It is not even a bug report, it is just a random flame fest.

Yeah, but it's only one of the reports. And it seems you didn't even read. Jens Axboe is still working on it. There's his patch also. Your reaction is very funny :)

This is a problem in Linux with scheduling I/O and many cores. One process gets all the bandwidth and others can't get a word in edgewise.It seems it's not:

Fair queuing would allow many processes demanding large levels of disk IO to each get fair access to the device, preventing any one process from denying the others.Even SFQ allowed this and CFQ moved even further. However, I don't expect from you to know this (if you even don't understand kernel versioning...). You and your friend already proved this in another thread.

Have a nice trolling there:

http://www.phoronix.com/forums/showthread.php?t=18073&page=7

RealNC

08-05-2009, 11:13 AM

kraftman

08-05-2009, 11:21 AM

My desktop applications freeze when there's heavy I/O. Of course others might pretend everything is OK simply because they don't understand the issue and think these freezes are normal/acceptable/unavoidable or they don't get them at all.

I do. There's a problem with Linux I/O and graphics. I don't know who's at fault. The problem is there. I always had it, with every PC I ever used. Windows does not have this problem; the GUI is always fluid no matter how heavy I/O load there is.

Yes, there's definitely problem with I/O on some configurations. It's science 2.6.18 like mentioned in bug report (but it's due to bug not due to design like some trolls want to profff; however long standing one, but not everyone is affected). Graphic is another case ;)

Easy way to check you're affected is to copy file which is bigger then your RAM. System becomes unresponsive for some amount of time.

frantaylor

08-05-2009, 04:44 PM

Yeah, but it's only one of the reports. And it seems you didn't even read. Jens Axboe is still working on it. There's his patch also. Your reaction is very funny :)

It seems it's not:

Even SFQ allowed this and CFQ moved even further. However, I don't expect from you to know this (if you even don't understand kernel versioning...). You and your friend already proved this in another thread.

Have a nice trolling there:

http://www.phoronix.com/forums/showthread.php?t=18073&page=7

I work with bugs every day. When the developer marks the bug as closed, that means "I'm not working on this any more"

kraftman

08-05-2009, 04:46 PM

I work with bugs every day. When the developer marks the bug as closed, that means "I'm not working on this any more"

So check date "closed" and when Jens uploaded the patch. There are also other reports like this one. If they'll close all reports there will be new, because bug is still there... Believe or not, but I'll probably switch to FreeBSD or Solaris, because of this (if it will really piss me of). However, I don't copy big files too much and I have Windows installed, so it's hard decision.

RealNC

08-05-2009, 07:04 PM

"CLOSED NEEDINFO" and "CLOSED WORKSFORME" doesn't mean there's no problem. It just means that "The Bazaar" failed.

krazy

08-05-2009, 10:27 PM

@kraftman

I was experiencing an issue something like that bug report on 2.6.30, but it seems to have improved in 2.6.31 RC5. Have you tried that?

kraftman

08-06-2009, 03:39 AM

@kraftman

I was experiencing an issue something like that bug report on 2.6.30, but it seems to have improved in 2.6.31 RC5. Have you tried that?

No, I'm using only distro provided kernels right now - 2.6.30.4, but I'll try this one and 2.6.30 with Jens patch.

@RealNC

"CLOSED NEEDINFO" and "CLOSED WORKSFORME" doesn't mean there's no problem. It just means that "The Bazaar" failed.

Exactly :>

kraftman

08-06-2009, 10:25 AM

EDITED:

I compiled 2.6.31-rc5, but X doesn't start. However I did this in vt:

I copied big file from ntfs partition using ntfs-3g to my home directory, ran "top -d 0.2" (to notice eventual slowdowns) as root in another vt and then I started copying file from home to ntfs partition (so both files were copied simultaneously). There were no single visible latency! (I can do the same with previous kernels, but after some time system becomes unresponsive).

It seems rc5 behaves much better or bug is even fixed. However, I need to try this in some DE, because it can be hard to catch latencies in vt.

frantaylor

08-06-2009, 02:05 PM

"CLOSED NEEDINFO" and "CLOSED WORKSFORME" doesn't mean there's no problem. It just means that "The Bazaar" failed.

Apparently "The Bazaar" does not do regression testing, either.

How do bugs like this make it into "RC" kernels? Does not "RC" mean "we have tested this and we think it is good"?

This is one reason why Linux has crummy market share. There are so many regressions. Normal non-hacker type people do not want to deal with regressions. They want to turn their computers on and get to work.

I wonder what can be done to deal with the regressions. Linux has no central testing lab and no formal process.

With a formal process, you are not even half done when you fix the bug. Next you have to write the regression test for the bug and then test the regression test. This usually takes more effort and more resources than fixing the bug. And then you have to run all the regression tests all the time. This requires an automated framework to run the regression tests and report the results. This is all enormous work but it needs to be done if you want to ship a quality product every time.

When you look at the bugzilla.kernel.org, there is not even a bug status for "needs testing". When something is "fixed" it gets marked as RESOLVED and that is that.

RedHat etc. have to do this testing and their kernels have hundreds of patches to the stock kernels to fix the problems that are not caught by the "Bazaar" process. When you look at these patches you see that most of them are fixes for regressions, things that used to work and then stopped working for some reason, and the regression was not caught. Or else they are driver patches for new drivers that never worked right in the first place because they did not get tested well. Some of the distribution patches stick around for years because they do not get accepted upstream for one reason or another. These patches need to be maintained as the code changes and that requires even more effort.

I don't know how it can be fixed. Nobody "owns" linux, so nobody wants to take the responsibility to do all the regression testing that should be done. The distributions "own" their kernels, but if they all do their own regression testing then there is enormous duplicated effort.

I worry that Linux is going to turn into even more of a chaotic mess as it gets bigger and gets more features. It is not the slim and trim kernel that it was back in the 90's.

kraftman

08-06-2009, 02:56 PM

Apparently "The Bazaar" does not do regression testing, either.

How do bugs like this make it into "RC" kernels? Does not "RC" mean "we have tested this and we think it is good"?

This is one reason why Linux has crummy market share. There are so many regressions. Normal non-hacker type people do not want to deal with regressions. They want to turn their computers on and get to work.

I wonder what can be done to deal with the regressions. Linux has no central testing lab and no formal process.

With a formal process, you are not even half done when you fix the bug. Next you have to write the regression test for the bug and then test the regression test. This usually takes more effort and more resources than fixing the bug. And then you have to run all the regression tests all the time. This requires an automated framework to run the regression tests and report the results. This is all enormous work but it needs to be done if you want to ship a quality product every time.

When you look at the bugzilla.kernel.org, there is not even a bug status for "needs testing". When something is "fixed" it gets marked as RESOLVED and that is that.

RedHat etc. have to do this testing and their kernels have hundreds of patches to the stock kernels to fix the problems that are not caught by the "Bazaar" process. When you look at these patches you see that most of them are fixes for regressions, things that used to work and then stopped working for some reason, and the regression was not caught. Or else they are driver patches for new drivers that never worked right in the first place because they did not get tested well. Some of the distribution patches stick around for years because they do not get accepted upstream for one reason or another. These patches need to be maintained as the code changes and that requires even more effort.

I don't know how it can be fixed. Nobody "owns" linux, so nobody wants to take the responsibility to do all the regression testing that should be done. The distributions "own" their kernels, but if they all do their own regression testing then there is enormous duplicated effort.

I worry that Linux is going to turn into even more of a chaotic mess as it gets bigger and gets more features. It is not the slim and trim kernel that it was back in the 90's.

Thanks for confirming what I suggested before. I wonder why Linux already killed Solaris? There's Linux's performance team etc. However, it doesn't matter.

I worry that Linux is going to turn into even more of a chaotic mess as it gets bigger and gets more features. It is not the slim and trim kernel that it was back in the 90's.This is what killed Solaris and other commercial Unixes. They're dying dinosaurs. It's just opposite when comes to Linux, but if you don't have anything smart to say why don't you just shut up? I know - you're a troll and you're on my ignore list now :> If you really want such flame post a new thread and pm me, because you're 'trashing' here.

@Krazy

Can you describe your problem little more? Do you notice long pauses when copying big file? Is rc5 much better or just little? I have to compile some more things to make X working and to try it :)

frantaylor

08-06-2009, 03:14 PM

Hey kraftman, do you know what "criticism" is?

It does not mean "I hate this"

It means "I like this and I want it to be better"

If I hated Linux I would not bother to post.

frantaylor

08-06-2009, 03:42 PM

Does anyone work with channel bonding and multiple cores? I used it
many years ago with ISDN and it did not work with SMP then. I hear
that they fixed it but I get kernel panics when I try to use it.

Gigabit Ethernet is not fast enough for my application. Used Infiniband cards are cheap on ebay but the cabling is too expensive. I want to try four channel-bonded gigabit ethernets, if I can get 3 Gb/sec then that would be great.

I am waiting for gear to show up in the mail so I can do some more experiments, but I wonder if anyone out there has tried the bonding driver with 2 or 4 or 8 cores and how well it works for them.

RealNC

08-06-2009, 04:30 PM

kraftman

08-06-2009, 04:45 PM

Linux is mostly developed by individuals that work for companies doing "server" and "workstation" work with Linux. A bug that affects GUI/Multimedia is quite irrelevant to those people, especially if fixing it would mean performance regressions in servers/workstations. If we consider Linux market share on the server side being over 13% while home desktops being under 2 or 3%, you can guess the priorities of the majority of kernel devs. If Linux would target the Desktop equally, it would never had become so popular on servers.

It's not exactly like this. Linux is made mainly by IBM, Intel, HP and many other companies (they test it on their machines like 'big irons', their servers, desktops etc). This bug is not multimedia one. It's not like this: focus 3/4 one servers and 1/4 on desktops. Solaris was focused on servers. However, it really goes to flame, so let's focus on topic and mentioned bug?

Hey kraftman, do you know what "criticism" is?

It does not mean "I hate this"

It means "I like this and I want it to be better"

If I hated Linux I would not bother to post.Ok, I didn't saw this, but this thread isn't about criticism. I've got very different feeling from yours, so if you want to continue let's post this in another thread?

I like Solaris and FreeBSD (however, I want them dead, but it's another story and if I have such bug under Linux like mentioned before I can use them instead), but I don't criticize them here :P

frantaylor

08-06-2009, 05:01 PM

Linux is mostly developed by individuals that work for companies doing "server" and "workstation" work with Linux. A bug that affects GUI/Multimedia is quite irrelevant to those people, especially if fixing it would mean performance regressions in servers/workstations. If we consider Linux market share on the server side being over 13% while home desktops being under 2 or 3%, you can guess the priorities of the majority of kernel devs. If Linux would target the Desktop equally, it would never had become so popular on servers.

One of these days real soon now, Microsoft is going to have a major meltdown. Someone will uncover a truly terrible security bug and half of the users on the Internet are gonna get 0wned. For all we know it is already happening with the ActiveX fiasco. It will be a major opportunity for Linux to step up to the plate, but they won't be ready for it. Apple will have a cut-price sale, that big teeter-totter in the sky will flip over to OSX, and Linux will have missed the opportunity. Apple will take over from Microsoft, they will get big and complacent and suck just as bad as Microsoft. Nothing will really change and Linux will still be at 2%. I don't like it but I can't see any other scenario.

frantaylor

08-06-2009, 06:03 PM

I see "2 cores vs. 4 cores" at the top of this page so I assume that is what the thread is.

So I wanna talk about NICs in this context. I want to set up a really bad-ass file server. I have lots of huge files (30 Gb each!) to backup and I hate to wait. I just want to blast them over to my file server ASAP. When I mess them up on my workstation I want to copy them back from the file server ASAP. There will be other users but they have very minor requirements compared to mine. However it would be nice if they get responsive behavior even when I am making my huge copies.

I want to know how many cores to put in my file server and what NICs to use that will work best with that many cores. I've already done my homework on the disk controller and I don't want to talk about that.

I don't even care what OS it runs, just that it has first-class NFS4 service. I would prefer Linux because I know it best. If there is something that works perfect out of the can, that would be best, but I am willing to fiddle around if I have to. I can see from the discussion here that Linux is not a slam-dunk.

Hey kraftman, is this something that you share an interest in? Surely you can tell me if 2 cores is sufficient or if I need 4? And do you know what would be the most stable kernel? I want speed, but data corruption is intolerable.

krazy

08-06-2009, 07:26 PM

@Krazy

Can you describe your problem little more? Do you notice long pauses when copying big file? Is rc5 much better or just little? I have to compile some more things to make X working and to try it :)

The problem with that bug report is that it was so vague that my problem could be completely different to your problem ;)

Anyway, I was having issues with copying to USB flash drive from my SATA HDD. Eg copying 3 ~700-800 MB files would work fine for the first ~1 GB or so and then slow right down to 0 kbps, speeding up for a couple of seconds, then back to 0 for a few more seconds (for the rest of the transfer). This final stage could last for up to 40 mins, and even after it had "finished" copying, the IO wait process would eat up 100% of one CPU core for another 10 mins before I could 'safely remove' the flash drive.

energyman

08-06-2009, 09:14 PM

well, I have a X2 6000+ and I will get a X4 955 on Monday. I compile a lot and that does benefit tremendously.

About the io-problem. There are ways and workarounds. Some people have the problem, some have it and can solve it, some can't. But since almost nobody with the problem ever complains on lkml it will probably never fixed. So if you see this io-hangs, go to lkml. Thank you.

kraftman

08-07-2009, 02:52 AM

The problem with that bug report is that it was so vague that my problem could be completely different to your problem ;)

Anyway, I was having issues with copying to USB flash drive from my SATA HDD. Eg copying 3 ~700-800 MB files would work fine for the first ~1 GB or so and then slow right down to 0 kbps, speeding up for a couple of seconds, then back to 0 for a few more seconds (for the rest of the transfer). This final stage could last for up to 40 mins, and even after it had "finished" copying, the IO wait process would eat up 100% of one CPU core for another 10 mins before I could 'safely remove' the flash drive.

Yes, my problem is different. However, if I remember I saw issue like yours. Can you check: hdparm -Tt /dev/hda [sda]

and post the results?

Maybe you can try this:

http://linux-ata.org/faq.html

"Intel combined mode".

@Frantaylor

I've already done my homework on the disk controller and I don't want to talk about that.It seems you didn't and that's why you don't want to talkt about this. However, another thread can verify this :>.

kraftman

08-07-2009, 03:05 AM

@Frantaylor

I don't even care what OS it runs, just that it has first-class NFS4 service. I would prefer Linux because I know it best. If there is something that works perfect out of the can, that would be best, but I am willing to fiddle around if I have to. I can see from the discussion here that Linux is not a slam-dunk.If you're experiencing similar issue like some of us better don't use Linux it this case.

Hey kraftman, is this something that you share an interest in? Surely you can tell me if 2 cores is sufficient or if I need 4? And do you know what would be the most stable kernel? I want speed, but data corruption is intolerable.I'll recomend 2.6.27, because it's marked as long supported one. If you're going to copy large files XFS should be good (it's known to be good when comes to copying big files, but I never used it too much and I'm not sure if it's as good as some people claim). Maybe better use old Ext3, because it's quite mature, so your data should be safe. When comes to number of cores you should know better, it's your server :)

@Energyman

But since almost nobody with the problem ever complains on lkml it will probably never fixed. So if you see this io-hangs, go to lkml. Thank you.There was at least one report, but as far I remember nothing specific. I have no single idea what my report should look like in this case, becasue it's quite strange thing. There's always a chance they'll replace buggy kernel part.

However, 2.6.31 looks very promising when comes to this issue.

energyman

08-07-2009, 05:27 AM

kraftman

08-07-2009, 09:54 AM

well, describe the symptoms, post the software (kernel, gcc, glbc) versions, hardware, io scheduler used, kernel config. The usual.

I have solved hang ups with:
using cfq
300Hz
reiser4
and this:
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

sure, a big copy still can make other disk accesses a bit slow, but I while I am typing, I am copying a 4.4gb big iso from one partition to another... without hangs.

Thank you. I'll try 'echo 1500 > /proc/sys/vm/dirty_writeback_centisecs', because other options I have the same (except fs, but it shouldn't matter too much). The best result I achieved was to using anticipatory scheduller and maybe some 'echoes', but I don't remember exactly.

However, this seems very interesting and optimistic (or not if someone already tried this kernel):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094/comments/235

energyman

08-08-2009, 01:32 PM

you might also want to play around with
/proc/sys/vm/dirty_background_ratio
/proc/sys/vm/dirty_ratio
and
if you are using raid:
/sys/block/mdX/md/stripe_cache_size
default is 256 which is incredible slow. I had best results with 4096 and 8192.

energyman

08-10-2009, 01:51 PM

so, I got my X4 955 today to replace my X2 6000.

Sooo cool. My box is compiling with -j5 right now, and KDE is a lot more responsive than with two cores and -j3 or 2. Oh - and the cpu is cooler. Same tdp but better powermanagment. I am so glad I did it. 2 cores beat one core. But 4 cores beat 2.

GreekGeek

08-12-2009, 04:31 AM

Hi guys,

I may be able to cast some light onto this?

I had installed Vmware, onto a partition using ntfs-3g and it was DOG SLOW. I had Vmware running fast as, years ago, on a K6-III+. So, I knew I was not dealing with a hardware issue.

So, I copied the Vmware image, onto a XFS partition and I was really back in business.

No I/O issus.

Note previously, frantaylor in post 6, says XFS was fine.

Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.

*HTH*

*BFN*

GreekGeek :-)

toxygen

08-12-2009, 05:19 AM

Hi,
I would go for quad core definitely. It's almost the same jump as from single core to dual core.
Even 1.5ghz dual core is much faster than 2.5 single core in daily usage (except purely single-threaded programs).
Even dual core can't assure you that when one core is 100% you can use the other as nothing was happening. That's because of x86 architecture.
However, when you have 4 cores, your chances of faster interactions/response times are getting better, almost twice.
Definitely quad core, it'll last longer in terms of catching-up to new cpu's.

Hi guys,

I may be able to cast some light onto this?

I had installed Vmware, onto a partition using ntfs-3g and it was DOG SLOW. I had Vmware running fast as, years ago, on a K6-III+. So, I knew I was not dealing with a hardware issue.

So, I copied the Vmware image, onto a XFS partition and I was really back in business.

No I/O issus.

Note previously, frantaylor in post 6, says XFS was fine.

Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.

GreekGeek :-)

Ntfs-3g has dead slow write times.

energyman

08-12-2009, 06:14 AM

now that I have my new quad - go quad. Really, do it. The improvements are easily feelable. Never again will mldonkey make your dual core box sluggish ;)

About ntfs-3g. NTFS is not a bad filesystem, but it really is not the fastest horse in the stable. ntfs-3g is like putting cement shoes around its for legs. So it is not only very slow, if you are unlucky it might break a leg or drown.

kraftman

08-12-2009, 06:32 AM

@GreekGeek

Note previously, kraftman Post 19, said he (?) was using "I copied big file from ntfs partition using ntfs-3g."

Note, the guys that make the free version of the NFFS-3g, also offer a commercial solution, that is .... faster.This is not the case, because when I copy big file on the same Linux' partition the problem remains. However, if it won't be fixed in 2.6.31 I'll probably try XFS. Thanks for your response. There's always possibility some other people aren't affected. Kraftman, she? ;)

GreekGeek

08-16-2009, 03:15 AM

Hi guys,

good call energyman, the horse example about captures the speed of ntfs-3g.

@ Kraftman, thanks for that clarification. :-)

If you Google, you will see find the odd comparison study out there, showing the merrits or otherwise, of different file system types.

GreekGeek :-)