[opensuse] Fwd: observed significant performance improvement in XFS a real-world application
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. It continually bests other file systems in optimized configuration performance tests and these new improvements sound like they only add more speed to the equation. For nearly all systems, disk speed is the bottle neck, so using the best solution possible should be strongly considered the default choice for all users -- regardless of 'political' concerns (which seem to often over-rule practicality, unfortunately). Linda p.s. I am not part of the xfs project. I've just used it with open suse (or previously, Suse) since ~ 2002 and have never regretted it. Current filesystem read rates using XFS are about 1GB/second on sustained multi-gigabyte reads. Using 1Gbit ethernet, Samba gets 97MB/s read from disk to 115 MB/s read from memory and 125MB/s writes to memory or disk. -------- Original Message -------- Subject: observed significant performance improvement using "delaylog" in a real-world application Date: Tue, 10 Aug 2010 18:01:33 +0200 From: Peter Niemayer <niemayer@isg.de> To: linux-xfs@oss.sgi.com Hi all, we use XFS for a very I/O-intensive, in-house developed real-time database application, and whenever we see new or significantly changed file-systems becoming available, we run a benchmark using this application on a conserved, fixed real-world data set. I'm pleased to state that using the experimental "delaylog" mount option (in vanilla linux-2.6.35) we measured a 17% performance increase for our benchmark scenario. (Other mount-options in use both before and after the "delaylog" option: noatime,nodiratime,nobarrier) That's a lot given that XFS was the fastest performing file-system for this application already. It's also a promising result regarding stability, as several other tests (using e.g. reiser4 or ceph) in the past led to crashes in the same benchmark scenario. So thanks to all contributing developers for this significant optimization! Regards, Peter Niemayer _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh <suse@tlinx.org> wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
Linda, In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns. Since desktops/laptops tend to have these much more than servers, I would not have wanted it to be the default at all during those times. Has its' resiliency greatly increased? If not, I don't think it is a good choice for the openSUSE default fs. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Unfortunately, my machines have been run through through the ringer, going for prolonged periods of time of having problems, including unclean shutdowns (too many things on plate to address issues that only happened at shutdown, with uptimes often measured in months. The only non-user-error dataloss I've ever experienced has been attributable to 2 areas, neither was XFS. 1st was software raid under 11.1: 2/4 volumes unreadable after an unclean shutdown (fortunately it was a backup volume). and 2nd area was during use of the LSM volume manager -- most recently under 11.2 when I upgraded the kernel and volume snaps broke. I did have a data corruption issue involving XFS with some volume snaps that went bad under 11.2, but they haven't been reproducible on non-LFM volumes nor on volumes where volume snaps had not become full (and self-corrupt). I've been using xfs since the early 2.4 timeframe and was lucky enough to have a stable system then, on a UPS, so that may have prevented some of the issues you are referring to, but UPS, hasn't saved my system stability since upgrading to SuSE 11.0, when stability took a downturn. However, in that time frame, even with instability, XFS hasn't caused any noticeable problems, but honestly, in the 8 years of use, if it had, I also keep daily backups of all data + metadata using xfsdump/restore, and have only had to resort to them for the problems mentioned above and cockpit error. Greg Freemyer wrote:
On Sat, Aug 14, 2010 at 7:45 PM, Linda Walsh <suse@tlinx.org> wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
Linda,
In the past (2.4.x kernel) XFS had significant data loss issues in the presence of unexpected shutdowns.
Since desktops/laptops tend to have these much more than servers, I would not have wanted it to be the default at all during those times.
Has its' resiliency greatly increased? If not, I don't think it is a good choice for the openSUSE default fs.
Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-15 03:57, Linda Walsh wrote:
Unfortunately, my machines have been run through through the ringer, going for prolonged periods of time of having problems, including unclean shutdowns (too many things on plate to address issues that only happened at shutdown, with uptimes often measured in months.
The only non-user-error dataloss I've ever experienced has been attributable to 2 areas, neither was XFS.
The data loss problem that Greg refers to is quite specific, the cause is known. It is a problem with any modern filesystem with a journal and optimized structures held in memory for speed. When the system is writing to disk, things may not get actually written at than moment; the actual write can be delayed. There is a classic example of how a file been edited is saved. Let me see if I remember it right: the in memory version of the file is saved as file.new the current file.bak is deleted the current file.txt is renamed to file.bak and file.new is renamed as file.txt The idea is that you will not be in danger of losing the file if the computer crashes during the operation. You could even rename the old file.bak as "file.bak;1" for extra security. However, there is no actual guarantee that the disk operations are really committed in that order, or at all. In fact, you may end with a partially written file.new, no file.bak, and a deleted file.txt. What programmers want (again, if I recall correctly) is a way of ensuring that one operation happens only after the previous one has been committed to disk (and only when they specify this type of working). What the kernel chaps propose is that they use the existing "flush"; it seems that the other type of operation is not contemplated in the standards. The big snag is that "flush" flushes everything to disk, not only the operation we are interested in, and thus, negating the efficiency of the memory buffers and all the structures that speed the filesystem. Ie, all disk new operations halt till all the pending operations are really written to disk, slowing performance notabily. There is a nice, extensive write up where this is explained very nicely, posted here a year ago or so, but I don't have the link handy. Maybe someone remembers. And XFS is affected by this more than others, as it uses memory structures more than others. A power off at a very bad moment can cause data loss. There maybe other scenarios than the one I described above, but this is the one they referred to, IIRC. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
El 14/08/10 19:45, Linda Walsh escribió:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
Unlikely, my best bet on the next default filesystem is : BRTFS ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-15 01:45, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
I use XFS, but it has issues when used for the root (/) filesystem, it is incompatible with grub in the same partition (there are bugzillas for this, solution: known issue non solvable). So, grub has to go to the mbr or you need an extra /boot partition. Therefore, the ext3/4 family is a better choice as default filesystem, because it works on all scenarios. Those that know or have different needs, can and do use xfs. I use xfs and reiserfs. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
Carlos E. R. wrote:
On 2010-08-15 01:45, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
I use XFS, but it has issues when used for the root (/) filesystem, it is incompatible with grub in the same partition (there are bugzillas for this, solution: known issue non solvable). So, grub has to go to the mbr or you need an extra /boot partition. Therefore, the ext3/4 family is a better choice as default filesystem, because it works on all scenarios.
Those that know or have different needs, can and do use xfs. I use xfs and reiserfs.
I have been on reiserfs since, almost, the beginning and - love it - it takes a beating and keep on ticking. Before I bought, out of necessity, a UPS, we keep getting brown-outs, spikes and complete power failures, and reiserfs has never failed - me. Now, I'm not the most speed observing person however when I was very very low on space, it was the - best - option to get the best use of space (even with major tweaking on the others filesystems). To bad - it's not - continuing being developed. Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ Tuning, Servicing & Rebuilding Reed Organ Society Member Florissant, MO 63034 (314) 838-5587 dahechler@att.net www.hechlerpianoandorgan.com -- Home & Business user of Linux - 10 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-15 03:59, Duaine Hechler wrote:
Carlos E. R. wrote:
Those that know or have different needs, can and do use xfs. I use xfs and reiserfs.
I have been on reiserfs since, almost, the beginning and - love it - it takes a beating and keep on ticking.
Before I bought, out of necessity, a UPS, we keep getting brown-outs, spikes and complete power failures, and reiserfs has never failed - me.
Now, I'm not the most speed observing person however when I was very very low on space, it was the - best - option to get the best use of space (even with major tweaking on the others filesystems).
To bad - it's not - continuing being developed.
Yes, it is too bad. It is very efficient for use, for example, on a partition holding maildir structures. Or one in which you run compilations. -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
On 8/15/2010 7:21 AM, Carlos E. R. wrote:
On 2010-08-15 03:59, Duaine Hechler wrote:
Carlos E. R. wrote:
Those that know or have different needs, can and do use xfs. I use xfs and reiserfs.
I have been on reiserfs since, almost, the beginning and - love it - it takes a beating and keep on ticking.
Before I bought, out of necessity, a UPS, we keep getting brown-outs, spikes and complete power failures, and reiserfs has never failed - me.
Now, I'm not the most speed observing person however when I was very very low on space, it was the - best - option to get the best use of space (even with major tweaking on the others filesystems).
To bad - it's not - continuing being developed.
Yes, it is too bad.
It is very efficient for use, for example, on a partition holding maildir structures. Or one in which you run compilations.
This sort of thing keeps coming up: KDE3.x, reiserfs, etc. If something works, why does it have to be continuously "developed?" I used resierfs from the time it was first added to SuSE until it was no longer a choice in the install, and never had any problems with it, and the last version of KDE3.x was a nice desktop environment and the developers "developed" it into something many feel is gross, unintuitive, clumsy. And yes, now I _have_ tried SuSE's version of KDE 4.x on the 11.3 live install, and I don't like it. Some 30 years ago, or so, Xerox invented the windows-type system, and it has been working pretty well for Win 95, 98, 2000, OS2, XP, Mac, even (mostly) Win7, KDE 3.x. Well, Mac had it's peculiarities, I grant, altho I'm told by a using friend that they're mostly gone. Don't get me wrong: I know there are people out there who seem to like KDE4.4.x. I don't disparage them. But the choice should remain with the _user_, not be forced on him. I expect to look into some of the other DE's within the next little while, and perhaps lxde, or even Gnome may be more desirable _to me_. It would help, I suppose, if SuSE and the other distros made more choices available during the install; SuSE is the only one I know of that even allows two choices. (I believe that 11.2 offered three: two KDE's and Gnome, but I bypassed that version.) It seems that developers are the same all over: look at Vista! But somebody upstairs at M/S told them to stop fooling around and do something usable for a change. Well, "7" is not as nice as XP, as far as many are concerned, but it is somewhat an improvement, even tho certain programs became broken or uninstallable. We need somebody upstairs--that's _us_, I believe--to tell the devels to stop fooling around, and that's what a lot of folks on this list have been doing! Or trying to! Just my $.02. --doug -- Blessed are the peacemakers...for they shall be shot at from both sides. --A.M. Greeley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Doug wrote:
On 8/15/2010 7:21 AM, Carlos E. R. wrote:
On 2010-08-15 03:59, Duaine Hechler wrote:
Carlos E. R. wrote:
Those that know or have different needs, can and do use xfs. I use xfs and reiserfs.
I have been on reiserfs since, almost, the beginning and - love it - it takes a beating and keep on ticking.
Before I bought, out of necessity, a UPS, we keep getting brown-outs, spikes and complete power failures, and reiserfs has never failed - me.
Now, I'm not the most speed observing person however when I was very very low on space, it was the - best - option to get the best use of space (even with major tweaking on the others filesystems).
To bad - it's not - continuing being developed.
Yes, it is too bad.
It is very efficient for use, for example, on a partition holding maildir structures. Or one in which you run compilations.
This sort of thing keeps coming up: KDE3.x, reiserfs, etc. If something works, why does it have to be continuously "developed?" I used resierfs from the time it was first added to SuSE until it was no longer a choice in the install, and never had any problems with it, and the last version of KDE3.x was a nice desktop environment and the developers "developed" it into something many feel is gross, unintuitive, clumsy. And yes, now I _have_ tried SuSE's version of KDE 4.x on the 11.3 live install, and I don't like it. Some 30 years ago, or so, Xerox invented the windows-type system, and it has been working pretty well for Win 95, 98, 2000, OS2, XP, Mac, even (mostly) Win7, KDE 3.x. Well, Mac had it's peculiarities, I grant, altho I'm told by a using friend that they're mostly gone.
Don't get me wrong: I know there are people out there who seem to like KDE4.4.x. I don't disparage them. But the choice should remain with the _user_, not be forced on him. I expect to look into some of the other DE's within the next little while, and perhaps lxde, or even Gnome may be more desirable _to me_. It would help, I suppose, if SuSE and the other distros made more choices available during the install; SuSE is the only one I know of that even allows two choices. (I believe that 11.2 offered three: two KDE's and Gnome, but I bypassed that version.)
It seems that developers are the same all over: look at Vista! But somebody upstairs at M/S told them to stop fooling around and do something usable for a change. Well, "7" is not as nice as XP, as far as many are concerned, but it is somewhat an improvement, even tho certain programs became broken or uninstallable. We need somebody upstairs--that's _us_, I believe--to tell the devels to stop fooling around, and that's what a lot of folks on this list have been doing! Or trying to!
Just my $.02. --doug
AMEN - Couldn't have said it any better myself ! Duaine P.S. Whatever version reiserfs is on now has done good so far - maybe the developers just need to - maintain - the current version. And keep it as a viable option in openSUSE. -- Duaine Hechler Piano, Player Piano, Pump Organ Tuning, Servicing & Rebuilding Reed Organ Society Member Florissant, MO 63034 (314) 838-5587 dahechler@att.net www.hechlerpianoandorgan.com -- Home & Business user of Linux - 10 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-15 22:10, Duaine Hechler wrote:
P.S. Whatever version reiserfs is on now has done good so far - maybe the developers just need to - maintain - the current version. And keep it as a viable option in openSUSE.
Reiserfs is being currently maintained and you can use it. I do. What is not known is for how long they will keep it - probably as long as the maintenance period of SLEx 9 (or 10?) requires it. The demise of reiserfs is not political, but neither it is technical, IMO. It is human, or business. The project was pushed by one brilliant developer. He disappeared - no need to say why. Without his push, the project, which apparently doesn't get much community support, languishes. Why doesn't it have more support? I don't know. Perhaps because it is very difficult to understand, technically. The current version of reiserfs was integrated in the kernel. At the time, the people that designed it left it to the kernel and moved on design the new version, #4. They considered that it was the responsibility of the kernel people to maintain it. IMO, they barely do so. IIRC, there were two devs on SuSE that did the maintenance. One left, so now there is only one. Reiserfs has currently some problems. It needs improving, it doesn't scale well as sizes increase and increase, for example (only one thread per system, or something of the sort). Other filesystems are currently being improved. Reiserfs is frozen. IMO, in our FOSS world, there is no guarantee that a piece of software we, as users, love, will be mantained for ever, even if we want it. We depend on developers keeping their interest, which can be different than ours. This is human. They may design some thing, then have a new bright idea, and go for it abandoning their previous pet. Worse if it's somebody else's pet, which is the case (IMO). We are users, not customers. We have little influence in what they do, because as they develop in their free time, it is their choice, not ours. Some maybe fortunate to be paid for developing, in which case I suppose they are more or less told what to do. So, yes, we can say that we want reiserfs. So what? We are nobody. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxob40ACgkQU92UU+smfQVKVACbBdYQq1XTBp0SSXOqXGY8greC 04wAmgN02RFVIe6kf5O5VNIAZoog70ws =GXod -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 16 Aug 2010 00:51:57 +0200, "Carlos E. R." <carlos.e.r@opensuse.org> wrote:
They considered that it was the responsibility of the kernel people to maintain it. IMO, they barely do so.
Kernelk people don't maintain a driver. They do make shure it matches changing APIs but for real maintenance it still needs dedicated developers . For reiserfs that was Chris Mason, now working for Oracle. He became fed up with fixing old code instead of developing new one so he started btrfs.
IIRC, there were two devs on SuSE that did the maintenance.
And one of them was Chris. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-08-17 11:03, Philipp Thomas wrote:
On Mon, 16 Aug 2010 00:51:57 +0200, "Carlos E. R." <> wrote:
They considered that it was the responsibility of the kernel people to maintain it. IMO, they barely do so.
Kernelk people don't maintain a driver. They do make shure it matches changing APIs but for real maintenance it still needs dedicated developers .
Ah, Well, then there is/was a mismatch between what the folks at (I forgot the name...) nemesis? No, Namesys thought and the kernel people thought was their respective responsibilities
For reiserfs that was Chris Mason, now working for Oracle. He became fed up with fixing old code instead of developing new one so he started btrfs.
Yes, this is normal.
IIRC, there were two devs on SuSE that did the maintenance.
And one of them was Chris.
Yes. Code needs maintenance. Programmers like new pastures (I know, I have been a programmer), but as a user I'd rather prefer old code being maintained that more and more new code being created. What I wonder now if is if btrfs has inherited any of reiserfs characteristics - like that of allowing millions of small files with very little wasted space, knowing that it inherited a programmer ;-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqdsMACgkQU92UU+smfQWi5gCgio9mHToiZuhTazvWl4XbBMB7 Wo0AniQdhN4QhrUNYg3LUmPMc3pK5lWg =9oGR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2010-08-15 at 15:00 -0400, Doug wrote:
On 8/15/2010 7:21 AM, Carlos E. R. wrote:
On 2010-08-15 03:59, Duaine Hechler wrote: It is very efficient for use, for example, on a partition holding maildir structures. Or one in which you run compilations. This sort of thing keeps coming up: KDE3.x, reiserfs, etc. If something works, why does it have to be continuously "developed?"
In order to continue working; software will not 'just keep working'. Subsystems and dependencies change and the layer over them must adapt and evolve. This is one form of bitrot [which is very real]. <http://en.wikipedia.org/wiki/Software_rot> Unmaintained software will have no one around who can fix it when that happens. It is better to migrate in an intentional manner to new [maintained] software than to collide with an unanticipated breakage.
upstairs--that's _us_, I believe--to tell the devels to stop fooling around, and that's what a lot of folks on this list have been doing! Or trying to!
s/lot/few/g -- Adam Tauno Williams <awilliam@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2010-08-16 12:38, Adam Tauno Williams wrote:
On Sun, 2010-08-15 at 15:00 -0400, Doug wrote:
This sort of thing keeps coming up: KDE3.x, reiserfs, etc. If something works, why does it have to be continuously "developed?"
In order to continue working; software will not 'just keep working'. Subsystems and dependencies change and the layer over them must adapt and evolve. This is one form of bitrot [which is very real]. <http://en.wikipedia.org/wiki/Software_rot> Unmaintained software will have no one around who can fix it when that happens. It is better to migrate in an intentional manner to new [maintained] software than to collide with an unanticipated breakage.
IMO, this is wrong. I mean, the solution used is probably the only feasible solution, but it is the incorrect one. It is like keeping the city landscape. At some time, they make a nice street, with gardens, pavement, lamps, the lot. Years pass. They neglect to hire gardeners, electricians, brick layerers. With time, the grass disappears, trees rot, pavement develops potholes and bumps, lamps do not work. Comes a new mayor. The street is put out of commission for a season, it is dismantled and rebuilt again with different trees in different places, new lamps in different places, even the places where cars and pedestrian go are interchanged - instead of having maintained it when it was due. What a good mayor we have! -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar))
El 15/08/10 15:00, Doug escribió:
This sort of thing keeps coming up: KDE3.x, reiserfs, etc. If something works, why does it have to be continuously "developed?"
Software development is just like life itself, based on your previous experiences, you take lessons and move on to the future...
We need somebody upstairs
No, thanks , there are a lot of them for now ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 8/14/2010 9:59 PM, Duaine Hechler wrote:
Carlos E. R. wrote:
On 2010-08-15 01:45, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice.
I use XFS, but it has issues when used for the root (/) filesystem, it is incompatible with grub in the same partition (there are bugzillas for this, solution: known issue non solvable). So, grub has to go to the mbr or you need an extra /boot partition. Therefore, the ext3/4 family is a better choice as default filesystem, because it works on all scenarios.
Those that know or have different needs, can and do use xfs. I use xfs and reiserfs.
I have been on reiserfs since, almost, the beginning and - love it - it takes a beating and keep on ticking.
Before I bought, out of necessity, a UPS, we keep getting brown-outs, spikes and complete power failures, and reiserfs has never failed - me.
Now, I'm not the most speed observing person however when I was very very low on space, it was the - best - option to get the best use of space (even with major tweaking on the others filesystems).
To bad - it's not - continuing being developed.
Nothing beats reiser3 yet for all-around performance and reliability. All our application servers have been reiser3 for the last 6 years and no problems. Just for comparison I have allowed a couple boxes here & there to be the default ext3 which everything else is the same as other boxes, hardware/OS/workload, and the ext3 boxes are dogs in comparison. They are ok, you wouldn't know they were slow except in comparison. They are insanely faster than HTFS from SCO Open Server on the same hardware for instance. But Reiser3 is even faster and with no reliability penalty so it's a no-brainer. xfs is good for what it's good for, which is actually a pretty limited set of circumstances. It would be a terrible general default. Reiser4 and ext4 I would not put my customers data on yet. Maybe one or the other is safe by now, maybe not. Probably ext4 is safe enough by now but Reiser3 still outperforms it anyways so who cares? Reiser4 is definitely still too wobbly-legged. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Brian K. White said the following on 08/16/2010 11:24 AM:
Nothing beats reiser3 yet for all-around performance and reliability.
+1
Reiser4 and ext4 I would not put my customers data on yet. Maybe one or the other is safe by now, maybe not. Probably ext4 is safe enough by now but Reiser3 still outperforms it anyways so who cares? Reiser4 is definitely still too wobbly-legged.
By that time, the ex-Reiser guy working on Btrs will have made that a serious contender. I'm running Btrfs on or mail hubs and so far I'm impressed with it. A future project due to start will be using it with SSD. -- The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten. --Kathleen Byle, Sandia National Laboratories -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 14 Aug 2010 16:45:39 -0700, Linda Walsh <suse@tlinx.org> wrote:
in hoping that decision-makers will consider XFS as the default suse OS install choice.
The most likely candidate is btrfs. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Philipp Thomas said the following on 08/15/2010 06:55 AM:
On Sat, 14 Aug 2010 16:45:39 -0700, Linda Walsh <suse@tlinx.org> wrote:
in hoping that decision-makers will consider XFS as the default suse OS install choice.
The most likely candidate is btrfs.
+1 -- A seminar on time-travel will be held two weeks ago. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 2010-08-14 at 16:45 -0700, Linda Walsh wrote:
Forward this from the linux-xfs list, in hoping that decision-makers will consider XFS as the default suse OS install choice. It continually bests other file systems in optimized configuration performance tests and these new improvements sound like they only add more speed to the equation.
You subject states "real-world application" but the attached message states "our benchmark scenario". There is no reason to believe their performance increases translate to the general case; and " very I/O-intensive, in-house developed real-time database application" certainly doesn't equate to the general laptop/workstation. I've been a UNIX/LINUX sys-admin for ~15 years; and a previous XFS proponent [and user]. However XFS faces several challenges: (1) The toolset is [or was, maybe it has improved] pretty crappy. The fsck for XFS was essentially just a no-op. In my experience xfs_check & xfs_repair were essentially useless. (2) Much of the performance benefit has diminished. Today's ext3 is not the ext3 of five-to-?? years ago. And most systems use ext4. I've no doubt XFS has improved as well. But in our application(s) I saw the difference between ext3 and XFS diminish over time as ext3 got faster [especially with the introduction of dir_index, which solved a *killer* ext3 performance issue]. The performance difference needs to be enough to make it worth being out of the main-stream [which is ext3/4; and *no* that is not a "political" consideration, it is a technical and support decision. There are lots of people who know lots about and have lots of experience with ext3/4; which is much less true of other file-systems.] The comment for "delaylog" is the following: <quote source="http://kernelnewbies.org/LinuxChanges#head-cb8e94576caa7c117ad3b6edc32686b8cc49a1ce"> 1.3. XFS Delayed logging This version adds a logging (journaling) mode called delayed logging, which is very briefly modeled after the journaling mode in the ext3/4 and reiserfs filesystems. It allows to accumulated multiple asynchronous transactions in memory instead of possibly writing them out many times. The I/O bandwidth used for the log decreases by orders of magnitude and performance on metadata intensive workloads increases massively. The log disk format is not changed, only the in-memory data structures and code. This feature is experimental, so it's not recommended for final users or production servers. Those who want to test it can enable it with the "-o delaylog" mount option. <quote> NOTE: "This feature is experimental, so it's not recommended for final users or production servers." Also note this behavior mimics that used by ext3/4.
For nearly all systems, disk speed is the bottle neck, so using the best solution possible should be strongly considered the default choice for all users -- regardless of 'political' concerns (which seem to often over-rule practicality, unfortunately).
I don't understand this point; I rarely see FOSS tainted by political concerns regarding technical decisions. That is usually an argument thrown out by the loosing side of the technical debate.
p.s. I am not part of the xfs project. I've just used it with open suse (or previously, Suse) since ~ 2002 and have never regretted it. Current filesystem read rates using XFS are about 1GB/second on sustained multi-gigabyte reads. Using 1Gbit ethernet, Samba gets 97MB/s read from disk to 115 MB/s read from memory and 125MB/s writes to memory or disk. -------- Original Message -------- Subject: observed significant performance improvement using "delaylog" in a real-world application Date: Tue, 10 Aug 2010 18:01:33 +0200 From: Peter Niemayer <niemayer@isg.de> To: linux-xfs@oss.sgi.com Hi all, we use XFS for a very I/O-intensive, in-house developed real-time database application, and whenever we see new or significantly changed file-systems becoming available, we run a benchmark using this application on a conserved, fixed real-world data set. I'm pleased to state that using the experimental "delaylog" mount option (in vanilla linux-2.6.35) we measured a 17% performance increase for our benchmark scenario. (Other mount-options in use both before and after the "delaylog" option: noatime,nodiratime,nobarrier) That's a lot given that XFS was the fastest performing file-system for this application already. It's also a promising result regarding stability, as several other tests (using e.g. reiser4 or ceph) in the past led to crashes in the same benchmark scenario. So thanks to all contributing developers for this significant optimization! Regards, Peter Niemayer -- Adam Tauno Williams <awilliam@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (11)
-
Adam Tauno Williams -
Anton Aylward -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Doug -
Duaine Hechler -
Greg Freemyer -
Linda Walsh -
Philipp Thomas