Samsung USB 3.1 Flash Drive BAR Plus MUF-256BE3/EU – further degradation(WHL #45F1)
Well here’s a first 
I’m about to RMA a piece of hardware, and I needed performance data from when the thing was new. Probably got a screenshot from back then, but searching for it on a machine that is inconvenient to access…just search the interwebs instead. And so I did, and entered the Google image search, and found what I needed. Yeah, turns out I just found my very own website. 
So, here’s the culprit again:
It’s not used that often, currently holds 110GB of WSUS data and some deep learning test dataset, so almost half of the drive is empty and performance is getting worse.
Performance when new:
Performance when used:
24h
Performance now:
Note that the sequential write rate stated at 6 MB/s and stopped at 70 MB/s, probably a side effect on writing 0xFFs to large portions of the disk (partition completely empty). 4K access rates are down (even compared to the used state before), and write access times have quadrupled. It often feels sluggish and has other issues, see below.
Similar story on CDM (bench has changed a lot *again* since version 6 and results aren’t fully comparable anyway due to different Windows, board and USB chipset)
Much worse than performance degradation however is that the stick randomly disappears and needs to be re-seated in order to work again. Maybe it’s the increased power usage (..why?), as it once used 0.2W in idle (now 0.3W), 0.3W while reading (now 0.6W) and 0.6W when writing (now 0.9W to 1.0W). This also pushes thermals from former 20-25K above ambient to more like 40K above ambient worst-case, which is now in unpleasant-to-touch territory. I mean it’s great that the chip self-disconnects before it burns out, but that’s not terribly useful for any drive in general and it should throttle instead – probably more than it already does.
So – I already had a chat with Samsung US and they would exchange the drive no questions asked (5Y warranty period) – it’s just that RMA via Samsung Europe would be a good idea due to postage. If that goes wrong for arbitrary reasons, I’ll probably rant about it in a future blog post 
dmesg output bonus for the Linux fanbois:
usb 10-1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd usb 10-1: New USB device found, idVendor=090c, idProduct=1000, bcdDevice=11.00 usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 10-1: Product: Flash Drive usb 10-1: Manufacturer: Samsung usb 10-1: SerialNumber: 0374718100011xyz usb-storage 10-1:1.0: USB Mass Storage device detected usb-storage 10-1:1.0: Quirks match for vid 090c pid 1000: 400 scsi host6: usb-storage 10-1:1.0 scsi 6:0:0:0: Direct-Access Samsung Flash Drive 1100 PQ: 0 ANSI: 6 sd 6:0:0:0: Attached scsi generic sg3 type 0 sd 6:0:0:0: [sde] 501253132 512-byte logical blocks: (257 GB/239 GiB) sd 6:0:0:0: [sde] Write Protect is off sd 6:0:0:0: [sde] Mode Sense: 43 00 00 00 sd 6:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 6:0:0:0: [sde] Attached SCSI removable disk
On a side note, I’ve already bought another Samsung flash product, this time a 128GB MicroSD card (“PRO Plus 2021”) bundled with one of those small USB readers, article number MB-MD128KB/EU or MB-MD128KB/WW. It’s rated for 160MB/s reads and 120MB/s writes, UHS-I U3 and app class A2, and it isn’t far off those advertised numbers. Plus: No performance degradation regardless of filling state, since it does have an aggressive garbage collection implemented as suggested by trimcheck. The moment a file is deleted and marked for removal from the disk, it reads random data back and sectors are getting cleaned in a background task. Results are the same every time, I ran a full test of h2testw in between those AS SSD runs – also without performance degradation. Perfectly oversized for use in my T400 internal card reader for backups!
TRIM check v0.7 - Written by Vladimir Panteleev https://github.com/CyberShadow/trimcheck Loading continuation data from I:\trimcheck-cont.json... Drive path : \\.\I: Offset : 35913728 Random data : B5 D7 A9 2F 8F C9 70 C5 99 0F 34 CF 58 C7 5A A3... Reading raw volume data... Opening \\.\I:... Seeking to position 35913728... Reading 131072 bytes... First 16 bytes: 7A 9A CF 9F B6 C8 66 D1 5A 77 56 6F 2A C9 1A 2C... Data is neither unchanged nor empty. Possible cause: another program saved data to disk, overwriting the sector containing our test data. CONCLUSION: INDETERMINATE.
