F2FS Enables Discard By Default, Performance Enhancements

[phoronix]

Phoronix: F2FS Enables Discard By Default, Performance Enhancements

Jaegeuk Kim, the creator and lead developer of the Flash-Friendly File-System (F2FS), has finally submitted the big feature updates slated for the Linux 4.19 kernel merge window...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-F2FS-Changes

[schmidtbag]

Wait they just now have TRIM enabled by default? That should've been the default from day 1.

[carewolf]

Wait they just now have TRIM enabled by default? That should've been the default from day 1.

Well, doing TRIM on every operation is usually a bad idea. Doing it periodically performs better. I assume they have implemented something smarter than what -o discard does on all the other FS

[schmidtbag]

Well, doing TRIM on every operation is usually a bad idea. Doing it periodically performs better. I assume they have implemented something smarter than what -o discard does on all the other FS

As far as I'm aware, it's only an issue during file deletes (which includes overwriting files) which isn't typically something very demanding. I can't think of any time-sensitive situation involving deleting files where the performance loss of on-the-fly TRIM would be significant enough to be a problem. I'm not saying such a scenario never comes up, but it's rare enough that it makes more sense for discard to be enabled by default.

[carewolf]

As far as I'm aware, it's only an issue during file deletes (which includes overwriting files) which isn't typically something very demanding. I can't think of any time-sensitive situation involving deleting files where the performance loss of on-the-fly TRIM would be significant enough to be a problem. I'm not saying such a scenario never comes up, but it's rare enough that it makes more sense for discard to be enabled by default.

The difference is large and measurable. If for no other reason that Windows does deferred trimming and thus drives are not optimized to do them fast in sync.

[schmidtbag]

The difference is large and measurable. If for no other reason that Windows does deferred trimming and thus drives are not optimized to do them fast in sync.

I'm very well aware the difference is large, my point is the difference isn't typically relevant in real-world scenarios. It's very rare to be in a rush when deleting or overwriting file(s). Again - if someone really cares about delete performance, it's not that hard to disable on-the-fly TRIM, but they're in the minority.

Also, I would not be using Windows as an example of how things should be done. For example, Windows is pretty much the only OS that still has to deal with defragmenting HDDs.

So all that being said, a filesystem specific to SSDs really ought to have TRIM enabled by default.

[Gusar]

Also, I would not be using Windows as an example of how things should be done.

It's a "Windows does XYZ, so device manufacturers optimize for XYZ" scenario. That XYZ might not be optimal is besides the point.

[schmidtbag]

It's a "Windows does XYZ, so device manufacturers optimize for XYZ" scenario. That XYZ might not be optimal is besides the point.

Except that doesn't apply in this case because F2FS isn't Windows compatible, or at least it isn't officially supported anyway.

[Gusar]

Except that doesn't apply in this case because F2FS isn't Windows compatible, or at least it isn't officially supported anyway.

I specifically said device manufacturers. If the device itself is slow with inline trimming, activating it is detrimental regardless of filesystem. Whether it's noticeable in real-world scenarios is again besides the point, it's about how the hardware is designed, and it's the behavior of Windows that often dictates design decisions.

[andrebrait]

Gusar has a point