--
Greg Freemyer
On Mon, Oct 28, 2013 at 4:37 PM, Yamaban
On Mon, 28 Oct 2013 21:16, Greg Freemyer
wrote: On Mon, Oct 28, 2013 at 9:30 AM, Yamaban
wrote: Other filesystems (XFS,JFS,ZFS,...) should be only in expert-mode made available, or above a certain partition-size (see btrfs and 15TB), with a strong hint about these fs not being useful in most SOHO cases.
I argue XFS for sure should stay on the list.
== background
Dave Chinner (xfs devel) would argue that ext2/3/4 is what should be removed from the default list and XFS & btrfs be the only 2 choices.
See this from Jan 2012: http://www.youtube.com/watch?v=FegjLbCnoBw He says anything with a 3.0 or newer kernel should be considering xfs in preference to ext2/3/4 if they have multiple CPUs (and even my phone has multiple CPUs) performing I/O to the fiilesystem.
The core argument for that is recent XFS from the last couple years has incorporated a lot of the ext3 / ext4 speed improvements in journal handling, but it has maintained the scalability capacity it always had. Thus it is now useable from the desktop to the datacenter.
I haven't seen a xfs related lost data horror story from a routine power outage in years, so the old statement the xfs only made sense if you had solid power is no longer true I don't think.
Thus Dave Chinner argues that a user wanting a stable FS that scales from desktop to enterprise should focus on XFS.
Users that want the features of btrfs should use it on their desktops and XFS on their big systems.
For big partitions (see 15 TB) better xfs than btrfs, sure. ATM I'd say btrfs up to ca 8 TB, XFS as a valid option ca 6 TB and up.
What hinders me to give a full recomentation for XFS is the overhead on create and remove a file / dir . That summs up, see the tests.
I don't know what you saw in Carlos'es results to make you say that. I think the situation is far more nuanced than you suggest. For a single threaded situation, all of the speed benchmarks Carlos posted are acceptable as far as I'm concerned.
From Carlos'es earlier post in this thread for both 100 Byte files and 10MiB files:
=== 10000 files of 100 B time (real/user/sys) | listing time | rm files time | used free % | (real/user/sys) | (real/user/sys) | space space reiserfs 0m10.171s/0m0.795s/0m1.445s | 0m0.030s/0m0.027s/0m0.003s | 0m0.282s/0m0.002s/0m0.277s | 9.9M 118G 1% ext4 0m10.087s/0m0.779s/0m1.387s | 0m0.050s/0m0.045s/0m0.006s | 0m0.126s/0m0.004s/0m0.121s | 266M 112G 1% ext3 0m10.266s/0m0.732s/0m1.415s | 0m0.050s/0m0.040s/0m0.010s | 0m0.156s/0m0.005s/0m0.148s | 228M 112G 1 xfs 0m10.193s/0m0.680s/0m1.332s | 0m0.028s/0m0.023s/0m0.005s | 0m0.235s/0m0.003s/0m0.231s | 270M 120G 1% btrfs 0m10.195s/0m0.689s/0m1.394s | 0m0.030s/0m0.026s/0m0.004s | 0m0.280s/0m0.005s/0m0.273s | 9.6M 118G 1% === 10000 files of 10 MB (not 10 MiB). Disk busy at up to 155MB/s - hardware is the limit. time (real/user/sys) | listing time | rm files time | used free % | (real/user/sys) | (real/user/sys) | space space reiserfs 12m39.628s/0m4.775s/3m10.519s | 0m0.309s/0m0.032s/0m0.005s | 0m13.438s/0m0.032s/0m0.005s | 94G 27G 78% ext4 12m15.974s/0m3.833s/1m43.232s | 0m0.077s/0m0.043s/0m0.009s | 0m6.394s/0m0.004s/0m1.490s | 94G 19G 84% ext3 15m20.931s/0m3.756s/2m40.206s | 0m0.156s/0m0.045s/0m0.007s | 0m9.677s/0m0.005s/0m3.006s | 94G 19G 84% xfs 11m11.731s/0m4.737s/1m26.311s | 0m0.155s/0m0.024s/0m0.005s | 0m9.480s/0m0.011s/0m1.584s | 94G 27G 78% btrfs 10m37.071s/0m4.837s/1m11.542s | 0m0.376s/0m0.027s/0m0.004s | 0m9.755s/0m0.004s/0m2.691s | 92G 27G 78% ===
Create Speads All 5 create the 10,000 100 Byte files at the same speed +/- 1%.
XFS is second fastest at creating 10MB files and is over 3 minutes faster that ext3 and a minute faster that ext4. In fact XFS is faster than everything but BtrFS at creating the 10MB files. If creating 10 MB files is important to you, then it is reiserfs and ext3/ext4 you should eliminate from you options. If you only care about small files, then they all create files very quickly. There is certainly no reason to make a blanket statement that XFS is slow at creating files.
Listing files For the 100 Byte files, all list the files at roughly the same speed.
For 10 MB files, listing is effectively fast for all except BtrFS and ReiserFS which take about 1/3 of a second each. For an interactive user, 1/3rd of a second is noticeable.
Removing files For 100 Byte files, xfs takes 0.235 seconds to delete 10,000 files. Both ReiserFS and BtrFS take longer. For 10 MB files, XFS is only bested by ext4, but admittedly by over 3 seconds.
------ I don't know about you, but I don't delete directories with 10,000 files in them very often and when I do I can stand to wait an extra 3 seconds. The speed tests certainly don't rule XFS out in my mind even for a singlethreaded test like Carlos did. Then if you watch the video, you see that Carlos tested XFS in it's worst mode. Were it shines is if you have multiple threads sending file i/o at it. For up to 8 threads it basically sees a linear speed bump. Neither ext4 or BtrFS can keep up. (ReiserFS was not part of Dave Chinner's testing). Historically XFS fell down because it couldn't handle huge tarball extraction and large tree deletion very well. That issue is resolved and if you are compiling in parallel like a lot of builds do these days, then XFS may be the best choice even for a developer working with large tarballs. fyi: I did not read the test script to confirm all the cache flushes are handled right for the above benchmark to be valid, but it probably doesn't matter. For a normal user, they just want to know how long the command prompt takes to return and don't care if the kernel is still processing the removes in the background. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org