Announcement

**oshunluvr** · Mar 16, 2021, 11:35 AM

Off the top I would say, yes that's too slow for a Samsung 840 Pro, but mine isn't much better (same tests):
My Samsung 840 Pro drive (45000+ power on hours, probably same age as yours):

Code:

[Read]
 541.341 MB/s [    528.7 IOPS] 
 494.982 MB/s [    483.4 IOPS] 
 196.398 MB/s [  49100.7 IOPS]
  35.857 MB/s [   8964.5 IOPS] 

[Write]
 505.046 MB/s [    493.2 IOPS] 
 438.812 MB/s [    428.5 IOPS] 
 174.436 MB/s [  43610.0 IOPS]
 122.764 MB/s [  30691.1 IOPS]

Benchmark utilities aren't really worth much except to compare raw results. Not much of what they test spills over into the real world.

If you're testing on NTFS, I would expect poor results. It's a crappy file system and not native to Linux. That we can read/write to it is a hack at best IMO. EXT4 can be tuned - there's dozens of articles on how to. I use btrfs which is generally slower than EXT4 but my results are better than yours.

My EXT4 partition has these mount options: noatime,data=writeback,barrier=0,nobh,errors=remou nt-ro
For some reason the Forum software is inserting that extra space in "remount-ro". We're due for an upgrade soon.

I also shrunk the reserved blocks to 0 instead of the default 5% because it's not a system partition, just used for virtual drive storage.

Just for fun, here's my Samsung 970 Pro NVME drive:

Code:

[Read]
3193.470 MB/s [ 3118.6 IOPS] 
1610.199 MB/s [ 1572.5 IOPS] 
 746.689 MB/s [ 186673.2 IOPS] 
  57.107 MB/s [ 14276.8 IOPS] 

[Write]
1763.246 MB/s [ 1721.9 IOPS] 
1443.867 MB/s [ 1410.0 IOPS] 
 155.535 MB/s [ 38884.9 IOPS]
 136.145 MB/s [ 34036.4 IOPS]

As far as the lagging, I doubt it's the drives. More likely NTFS and file indexing - which you can turn off - or let run until it's finished. You're not running your installation from a NTFS partition are you?

BTW, here's a one-liner that will run hdparm on all your drives:

for dr in `lsblk -d |grep -v -- 'loop\|sr\|NAME'`; do sudo hdparm -Tt '/dev/'$dr; done

**chconnor** · Mar 16, 2021, 12:14 PM

Thanks a bunch --

Originally posted by oshunluvr View Post

If you're testing on NTFS, I would expect poor results. It's a crappy file system and not native to Linux.

Yeah my problem has always been that I dual boot between windows and I've never found a better option to share partitions between the two. I.e. the support in windows for linuxy filesystems has always been worse than the support in linux for windowsy filesystems. :-) If there are any alternatives, I'm all ears!

I'll look into those ext4 options and see if I can improve things at all, thanks.

Re-running kdiskmark I'm getting results closer to yours, so it may have been a transitory issue...

As far as the lagging, I doubt it's the drives. More likely NTFS and file indexing - which you can turn off - or let run until it's finished.

The thing is that it has only started recently, after 8ish years of being fine. It's not terrible lagging, just every now and then things hanging longer than they used to. E.g. saving a text file in emacs that used to be instant now pauses for a few seconds, or opening a dolphin window takes a couple seconds before the contents appear, etc... stuff that kinda feels like the disk is held up doing something. Maybe a recent update has caused some kind of issue.

You're not running your installation from a NTFS partition are you?

No, / and /home are of course ext4. It's just the dual-boot shared data partitions that are NTFS. I do, however, symlink some stuff from the ext4 partitions to the ntfs partitions, due to limited space on / and /home, e.g. firefox cache, but nothing that I think would explain this...

**claydoh** · Mar 16, 2021, 12:20 PM

Is it possible, or rather likely, that the differences seen between the OSs are due to different benchmarking tools being used in each one?

**chconnor** · Mar 16, 2021, 12:26 PM

Hey, out of curiosity, what do you get on your 840 Pro for:
sudo smartctl -a /dev/sda | grep Total_LBA | awk '{print $10}'

I'm only at 30k hours but I do a fair amount of file I/O (lots of time lapses with thousands of files :-) ) and I'm just idly curious to see if it's more or less than yours.

While we're at it, what about:

sudo smartctl -a /dev/sda | grep Wear_Leveling | awk '{print $4}'

...I'm at 88%.

**chconnor** · Mar 16, 2021, 12:32 PM

Originally posted by claydoh View Post

Is it possible, or rather likely, that the differences seen between the OSs are due to different benchmarking tools being used in each one?

Yeah I dunno... seems like CrystalDiskMark and KDiskMark are testing in nearly identical ways, but obviously I'm not the expert. I'm not worried about the fact that they get different results, per se, especially because of the ntfs issue... but the difference was pretty extreme. At any rate, even ignoring the windows side it's nice to get some sanity checking on the purely linux/ext4 side of things. I'm going to see if the mount options make any noticeable differences.

**oshunluvr** · Mar 16, 2021, 12:46 PM

I have 2 of them actually:

Device	Total_LBA	Wear_Leveling	Power_On_Hours
sda	31552575061	088	45217
sdb	38690114852	084	52563

**oshunluvr** · Mar 16, 2021, 12:53 PM

The big take-away from my above results re. the NVME drive vs. SSD is the "Random 4K Q1T1" results are identical for all practical purposes, as are the writes for Random 4k Q32T16 benchie.

When people like me say benchmarks aren't of much use in the real world, that's what we mean.

**chconnor** · Mar 16, 2021, 12:58 PM

Originally posted by oshunluvr View Post

The big take-away from my above results re. the NVME drive vs. SSD is the "Random 4K Q1T1" results are identical for all practical purposes, as are the writes for Random 4k Q32T16 benchie.

When people like me say benchmarks aren't of much use in the real world, that's what we mean.

I noticed that... so what you're saying is that "NVME is certainly better/faster but the benchmark misleadingly makes it look like it's roughly the same"?

**oshunluvr** · Mar 16, 2021, 01:07 PM

Your symptoms sound like they could be tracked down and I agree there must be a problem somewhere if there's been a change. I wonder what overhead issue could be the culprit.

As far as the other - why do you dual-boot to Windows? Games I guess? Otherwise, Windows is much faster running in a QEMU/KVM virtual machine.

**oshunluvr** · Mar 16, 2021, 01:17 PM

Originally posted by chconnor View Post

I noticed that... so what you're saying is that "NVME is certainly better/faster but the benchmark misleadingly makes it look like it's roughly the same"?

It's kinda deceptive on both ends: The manufacturers will advertise the high-end numbers but not the roughly equal ones. My point is whether or not something like a drive type or file system is "better" than another is heavily dependent (and wildly variable) on your actual use-case. Is my nvme drive noticeably faster in some specific operations? For sure. Overall though, the difference is rarely very apparent. I think, using Linux, file system access times are more noticeable based on file system type rather than the storage medium - at least when it comes to SSDs. Moving off of platter drives for all except backup storage was a HUGE gain. The difference using the NVME drive is not as obvious (compared to SSDs) despite the differences in the specs.

It would be an interesting experiment to use the KDiskMark tool on some other file system types.

**chconnor** · Mar 16, 2021, 01:47 PM

Gotcha, thanks.

So I couldn't boot with "data=writeback", because on / apparently you have to also do:

$ tune2fs -o journal_data_writeback /dev/sda2

...however when I boot (now successfully) I don't see it in:

$ findmnt /dev/sda2
TARGET SOURCE FSTYPE OPTIONS
/ /dev/sda2 ext4 rw,noatime,nobarrier,errors=remount-ro,commit=60

...I expected "data=writeback" in there... /etc/fstab is:

UUID=1234 / ext4 noatime,data=writeback,barrier=0,nobh,commit=60,er rors=remount-ro 0 1

...any ideas? I notice that "nobh" also seems to be disappearing. Should I just ignore these issues and trust that data=writeback and nobh are in effect?

**chconnor** · Mar 16, 2021, 02:01 PM

Originally posted by oshunluvr View Post

As far as the other - why do you dual-boot to Windows? Games I guess? Otherwise, Windows is much faster running in a QEMU/KVM virtual machine.

I boot to windows for audio production software and video editing (Reaper + associated plugins, and Davinci Resolve -- both have linux versions but for various reasons they aren't workable for me, or at least not well enough to wean myself off windows.) There are also a variety of other obscure things I need windows for, but they could probably run comfortably in a VM or wine.

Windows faster in a VM? I'm intrigued... do you have links or more info? It probably wouldn't be great for me, given the need for consistent and low latency with audio interfaces (?), but I'm still curious.

**oshunluvr** · Mar 16, 2021, 02:14 PM

This should work: https://linuxize.com/post/how-to-ins...-ubuntu-20-04/

QEMU/KVM isn't as easy as VirtualBox but it's not rocket science and it way more efficient IMO. I can boot Win10 in a VM in about 12 seconds. The first couple times you try to create a new machine you may fumble a bit, like the way it handles virtual storage isn't obvious, but once you get it, it's cake. You can even set it up to allow hardware pass-through and give your VM direct access to the video card, for example. I didn't do that because it's not needed for what I use it for.

Can't hurt to give it a try. If you're accessing specific hardware via a midi interface you may have to work at that. It's even legal to run Win10 in a VM via the MS license.

**chconnor** · Mar 16, 2021, 02:17 PM

Great, I'll check it out. Can it map multiple monitors reasonably well?

Announcement

SSD performance problems -- config problem or old drive?

SSD performance problems -- config problem or old drive?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment