Btrfs Mount Option Benchmarks With The Linux 4.9 Kernel

[sdack]

Yes, I was wondering about that too... Aren't Samsung 8** buggy and blacklisted in the kernel?

They shouldn't be. It was a bug in the raid code, which got patched a while ago. It was actually Samsung who fixed the kernel... It affected all types of SSDs, but Samsung got the blame. Funny how this is still a rumour.

https://linux.slashdot.org/story/15/...inux-trim-code

[marvin42]

others mentioned it already (a bit), nodatacow disables most features, also compression, so it makes not sense to run with nodatacow,compression=xxx ...

[Tobu]

IIRC, nodatacow still allows snapshots, copying the file only once after it is changed for the first time after a snapshot.

Mostly correct, except the unsharing is done at the extent level, not the file level. nodatacow extents shared by a snapshot are CoW once when first written, then they are unshared. In other words, snapshotting can make nodatacow performance unpredictable, but snapshot functionality is preserved.

[nbecker]

Man mount:
discard
Disable/enable the discard mount option. The discard function issues frequent commands to let the block device
reclaim space freed by the filesystem. This is useful for SSD devices, thinly provisioned LUNs and virtual machine
images, but may have a significant performance impact. (The fstrim command is also available to initiate batch trims
from userspace.)
Doesn't sound like it should speed anything up, does it?

[niner]

They shouldn't be. It was a bug in the raid code, which got patched a while ago. It was actually Samsung who fixed the kernel... It affected all types of SSDs, but Samsung got the blame. Funny how this is still a rumour.

"It" was obviously more than a single issue. Because I had similar problems but do not even use RAID in my laptop. Yet the blacklisting made the system usable. And indeed, even on the most recent kernel, Samsung SSD 8* are still blacklisted for NCQ TRIM:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c?id=refs/tags/v4.9#n4414

[niner]

Man mount:
discard
Disable/enable the discard mount option. The discard function issues frequent commands to let the block device
reclaim space freed by the filesystem. This is useful for SSD devices, thinly provisioned LUNs and virtual machine
images, but may have a significant performance impact. (The fstrim command is also available to initiate batch trims
from userspace.)
Doesn't sound like it should speed anything up, does it?

That's just very thin documentation for a mount option which even mentions the potential for a performance impact. That may as well mean a speed up.

It's actually absolutely device dependent. Discard may kill performance and it may speed up a device tremendously. Especially consumer SSDs absolutely need TRIM for sustained performance. Whether inline TRIM via discard mount option or regular TRIM via cronjob is better again depends on the hardware. Enterprise/server SSDs are less dependent on TRIM as they are usually overprovisioned extensively which helps write performance a lot.

[thelongdivider]

And still no official lz4 support.

I would like to have this as a feature too, for its ridiculously fast decompress times compared to even LZO (it appears to me to be a direct upgrade to LZO). However, the utility and necessity may still be small relative to other BTRFS issues. Especially since only a few SSDs are fast enough to notice the difference even in synthetic benchmarks.

[pcxmac]

I would like to have this as a feature too, for its ridiculously fast decompress times compared to even LZO (it appears to me to be a direct upgrade to LZO). However, the utility and necessity may still be small relative to other BTRFS issues. Especially since only a few SSDs are fast enough to notice the difference even in synthetic benchmarks.

LZO has it's benefits as in it's not as processor intensive as LZ4. LZ4 might have faster decompress, but it can draw significantly more CPU load on Compress. There are tradeoffs in most compression algorithms. It would be nice to see more compression support though, I grant you that. For me ZFS is fine for 'stores' (reading from) where I use BTRFS for active file systems (especially the root file system/IMO superior snapshot management), so LZO is actually preferred, and like has been mentioned, turning off COW, under VM images, so that you can run a COW image on top of BTRFS works well enough, but you can still use an EXT4 partition in that case.

[sdack]

"It" was obviously more than a single issue. Because I had similar problems but do not even use RAID in my laptop. Yet the blacklisting made the system usable. And indeed, even on the most recent kernel, Samsung SSD 8* are still blacklisted for NCQ TRIM:
https://git.kernel.org/cgit/linux/ke...ags/v4.9#n4414

You can get a hint from the link you've posted. It's been a single issue with multiple devices from multiple vendors and hasn't been specific to a single family of drives. That's often a good sign of the issue being with the kernel and not the drives. I'm guessing your drive does work under Windows, doesn't it?

[DrYak]

Which other features suffer from nodatacow? Data deduplication?

Indeed. A file which is marked for NODATACOW cannot share any chunk of data with another one.
No way to deduplicate a nocow file (either when mounting with "nodatacow", or more realistically, when flaging "chattr +C" one of the few corner cases that require it.

Well it's kind of pointless IMHO, COW and especially data COW is one of BTRFS' most attractive features. The only case where I disable it is for VM images (obviously).

According to official docs, the other similar use case that benefit from "chattr +C" are databases. (They to are huge files getting lots of random writes which leads to significant file fragmentation).
I've never bothered to actually benchmark, I'm just following recommendations.

(NOTE: this problem will affect any other COW/Log structured filesystem. ZFS is actually an exception. It simply doesn't seem affected because ZFS can autodetect such fragmenting files and disable COW automatically without any user intervention).

I'm actually surprised that the datanocow options didn't provide a boost to the Postgress database test.

Aren't Samsung 8** buggy and blacklisted in the kernel?

To be more precise : the Samsung 840 and 850 after the latest firmware update (the one that fixes the read speed decay) will wrongly report that TRIM + NCQ (trim could be reordered as part of the NCQ).

(This is false, they only support TRIM in direct mode : ....finish writting, flush, wait for the flush to complete, trim, wait for the trim to complete, resume work... when trying to use TRIM+NCQ to do them out-of-order they can end-up being done at the wrong time).

So the kernel has a black list to avoid TRIM+NCQ and only doing in-order TRIM on those drives.