Btrfs Is Not Yet the Performance King 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."
Re:hmm (Score:4)
Re: (Score:1)
How is this news? (Score:4, Insightful)
Re: (Score:1)
Stability, reliability (Score:5, Insightful)
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 (Score:5, Informative)
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: (Score:2, Insightful)
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 (Score:4, Informative)
Re:Stability, reliability (Score:4, Insightful)
Re: (Score:1, Troll)
Re: (Score:3, Informative)
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 (Score:5, Insightful)
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: (Score:1)
Slimy thing? It's business. Fucking FSF hippies.
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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 filesyste
Re: (Score:2)
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)?
You can fun a file system in userspace, it's just quite a bit slower that way. I believe you can run ZFS on Linux with Fuse.
For what it's worth, you can legally run ZFS as a kernel module without violating either license, you just can't distribute it that way because the GPL would require that the ZFS code be distributed under a compatible license.
Re: (Score:2)
Re: (Score:2)
I guess that explains why no non-gpl stuff is on my Debian install.
Oh wait...
Re: (Score:2)
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: (Score:1)
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 th
Re: (Score:2)
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.
Since Sun has copyright on the Solaris kernel, they could have released it under the GPL while simultaneously licensing it under whatever other licensing agreement they had with other vendors.
If you license your code under the GPL, that doesn't prohibit you from licensing it under any other terms. You can distribute your own code under as many licenses as you want.
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.
Sun could have dual-licensed it under the CDDL and GPL. They could have used an Apache or BSD license. There were plenty of options available
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
> 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.
You are aware that Oracle is the company behind BTRFS and Oracle now owns Sun and ZFS?
Re: (Score:2)
You are aware that Oracle is the company behind BTRFS and Oracle now owns Sun and ZFS?
I am aware. Also, Oracle licensed BTRFS under the GPL from the start. Makes it a lot easier to integrate with Linux when you don't have to make poor technical choices due to licensing issues.
Re: (Score:3, Informative)
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: (Score:3, Interesting)
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: (Score:1)
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 f
Re:Stability, reliability (Score:4, Informative)
Re: (Score:1, Funny)
God I love slashdot! I *literally* pulled that quote out of my ass, and it's already been moderated up to 2, insightful.
Re: (Score:1, Funny)
You have a very weird way of storing quotes.
Re: (Score:2)
Re: (Score:2)
You should see how insightful he gets after eating cabbage and beans.
Re: (Score:1)
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.
Re: (Score:1, Interesting)
"But her face"
As in, she's so hot...but her face.
Re: (Score:2)
That's what bags are for
Re: (Score:1)
Re: (Score:3, Interesting)
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 othe
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 actual
Re: (Score:2)
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 SA
Re: (Score:2)
That's pretty much what I thought. Your technical solution is coherent, well-thought-out, clear, planned very well, and exactly not what original poster requested. I'm sure it's because you believe (and I agree) that what original poster requested is neither feasible nor practical.
So, in short, other than your excellent but basically off-topic suggestion, your answer is "no."
Re: (Score:2)
that what original poster requested
Looks like we have different interpretations of what the original poster requested.
On one hand he asks for a specific solution: "I'm more interested in a truly distributed file system"
On the other he states the intended purpose: "for making better use of my home LAN full of PCs with those over-sized hard drives that could be being used efficiently."
As the posters suggested solution is infeasible but his stated purpose can be resolved I'd consider that a completely relevant
Re: (Score:2)
iSCSI isn't a distributed filesystem. And yes, several have been invented before, none of them very stable yet.
Centralized repository of data != Distributed & redundant storage system.
Re: (Score:2)
iSCSI isn't a distributed filesystem.
It is, however, a solution to more effective use of oversized hard drives; minimizing wasted space has always been one of the selling points of SAN storage. For the purpose, any block level storage protocol capable of supporting diskless machines would work, of course.
Centralized repository of data != Distributed & redundant storage system.
That would depend on your configuration. Most SAN storage solutions are distributed and redundant. You might not spread slices ar
Re: (Score:2)
Re: (Score:1)
Evgeniy Polyakov's Distributed Storage (DST) and Elliptics projects are along the lines of what you're thinking. DST is available in the latest testing kernel via the staging drivers series. See http://www.ioremap.net/taxonomy/term/2 [ioremap.net] and http://www.ioremap.net/taxonomy/term/17 [ioremap.net], respectively.
Re: (Score:1, Interesting)
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: (Score:2)
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: (Score:2)
Re: (Score:2, Insightful)
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: (Score:2)
I thought so too, but I have noticed that deleting files on ext4 is faster than on ext3 on my dm-crypted drive.
Re: (Score:1)
Re: (Score:2)
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? (Score:3, Insightful)
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: (Score:2)
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: (Score:2)
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: (Score:2)
You are correct, I should have left off the '2'
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Why recommend xfs, when jfs is smaller and faster?
Re: (Score:2)
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... (Score:2)
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
Designed for database usage? Not. (Score:2)
Hardly. ZFS and btrfs use a copy on write design that is decidely non-optimal for database usage. Both work best when files are completely rewritten or only appended to. Partial writes to files cause them to get fragmented. This problem is severe enough that btrfs at least is planning special options so that the performance of large databases doesn't go downhill. How they plan on integrating that with a copy on write design is an interesting question.
What will happen to Btrfs (Score:3, Informative)
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: (Score:2, Interesting)
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: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
Why would you think that Btrfs is unstable and slow... because of one article where they tested an unfinished, un-optimized file system on a single computer with a simple single SATA drive.
No filesystem performs the same on every device you use it on. Some very basic file systems do quite well on most drive/controller configurations, but anything truly advanced needs to be tuned for the configuration.
Honestly, with all that btrfs has to offer, I could care less that it's marginally slower than EXT 3/4. Es
Re: (Score:2)
Why would you think that Btrfs is unstable and slow...
There have been other Btrfs benchmarks. The main page of the Btrfs wiki [kernel.org] says:
Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.
If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?
If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?
Re: (Score:2)
Why would you think that Btrfs is unstable and slow...
There have been other Btrfs benchmarks. The main page of the Btrfs wiki [kernel.org] says:
Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized, but it will only be changed if a critical bug is found and no workarounds are possible.
The Wiki doesn't say it's unstable or slow at all... only that its not complete so they don't recommend it for production. It could be the fastest and most stable file system on the planet and still have that warning if the developers were not 100% confident that the disk format won't change.
If anything, one could hope that Oracle pulls some folks from ZFS to btrfs and actually speeds development, why develop two competing open file systems?
If they were going to pick just one, why would they favor the one that is not done over the one that has been in production for years? Especially considering that more people deploy Oracle on Solaris/SPARC than on Linux?
The one that is done is not compatible with the linux kernel. Why do you think that Oracle started the btrfs project to begin with, they wanted something as feature rich as ZFS but would run on linux.
It's possible tha
filesystem config for each case? (Score:2)
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.
Re: (Score:2)
What's the advantage of XFS over ext3?
Re: (Score:2, Informative)
> 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 b
Re: (Score:2)
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
Re: (Score:2)
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 -- a
Re:format stability (Score:4, Informative)
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: (Score:2)
Re: (Score:2)
A mounted XFS volume can also be increased on the fly.
XFS is able to scale to much larger partition siz
several useless metrics (Score:3, Insightful)
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: (Score:3, Insightful)
Because Phoronix does really crappy pointless benchmarks all the time. Occasionally they sucker me into reading them and I always wish I hadn't
try again (Score:1, Insightful)
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? (Score:2, Insightful)
I didn't RTFA but why no mention of ZFS?
Re: (Score:2, Insightful)
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 implementati
Re: (Score:2)
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!
ReiserFS all the way! (Score:1, Funny)
No large file unlink() benchmarks? (Score:1, Interesting)
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
xfs? (Score:2)
All these results just make me wonder why we arn't all using 'xfs' by default nowadays?
One drive? (Score:2)
How can one say that Btrfs is slower when they only tested on a single configuration.
I wouldn't be surprised if Btrfs would outperform the others on systems with multiple disks, especially if it has some ZFS style capabilities.
Also, I didn't see anywhere that they were running a 64bit install... I would hope that the devs for Btrfs are optimizing for 64bit systems.
Reguardless, a single configuration test does not qualify them to say that one filesystem is faster than another... unless they qualify it by say