4

My server contains 128 monitors and that caused many random write IO be submitted. If I use SSD, many writes will make it broken soon.

I read some articles about F2FS and know it works better on flash disk and random/small writing.

There are many random write IO in my server. It always degrade performance in my server.

If I mount F2FS on a HDDs? Does that works better than ext4?

====== UPDATE ======

RAID0 just for performance benchmark, actually I will use RAID5 or RAID6.

After I searched a lot, there're 2 way maybe works:

  1. Cache IO
  2. Queue IO from random IO to sequential IO <-- F2FS supports that
code_worker
  • 161
  • 6

2 Answers2

6

Do not use RAID0, a failure of any one drive will kill the array. RAID6, RAID10, even a single drive with no array would be better for availability.

f2fs intends to be friendly to modern solid state devices, and Linux md can go very fast.

However, impossible to make general statements like f2fs on an array is better without data. You need to take into account what your workload is, if the I/O pattern has been benchmarked on a system similar to yours, and what limiting factors exist.

Do a capacity analysis. Estimate things like database queries per second, or how many files are read and written. Measure IOPS with tools like iostat -xz 1. If the r/s and w/s numbers approach the rated capacity of the device, you may need faster disks. Expect roughly 100 IOPS per spinning magnetic, and at least a couple thousand IOPS out of most SSDs. And it makes a different whether disks are connected as SATA or NVMe.

Evaluate the performance of every resource on the system. Fast storage is of limited help if you are CPU or memory bound. Memory is especially useful as cache. Excessive paging out is bad, as the swap file steals storage system performance but isn't as fast as DRAM.

Once you understand the performance of the system now, then you can start evaluating changes to the storage system.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks lot. RAID0 won't be my opinion, that's just a performance benchmark for me. – code_worker Jun 22 '20 at 03:47
  • My environment contains 128 monitors and that's why I say so many random write IO in my server. The pattern doesn't works great in ext4. So it is sure IO bound and better way are 1. cache IO queue or 2. queue them into a sequential write IO. F2FS support the 2nd way but I don't know if it suits – code_worker Jun 22 '20 at 03:53
  • Yes, but specifically how many IOPS and what storage are you using? Edit your question to add that. It does no good to talk in general when you have a specific workload. F2FS is not magic. XFS can do 100,000 IOPS but you need a monster storage to accomplish it. – John Mahowald Jun 22 '20 at 13:50
5

Using F2FS on a classical HDD is not a good idea: while its random write performance will probably be higher then EXT4 or XFS, the sequential read speed on an aged filesystem will be very disappointing.

To increase random write performance without having a powerloss-protected write back cache (read: a true RAID controller), you have to configure your applications to not issue fsync(), but this will significantly increase the odds of losing data with unplanned shutdown. Do not disable the barriers at system level (ie: by telling the kernel you have write through caches), as that can trash the entire filesystem in case of powerloss.

You can also consider using ZFS (preferably leaving striping to itself, rather than to the MDRAID layer): due to its CoW nature, random writes are significantly faster than on other filesystem, while advanced caching avoid the issues with sequential reads. It even supports sync=disabled: if you can tolerate a ~5s data loss window in case of unexpected shutdown, it will provide a ton of random write IOPs without impacting application or filesystem consistency.

Finally, if you are using EXT4, you can do a quick test with data=journal: while this will lower sequential write performance, random writes should be somewhat faster then the default journal mode.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • Thanks lot. Why Cow feature will improve random write? That copy block first then write, maybe degrade because so many copying? – code_worker Jun 22 '20 at 04:07
  • @code_worker CoW means LBA are not laid down in address order, so random writes can be written sequentially. A similar thing happens on first write in a sparse file on a traditional filesystem. CoW have other performance penalty, but this is not one of them. Anyway, be sure to test the filesystems with a representative workload. – shodanshok Jun 22 '20 at 08:24