Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Btrfs Is Not Yet the Performance King

timothy posted more than 5 years ago | from the happy-churning dept.

Data Storage 117

Ashmash writes "Benchmarks of the Btrfs filesystem have been published by Phoronix that compare it to the XFS, EXT3, and EXT4 file-systems. In the end they conclude that this next-generation Linux filesystem is not yet the performance king. In a great number of the tests, the EXT4 filesystem that was designed to be an interim step to Btrfs actually performs much better than the unstable Btrfs, albeit Btrfs still has more advanced features. Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."

cancel ×

117 comments

hmm (0, Funny)

Anonymous Coward | more than 5 years ago | (#27776675)

what I want to know is, which filesystem is most helpful for murdering my Russian wife?

Re:hmm (3)

TooMuchToDo (882796) | more than 5 years ago | (#27776733)

Where's the "-1, tired and worn out" mod option?

How is this news? (3, Insightful)

Burkin (1534829) | more than 5 years ago | (#27776909)

What is newsworthy in the fact that a less tested and less stable filesystem is slower than filesystems that are more mature, stable and well-tested?

Re:How is this news? (0)

Anonymous Coward | more than 5 years ago | (#27777459)

Mod parent up. Seriously.

Re:How is this news? (1)

fatp (1171151) | more than 5 years ago | (#27783663)

The newsworthy part is that the less tested and less stable filesystem in beta (or alpha?) can complete the tests.

Stability, reliability (4, Insightful)

Hatta (162192) | more than 5 years ago | (#27776767)

I don't care which filesystem is fastest. Kcryptd is the bottleneck on my system, so it really doesn't matter how fast the filessytem is. I want to know which filesystem is the most robust. What filesystem is least likely to lose data?

Re:Stability, reliability (5, Informative)

Cassini2 (956052) | more than 5 years ago | (#27776853)

btrfs has several features that help prevent data loss, and in particular silent corruption of data on the disk. It is also handy to be able to take snapshots for backup purposes.

Ext3 and Ext4 are faster because they omit some of these features. There was recently some heated debate about ext4 and data loss, see the Slashdot discussion [slashdot.org] for more links.

With file systems, speed and data integrity are trade-offs.

Re:Stability, reliability (2, Insightful)

Anonymous Coward | more than 5 years ago | (#27777309)

With file systems, speed and data integrity are trade-offs.

Not at all. ZFS is a perfect example. Not only is it faster than any Linux file system, but also far more flexible, reliable and far far less likely to lose your data.

Re:Stability, reliability (3, Informative)

TooMuchToDo (882796) | more than 5 years ago | (#27777641)

Unfortunately, Sun had no plans on licensing ZFS so it could run on Linux. Will Oracle change it's mind? Probably not, hence the reason btrfs is reproducing features of ZFS.

Re:Stability, reliability (4, Insightful)

onefriedrice (1171917) | more than 5 years ago | (#27777761)

I think it's important to keep in mind that it is the GPL that is incompatible with other free licenses, not the other way around.

Re:Stability, reliability (0, Troll)

TooMuchToDo (882796) | more than 5 years ago | (#27777919)

And what happens? Someone takes the features they need from a non-GPL program/filesystem/etc and creates a GPL version. Yea, great going there with using an incompatible license. Feel free to use a license incompatible with the GPL. Also feel free to whine when someone replaces the functionality of whatever you've written with a GPL version, which is then included in Linux distros or the kernel where huge amounts of users get access to it.

Re:Stability, reliability (2, Informative)

rackserverdeals (1503561) | more than 5 years ago | (#27779497)

And what happens? Someone takes the features they need from a non-GPL program/filesystem/etc and creates a GPL version. Yea, great going there with using an incompatible license. Feel free to use a license incompatible with the GPL. Also feel free to whine when someone replaces the functionality of whatever you've written with a GPL version, which is then included in Linux distros or the kernel where huge amounts of users get access to it.

How many years has it been since ZFS has been released and we still don't have a workable linux alternative.

I don't think anyone is whining at Sun.

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27782701)

Because no one is using Sun's OS, hence why they were bought out.

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27781845)

Yeah and feel free to whine when your GPL code is attacked in a lawsuit due to patent infringement.

Re:Stability, reliability (0)

LingNoi (1066278) | more than 5 years ago | (#27782711)

You're making the assumption that everyone lives in the US with its messed up patent system. For some of us software patents aren't an issue at all.

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27778625)

I think it's important to keep in mind that it is the GPL that is incompatible with other free licenses, not the other way around.

As it stands, GPL compatible software is the only software that matters when it comes to kernel-linked stuff.

Re:Stability, reliability (4, Insightful)

Nevyn (5505) | more than 5 years ago | (#27778699)

You're right, Sun had no idea their new license would be incompatible with Linux because they wanted to be compatible instead of doing the slimy thing and trying to make it be a selling point over using Linux, which everyone was doing. Alas. for them RMS and Linus travelled back in time and created/used the GPL just to thwart poor Sun.

Re:Stability, reliability (1)

Luke has no name (1423139) | more than 5 years ago | (#27782265)

Slimy thing? It's business. Fucking FSF hippies.

Re:Stability, reliability (1)

ultrabot (200914) | more than 5 years ago | (#27784051)

Slimy thing? It's business. Fucking FSF hippies.

That's not what Sun has been telling us (instead they have been citing technical/legal reasons).

Re:Stability, reliability (1)

Luke has no name (1423139) | more than 5 years ago | (#27784739)

I wish I could cite where I saw this, but I remember reading an article stating that the CDDL was intentionally designed to be GPL incompatible; they didn't want the Linux crowd mooching off their work.

Re:Stability, reliability (1)

ultrabot (200914) | more than 5 years ago | (#27786987)

I wish I could cite where I saw this, but I remember reading an article stating that the CDDL was intentionally designed to be GPL incompatible; they didn't want the Linux crowd mooching off their work.

You probably saw it all over the place - that's the "common wisdom" among everybody but Sun and Sun fanboys.

Re:Stability, reliability (1)

Sentry21 (8183) | more than 5 years ago | (#27784039)

Or, put another way, Sun released ZFS code under an open-source license, and that should be good enough, but the GPL is too focused on rigid adherence to a strict set of rules, and is thus incompatible with many open-source licenses, including Sun's.

How is it that FreeBSD, for example, got Dtrace support included, but Linux can't? Oh, that's right, it's Sun's fault somehow.

Re:Stability, reliability (1)

Ginger Unicorn (952287) | more than 5 years ago | (#27784883)

Sun could have dual licenced ZFS under GPL and BSD. Why didn't they?

Re:Stability, reliability (1)

chrish (4714) | more than 5 years ago | (#27785165)

Why would they? Seems to me like releasing it at all was a huge step for a business; they could've sat on it and kept it to their storage systems as a competitive advantage.

Releasing it under two different licenses just to appease FSF fanatics at least doubles the effort required to review the code and get it released. It probably gives their lawyers high blood pressure, too.

I just can't see how this is Sun's problem and not Linux's problem. Why isn't the kernel flexible enough to allow loading filesystems without being merged into the kernel (or is it? I honestly don't know)?

Re:Stability, reliability (1)

JackieBrown (987087) | more than 5 years ago | (#27781263)

I guess that explains why no non-gpl stuff is on my Debian install.

Oh wait...

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27784969)

I think it's important to keep in mind that it is the GPL that is incompatible with other free licenses, not the other way around.

Other free licenses such as the Sun CDDL, yes? Licenses that were written long after the GPL was, yes? Yeah, clearly the GPL is to blame there.

Let's be honest: we all know that Sun wrote the CDDL and put ZFS etc. under it in order to a) be able to claim they were adhering to FOSS principles, and b) make sure that their competitors (such as Linux) would not be able to benefit from their stuff (e.g. by porting ZFS to Linux, although I'll note that the lack of a flow of code works both ways - Solaris can't incorporate code from Linux, either). And that's certainly entirely fine, too - Sun's entirely free to do that.

But don't go around spreading lies about how this was not a deliberate move on Sun's part or how it's the fault of the GPL that a license that came into being 15 years *after* the GPL intentionally broke compatibility with it (i.e., the GPL).

We're not THAT stupid here.

Re:Stability, reliability (1)

Bert64 (520050) | more than 5 years ago | (#27785391)

I don't see why they really have to compete... Sun sell hardware and support packages, do they really care what you run on their hardware so long as it's sun hardware and comes with a lucrative maintenance contract?

Re:Stability, reliability (1)

asaul (98023) | more than 5 years ago | (#27785863)

No - but you are reading it the way you want - lets go over this again.

Sun wanted to Open Source Solaris because it was the cool thing to do at the time.
However there was non-Sun code which could not be released. Also Sun as a OS provider had vendors who wrote kernel modules for Solaris. According to the interpretations of kernel modules under GPL, putting Solaris or any of Sun's kernel code under the GPL required the rest of the kernel to be GPL - not suitable for other vendors who did not wish to GPL their code. Argue that if you want, but find a corporate lawyer who wont read the GPL conservatively.

So - Sun wrote the CDDL in order to have a license which met their needs and their vendors and partners needs, and then released their code.

So now in the minds of Linux fanbois everywhere, Solaris goes from being a closed evil proprietary operating system trying to kill linux with lockin, to a open source evil operating system trying to undermine Linux by tempting it with code that it cannot integrate.

So - why not dual license Linux if you want the code so bad?

What I find funny is the number of posts that on one hand flog ZFS for being inferior to any Linux filesystem for so many ill informed reasons, then decry it for not being GPL and hence not available in Linux.

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27787001)

I think it's important to keep in mind that it is the GPL that is incompatible with other free licenses, not the other way around.

Obviously, as the owner of ZFS, Sun can open source their product under their license AND the GPL. Your remark is common of the Sun employee's I've spoken with about this: playing innocent doe-in-the-headlight kinda stuff. Anyway, this leads one to conclude: 1) either the licensing boy's at Sun are STUPID, or 2) ZFS is intentionally incompatible with the GPL.

You don't think the employees of Sun are stupid, do you?

C//

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27784511)

Will Oracle change it's mind? Probably not, hence the reason btrfs is reproducing features of ZFS.

Oracle does a lot of the btrfs development. So if they could simplify their work by releasing ZFS under the GPL, they may very well do that.

Re:Stability, reliability (1)

chrish (4714) | more than 5 years ago | (#27785133)

It's so very nice actually using ZFS (on my FreeBSD server) instead of waiting around for the Linux guys to reinvent the wheel with BTRFS.

Dynamically adding storage to your filesystems is a killer feature, although ZFS certainly likes to have a lot of memory handy. I've actually held off on adding a few things to the server (Squid proxy) because I don't want to add more things to memory.

How about changing the way Linux loads filesystems instead of complaining about the flavour of license? Seems to me like it would be faster and less bug-prone that implementing a new filesystem.

Re:Stability, reliability (1)

Bert64 (520050) | more than 5 years ago | (#27785371)

But what plans do Oracle have?
They are working on BTRFS, but will also soon be the owners of ZFS... What's to stop them re-releasing ZFS under compatible terms, or even merging the two filesystems?

Re:Stability, reliability (1)

TooMuchToDo (882796) | more than 5 years ago | (#27786585)

They are working on BTRFS, but will also soon be the owners of ZFS... What's to stop them re-releasing ZFS under compatible terms, or even merging the two filesystems?

Nothing I suppose, although I would prefer something as important as a filesystem be GPL'd just like the kernel, and not tied to any one company.

Re:Stability, reliability (3, Informative)

Anonymous Coward | more than 5 years ago | (#27777779)

Yes, ZFS is a perfect example of a design that's perfect by its own definition of perfect. For (perfect) example, you can perfectly accidentally add an empty USB drive to a pool and you'll be perfectly unable to ever remove that device without doing a perfectly full mirror or backup.

They've been promising to fix this any day now for years. I'll send you $50 when they do. I'll send you another $50 when I can use it on my Linux box.

I think my money's perfectly safe.

Re:Stability, reliability (2, Interesting)

ToasterMonkey (467067) | more than 5 years ago | (#27782561)

I can't figure out the "accidentally" add a USB drive to a local disk pool part. Why would mixing removable with non-removable devices in ANY volume manager ever be a good idea, and why would preventing cases where people "accidentally" do so be a priority? When you plug in a USB disk, does a little dialog ask "Would you like to add this removable disk to a logical volume including fixed disks?" Didn't think so.

I know what feature you're talking about, but this attempt to make it a big deal is pathetic.

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27784509)

Ok, then remove the "accidentally". I have a single enclosure of disks in a data center with limited space. Because of site logistics, that enclosure has to last me essentially forever while my storage needs keep increasing. No problem - I'm planning ahead. I'll always keep one slot free, and as disk capacities grow I'll periodically add a large drive, transfer all of my smallest drive's data to it, and get rid of the smallest drive.

Except I can't do that with ZFS. I can *never* get rid of a drive without having some other identical storage space to dump the whole pool to and then dump it back. ZFS's design philosophy is that I can always add more disks, but I'm space-constrained - I only get the one rack and it's got to be pretty near full all the time otherwise someone else will be assigned the space. And even if I did have the spare space somewhere on some ungodly stack of tapes, I'll have downtime for the entire duration of the restore.

This isn't a pie-in-the-sky feature. It's been in LVM for years, and I can do the expansion without any downtime.

Re:Stability, reliability (1)

asaul (98023) | more than 5 years ago | (#27785965)

I am assuming you have some sort of redundancy in your pool configuration, this being your uber always running data center machine that in no way is using USB disks.

So as you have either RAID-Z or mirrored vdevs, in both cases you an offline one of the devices, replace it with a larger one, then resilver the pool. Once you have replaced the devices in the vdev with larger ones, the pool will automatically resize.

But your point is taken - the ability to remove devices permanently is a basic administration feature which is lacking currently, but the work is underway. From what I understand the model used to do it opens up a number of useful methods for playing with zpools

Re:Stability, reliability (3, Informative)

Anarke_Incarnate (733529) | more than 5 years ago | (#27777897)

I'm glad that you can assume a performance margin without knowing the workload or the application. Please, enlighten us with the performance of ZFS using Oracle or another database...Sure it can be fast, but please, in detail, explain the tunables that need to be set to achieve this performance and what kind of issues you may have with fsync and such, especially when dealing with SAN storage with external battery backed cache..... I am curious..... (and yet know the answers).

Re:Stability, reliability (0)

Anonymous Coward | more than 5 years ago | (#27782703)

Sure it can be fast, but please, in detail, explain the tunables that need to be set to achieve this performance and what kind of issues you may have with fsync and such

I don't know what you're getting at. ALL cooked filesystems need app minded tuning for best performance.. especially on anything with RAID, especially expensive software running on expensive RAID, ie SAN equipment. Even the devices themselves are tuned specifically for certain workloads, RAID 10 for DBs is common, RAID 3 for streaming, and so on.
There's block size, alignment, prefetch settings, log/journal/ZIL options, direct IO, etc. but these apply to any FS where performance is concerned.

BTW,

SAN storage with external battery backed cache

Is there any other kind?

I am curious..... (and yet know the answers).

I have to wonder what you were getting at by asking these questions?

Re:Stability, reliability (1, Funny)

Anonymous Coward | more than 5 years ago | (#27778553)

God I love slashdot! I *literally* pulled that quote out of my ass, and it's already been moderated up to 2, insightful.

Re:Stability, reliability (1, Funny)

Anonymous Coward | more than 5 years ago | (#27778761)

You have a very weird way of storing quotes.

Re:Stability, reliability (1)

SpaceLifeForm (228190) | more than 5 years ago | (#27780593)

Probably desired due to the low latency.

Re:Stability, reliability (1)

Rhinobird (151521) | more than 5 years ago | (#27783491)

You should see how insightful he gets after eating cabbage and beans.

Re:Stability, reliability (1)

k8to (9046) | more than 5 years ago | (#27783077)

Pull the other one. For any application with high transfer rates, the overhead of hashing the data with ZFS is likely to make it quite noticably worse performance-wise than a simpler filesystem like UFS or EXT3. Do some real-world benchmarks.

I've seen cpu-limited apps reach beteen 130% and 200% of their ZFS performance when migrated to UFS.

Better or Butter? (0)

Anonymous Coward | more than 5 years ago | (#27777483)

Does one pronounce Btrfs as "Better FS" or "Butter FS"? I prefer the latter.

Re:Better or Butter? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27777811)

"But her face"

As in, she's so hot...but her face.

Re:Better or Butter? (1)

JackieBrown (987087) | more than 5 years ago | (#27781275)

That's what bags are for

Re:Better or Butter? (1)

nicodoggie (1228876) | more than 5 years ago | (#27777829)

But does it matter? You know everything's better with butter.

Re:Stability, reliability (2, Interesting)

MikeBabcock (65886) | more than 5 years ago | (#27776989)

I'm more interested in a truly distributed file system for making better use of my home LAN full of PCs with those over-sized hard drives that could be being used efficiently.

Several file systems have tried to take advantage of distributed storage, RAID-style, but none are very well maintained or stable or feature-rich for day to day use to my knowledge.

Besides, its a distributed backup system.

Interestingly, it would be easier to store all my data in Freenet [freenetproject.org] and have all my PCs form a darknet with each other.

Re:Stability, reliability (1)

psyclone (187154) | more than 5 years ago | (#27777317)

Interestingly, it would be easier to store all my data in Freenet and have all my PCs form a darknet with each other.

I guess it would be cool to have a darkLAN, but with Freenet, you have to duplicate your data.

It may make more sense to use GlusterFS [gluster.org] or Hadoop [apache.org] for your LAN.

If you want to add crypto, you could store the above data volumes on plain ol EXT(3|4) filesystems inside a TrueCrypt partition.

Re:Stability, reliability (1)

setagllib (753300) | more than 5 years ago | (#27779753)

If you're on Linux anyway, why would you use proprietary TrueCrypt instead of Linux' built-in dm-crypt? Most installers even do it for you now.

Re:Stability, reliability (1)

Znork (31774) | more than 5 years ago | (#27777407)

To solve that problem I moved over centralized storage with diskless clients using iSCSI volumes and booting with PXE. With gigabit it works fine for daily use, it's much simpler to keep track of data and backups and no more wasted disk space in clients.

And, yes, it's very stable.

Re:Stability, reliability (1)

idontgno (624372) | more than 5 years ago | (#27778549)

Hm.... As in, "take all the hard drives out of current machines while preserving their contents someplace, install those drives in a new iSCSI NAS box, build a mondo-RAID out of those disparate hard drives, building zones for each machine's boot volume use, restore the clients' disk images into their individual zones, reconfiguring the clients to PXE boot"?

I'm pretty sure new hardware wasn't in GP's wish list. Hence, the iSCSI NAS box isn't happening. What's your plan B?

I'd be curious if anyone could actually address GP's original requirements, which is a distributed filesystem using spare capacity on existing client systems' current directly-attached JBOD disks.

Re:Stability, reliability (1)

Znork (31774) | more than 5 years ago | (#27786751)

As in, "take all the hard drives out of current machines

Mmm, no. As in quit installing on local disk, bite the bullet and build a SAN and stick decent size disks in one or two linux machines servicing your block device needs. It'd expect the gp'd have at least one or two machines of the current ones that are stable enough to act as servers for the rest.

Disparate sizes of disks isn't a problem as you share out lvm slices, and if you want maintenance ease and redundancy you mirror on the client side of the SAN, not on the server side.

a distributed filesystem using spare capacity

There is none, nor is there likely to be one in the near future. You can accomplish something towards that end with hacks like freenet, or, heck, you could even share the space as block iscsi storage and raid it on other nodes, but the combination of varying client types, varying client uptimes, varying client versions, etc, and any such system will become massively painful to maintain, would be a horror to program for or would have to have massive redundancy to deal with random data going unavailable at any time.

The (stable functional) distributed filesystems there are tend to be written for either large clusters of homogenous clients or are merely designed to redundantly serve from several servers. Neither is a good solution to that particular problem, and trust me, I looked (four years ago, before going with SAN). I haven't seen any major new developments since then. Well, except SSD disks, which, if I just wanted a quick solution, would probably be the way to go to minimize storage waste on new clients today.

Re:Stability, reliability (1)

TheRaven64 (641858) | more than 5 years ago | (#27785023)

Take a look at HAMMER, the new filesystem in DragonFlyBSD. It is designed for distributing load over the hard drives in a cluster, and sounds like exactly what you want.

Re:Stability, reliability (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27777233)

I don't care which filesystem is fastest. Kcryptd is the bottleneck on my system, so it really doesn't matter how fast the filessytem is. I want to know which filesystem is the most robust. What filesystem is least likely to lose data?

ZFS

--AC

Re:Stability, reliability (1)

jabuzz (182671) | more than 5 years ago | (#27777757)

Hum, I would disagree. I personally think that IBM's GPFS is the least likely to lose data. Heck it is the *ONLY* file system I have seen that keeps trucking when loosing a disk making it up. Sure the files on that disk are no longer available but all the rest are.

Re:Stability, reliability (1)

Anarke_Incarnate (733529) | more than 5 years ago | (#27777923)

What happens when that disk goes loose? Do you have to tighten her back up or just ask for a daddy stitch?

Re:Stability, reliability (2, Insightful)

UnknownSoldier (67820) | more than 5 years ago | (#27777355)

There is always a trade off between performance, correctness/robustness, and features.

Pick 2, and don't complain when a 99.99999% guarantee of no data loss is dog slow compared to a filesystem that offers minimal protection against (meta) data loss.

Re:Stability, reliability (1)

ChienAndalu (1293930) | more than 5 years ago | (#27779737)

I thought so too, but I have noticed that deleting files on ext4 is faster than on ext3 on my dm-crypted drive.

Re:Stability, reliability (1)

rvr777 (1082819) | more than 5 years ago | (#27780767)

Yes, for you this may be the case. I also prefer data integrity in most of the cases, but sometimes you need the faster filesystem, because the data is not that important (temporary files), like cache and other data that will quickly be erased. So, like always, it depends on the needs of each environment.

Re:Stability, reliability (1)

Hucko (998827) | more than 5 years ago | (#27780945)

Hmmm...

Ext3 looses data, ext4 loses data. ah god I have to stop focusing on tangents.(I know you used the word correctly, I can't help examining the words 'loose' and 'lose' to the nth degree. Ext3 would be the answer.

Numbers for mysql performance on BTRFS? (3, Insightful)

Smidge207 (1278042) | more than 5 years ago | (#27776925)

Btrfs is mainly created for the Oracle client that doesn't want to use "raw device". It's to improve performance reading/writing large files with high concurrency. So it have to be fast on concurrent request.

What should be looked is :
how mysql perform on BTRFS
how postgres perform on BTRFS
how firebird perform on BTRFS

As there is no magical solution, btrfs is no exception. It's not a general usage FS as is ext (imho). On the desktop, xfs will be the way to go. Performance-wise it's obviously not so great (I do realise that it's still in development and this might change in the future), and the features it delivers are not very interesting as well imho, except maybe for the online defragmentation thingy. But I'm not an enterprise user whis is what this fs aims at I assume.

Still I appreciate the work. Let's hope it doesn't get axed now that Oracle owns Sun and thus already has ZFS.

cheers

=Smidge=

Re:Numbers for mysql performance on BTRFS? (1)

thule (9041) | more than 5 years ago | (#27777231)

Are you sure you are not talking about ocfs2? ocfs2 was designed to run Oracle clusters.

btrfs's stated goal is to eventually replace ext2/3/4.

Re:Numbers for mysql performance on BTRFS? (1)

jabuzz (182671) | more than 5 years ago | (#27777845)

Wrong OCFS was a cluster filesystem that did just enough to run Oracle DB clusters. OCFS2 aims to be a fully fledged cluster filesystem with full Posix schematics.

Re:Numbers for mysql performance on BTRFS? (1)

thule (9041) | more than 5 years ago | (#27780551)

You are correct, I should have left off the '2'

Re:Numbers for mysql performance on BTRFS? (1)

Chirs (87576) | more than 5 years ago | (#27777287)

Btrfs is mainly created for the Oracle client that doesn't want to use "raw device". ...It's not a general usage FS as is ext (imho). On the desktop, xfs will be the way to go.

I'm curious where you're getting this from. It's true that btrfs was originally started for Oracle, but the discussions on the kernel mailing list clearly show that btrfs is intended to be a general purpose filesystem. Ted Ts'o (one of the main ext4 guys) has spoken about btrfs eventually superceding ext4.

Re:Numbers for mysql performance on BTRFS? (1)

RiotingPacifist (1228016) | more than 5 years ago | (#27779455)

Yeah but as always Ted Ts'o has made statements about whats going to happen, before there is any data in there to support these statements.

*if your about to mod me troll/flamebait you clearly don't get it

Re:Numbers for mysql performance on BTRFS? (0)

Anonymous Coward | more than 5 years ago | (#27777435)

If I might guess, even though postgres compares well to oracledb on most benchmarks, oracledb will be far, far faster than postgres on btrfs.

Just, you know, a hunch.

Re:Numbers for mysql performance on BTRFS? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27777535)

imho

I know your posting history. You are anything but humble, so drop the h.

Re:Numbers for mysql performance on BTRFS? (1)

RangerElf (32760) | more than 5 years ago | (#27777565)

...On the desktop, xfs will be the way to go.

Why recommend xfs, when jfs is smaller and faster?

Re:Numbers for mysql performance on BTRFS? (1)

jabuzz (182671) | more than 5 years ago | (#27777815)

Because XFS seems to get more attention from developers. JFS seems to be almost abandonware. For example the DMAPI stuff no longer works, and even IBM don't support that feature of the FS anymore.

Also you can turn XFS into a clustered filesystem if you pay the right money to SGI/Rackable. JFS can't do that.

Put the money where it matters... (1)

mcrbids (148650) | more than 5 years ago | (#27778013)

I host some good-sized databases. (aroung 100 GB when dumped as sql statements) I do this on commodity x64 systems and RHEL/EXT3. Although an F/S swap may boost performance some, I'd almost a guarantee in blood before I'd consider swapping.

Performance is already good/excellent, so the benefit would be minor, while the cost of any corruption would be extreme. I'd be far more likely to upgrade the ECC RAM than do anything to the F/S until a few years of stability have assured me that the change would work out.

Given how fast CHEAP hardware is nowadays, speed takes a distant back seat to reliability nowadays!

What will happen to Btrfs (2, Informative)

rackserverdeals (1503561) | more than 5 years ago | (#27777187)

With Btrfs still being unstable and slow, what is going to happen to it once Oracle completes it's purchase of Sun and gets ZFS and Solaris?

Re:What will happen to Btrfs (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27777763)

According to project leader Chris Mason the development of btrfs will continue:

Just a quick note about the recently announced purchase of Sun by Oracle. This does not change Oracle's plans for Btrfs at all, and Btrfs is still a key project for us. Please, keep your btrfs contributions and testing coming.
http://article.gmane.org/gmane.comp.file-systems.btrfs/2880 [gmane.org]

Re:What will happen to Btrfs (1)

zaibazu (976612) | more than 5 years ago | (#27781439)

On the positive side, a properly implemented ZFS in Linux would be awesome.

Re:What will happen to Btrfs (1)

Xabraxas (654195) | more than 5 years ago | (#27785389)

On the positive side, a properly implemented ZFS in Linux would be awesome.

Good luck getting ZFS into mainline. Even if the source is GPL'd it's not going to be an easy task. It has a lot of the same issues as Reiser4. There is a ton of stuff that Linus doesn't think should be in the filesystem itself but at another layer. There is a better chance that some concepts will make it into the kernel but I doubt the FS ever will.

filesystem config for each case? (1)

Chirs (87576) | more than 5 years ago | (#27777201)

I didn't see any indication of the actual filesystem configuration in each case.

Are the defaults for the two filesystems even equivalent? The test isn't really fair if one of them is providing more ordering guarantees than the other.

format stability (0)

Anonymous Coward | more than 5 years ago | (#27777353)

So far I have resisted moving to butterface because I've read that the on-disk format may change, and I'd have to reformat and copy all my data to and from a backup device. It wasn't a pain I wanted to go through just for that.

So I'm happily on XFS for now - I'm very happy with the large file performance and xfs_fsr is nice to have. Will try butterface at some point in the future if it reaches format stability.

Re:format stability (1)

Dan Ost (415913) | more than 5 years ago | (#27778339)

What's the advantage of XFS over ext3?

Re:format stability (2, Informative)

Anonymous Coward | more than 5 years ago | (#27778541)

> What's the advantage of XFS over ext3?

Well I can only speak for my own experience, and obviously yours may be different. But I've had better luck with XFS stability as well as handling of multi-gigabyte files and directories that contain many files. I was soured early on based on some bad experiences with both ext2 and ext3, went to XFS, and haven't had a problem since.

For me deleting very large files is almost instantaneous on XFS, but drags on and on using ext3. I like XFS on my media server box but also use it on a desktop machine. It's also hugely scalable.

Re:format stability (1)

bzipitidoo (647217) | more than 5 years ago | (#27781541)

Deleting directory trees is horribly slow in XFS. Try untarring the Linux kernel source to an XFS volume, then delete it. Depending on the XFS options, deletion could take longer than untarring. Way faster in Reiserfs (version 3). I had to move away from XFS for that reason. I use reiserfs. A pity that Reiser4 looks to be dead in the water, but I suppose btrfs means to incorporate or supersede much of Reiser4's advances, and more.

ext3 is slower at almost every operation. FAT is one of the few that is worse than ext2/3 across the board, that is, both slower and less reliable. ext3's slowness is partly because ext3 is ext2 with journaling bolted on. Better to use a file system designed from the start for journaling. ext2 isn't great either. No fun being forced to wait 10 minutes for a file system check because the fs has been mounted too many times without a check, or improperly shutdown. And just because fsck gives you the all clear after repairing things from an improper shutdown doesn't mean everything is fine again, you've got to do a proper shutdown.

To sum up, any modern journaling fs > ext3 > FAT.

Re:format stability (1)

macshit (157376) | more than 5 years ago | (#27783243)

Deleting directory trees is horribly slow in XFS.

Yup, one machine I often use is maintained by someone else, and they switched to xfs (from ext3) when rebuilding the system after a big hardware-loss incident. From my perspective, the experience is clearly worse. In particular the whole "deleting lots of little files" thing (which I seem to do quite often) -- in ext3 I never noticed any delay, but xfs seems to take forever to do the same operation.

I get the impression that xfs was designed with a particual usage in mind -- big media servers, IIRC -- and shines there, but is maybe not the best choice for a general-purpose machine.

Re:format stability (4, Informative)

pigeon768 (589860) | more than 5 years ago | (#27778785)

Extents and delayed allocation are the big ones, both of which are available in ext4, reiser4, and btrfs.

Unfortunately, xfs is more likely to eat data in individual files than ext3 or ext4 w/ data=ordered. It's apparently less likely to end up with an uncorrectable superblock.

xfs is also horrifically slow for random access of smaller files. If your application calls for massive files, such as databases or a porn library, xfs is preferable over reiserfs or ext3, comparable to ext4, but for general use you're better off with ext3/4 or reiserfs. (by reiserfs I mean 3.6, not reiser4. I can't speak for reiser4)

It's important to remember that there is no one fs to rule them all. Any time anyone tells you "*fs is the best filesystem" they're suffering from fanboyism. xfs is probably not the ideal filesystem for / on a desktop system, but it's a great filesystem for a partition on a server running a database or a fileserver serving large files, or for a DVR application like mythtv.

Re:format stability (1)

Xabraxas (654195) | more than 5 years ago | (#27782209)

XFS can be tuned for greater performance with options at creation time and mount time. I loved Reiser3's performance but there are too many missing features. I switched to XFS about 2 years ago and haven't looked back since. Small files are still slower to delete but after tuning the system it isn't really that bad at all.

Re:format stability (1)

AaronW (33736) | more than 5 years ago | (#27779215)

XFS has a number of features that ext3 is missing. For example, one can easily defragment a mounted XFS filesystem. It's also much more resistant to fragmentation due to the late allocation strategy. xfsdump allows one to easily back up the filesystem and all of the metadata, including incremental backup support. I've used this to replicate an xfs filesystem via netcat when migrating to a new server.

A mounted XFS volume can also be increased on the fly.

XFS is able to scale to much larger partition sizes than ext2/3 (which maxes out at around 8TB with 4K blocks). fsck runs much faster as well. I go and take a coffee break when ext3 decides its time to run its periodic fsck run. ext3 also supports a maximum file size of 2TB and has a limit of around 32K subdirectories per directory. XFS does not have these limitations.

several useless metrics (2, Insightful)

Khashishi (775369) | more than 5 years ago | (#27777425)

not sure why phoronix decided to include several test cases which are clearly bottlenecked by something other than the filesystem. Obviously, all 4 filesystems are gonna score the same.

Re:several useless metrics (2, Insightful)

vondo (303621) | more than 5 years ago | (#27777615)

Because Phoronix does really crappy pointless benchmarks all the time. Occasionally they sucker me into reading them and I always wish I hadn't

Re:several useless metrics (0)

Anonymous Coward | more than 5 years ago | (#27781383)

not sure why phoronix decided to include several test cases which are clearly bottlenecked by something other than the filesystem. Obviously, all 4 filesystems are gonna score the same.

Because "Phoronix" is incorrectly spelled.

The correct spelling is "Moronix".

As in "bunch of morons who don't know what they're doing playing with computers".

try again (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27777441)

with linus ranting against ext4 i expected to find 'ordered' (mount option to make ext4 acceptable) in the f****** article at least once, but didn't.
so, please guys: do yourself a favour and do the benchmark again! benchmarking ram against platters ain't fair!

ZFS? (2, Insightful)

javacowboy (222023) | more than 5 years ago | (#27777491)

I didn't RTFA but why no mention of ZFS?

Re:ZFS? (0)

Anonymous Coward | more than 5 years ago | (#27777833)

ZFS is only available in Linux as a user-space filesystem using FUSE due to the GPL not being compatible with the CDDL used for ZFS.

Re:ZFS? (2, Insightful)

pigeon768 (589860) | more than 5 years ago | (#27779007)

The short version is that ZFS isn't available for linux, and this is a linux FS benchmark on a linux specific site.

You could run the same benchmark on OpenSolaris vs Linux on the same hardware, but this wouldn't be particularly meaningful: different storage stack, vfs, etc. Even if the benchmark convinced someone that ZFS is better, they couldn't switch to it, because again, there is no linux port.

You could benchmark the userspace ZFS on Fuse driver, but this is meaningless because the Fuse ZFS implementation is useless (slow + unstable) and everyone knows it.

Re:ZFS? (1)

Slashcrap (869349) | more than 5 years ago | (#27784381)

I didn't RTFA but why no mention of ZFS?

Name: Mentions Java
Signature: Mentions Macs
Comment: Mentions ZFS for no reason.

Congratulations! You have acheived the full trifecta of Slashdot faggotry!

Boot Performance is Critical? (0)

Anonymous Coward | more than 5 years ago | (#27777809)

Fedora 11 even took longer to boot when using Btrfs than EXT3 or EXT4."

Performance testing is a huge part of my job. File system performance is a critical part of many performance tests.

In 20 years of performance testing, I have never measured or reported on "boot performance". After all, who among us reboots more than once every 6 or 7 months?

Re:Boot Performance is Critical? (0)

Anonymous Coward | more than 5 years ago | (#27780519)

uh people who don't run enterprise linux? people who power down their machines when not using them to save on utilities?

ReiserFS all the way! (1, Funny)

hansede (1521535) | more than 5 years ago | (#27777827)

Now all of my apps are killer apps!

No large file unlink() benchmarks? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27778957)

You want to see EXT3 choke and gobble tons of CPU?

Try creating a bunch of 8-20GB files then unlink (rm) the files.

You'll be amazed to see unlink() on EXT3 use 100% CPU usage for 8-20 seconds PER FILE with all of the other processes starved while EXT3 bogs. Any live data collection in other processes will be stalled until unlink() finishes.

XFS, without a real-time volume, does a fine job of large file deletion without bogging the CPU or starving the live data collection processes.

It's too bad Phoronix didn't bother with benchmarking that scenario.

xfs? (1)

John Meacham (1112) | more than 5 years ago | (#27784389)

All these results just make me wonder why we arn't all using 'xfs' by default nowadays?

ReiserV4 vs BTRFS (0)

Anonymous Coward | more than 5 years ago | (#27785283)

Would be nice to have a Benchmark between the KillerFS(ReiserV4) and BTRFS!

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...