Linksys WRT3200ACM - USB3 Enclosure Performance

I have just switched from the stock Linksys (and DD-WRT on occasion) to OpenWRT, and after spending two days struggling to get my USB3 Enclosure to work (nota bene: Don't install both ntfs kmod and ntfs fuse), I have finally both working miniDLNA and Sambav4.

OpenWRT 19.07.6 Status:

Drive Mount Options:

-o rw,big_writes,noatime

CrystalDiskMark result via mapped network drive to wired Windows 10 client:

AMS DS-309U3 Enclosure:


I've read that the fuse implementation of NTFS is a bit slower than in-kernel can be, and that the CPU overhead can be detrimental on embedded devices.

The reason I bought my WRT3200ACM initially was that I saw a number of benchmarks that put its USB Storage performance way ahead of any other device in its class, and with the main goal of having an enclosure shared as a NAS-lite, I purchased.

I'm not sure how DD-WRT and the OEM firmware implemented NTFS support, but the drive was very fast/responsive then, and feels just as much so now when doing transfers via Windows Explorer.

Stable 100MB/s transfers

I'm just wondering if there would be any risk, or benefit, to me dropping the fuse NTFS support for the kmod one.


you'll need to mention what version/release you are running... as it is relevant here...

1 Like

Ah, thought having it in the screenshot above would be sufficient.

OpenWRT 19.07.6

All packages latest as of today.

thanks... vision imparied may find screenshots troublesome...


I think ntfs has been, and continues to be, something less than what might be considerd well performing. The recommendation usually has been to convert to something else (i.e. ext3 || 4)


There actually are attempts by Paragon Software to get their ntfs kernel driver merged mainline, but it will take some time to actually arrive (they're at v19 now, submitted less than three days ago).

Yes, hell indeed freezes over, first exFAT, now ntfs…


I apologize, and thank you for prompting me to make it more accessible.

Yes, people always have recommendations for filesystems they prefer. I'm quite interested in BTRFS, but I'm a bit cautious to use it to store our data for our household.

Again, I'm not complaining about the performance, I'm merely asking for anyone's recommendations/data/experience specifically between the FUSE and the kernel implementation of NTFS on OpenWRT. I've read in numerous places that they perform differently and there are potential pitfalls to either.

I've been watching the news around this with some interest on Phoronix. I gather it is meant to be way more robust and performant than the current FUSE implementation.

1 Like

Apparently, I missed an important detail with the current kmod NTFS: Read-Only.

So, I'll have to re-visit this line of inquiry if/when the Paragon NTFS kernel driver gets upstreamed and makes it into OpenWRT.

In a similar line of inquiry, does anyone have any data/feelings/thoughts on the in-kernel ksmbd versus the samba4 implementation?

Same as above... just looking for reliable, light, and fast, though, at the moment, I have no issues with speed.

light = ksmbd ( although on 'stable' / 19 ... you may run into concurrency issues )

full version for anything fancy like domains / timemachine etc.

1 Like

Thank you. That reinforces what the documentation states on the matter, which is nice.

I'm a bit concerned about the stability aspect, since as I intimated above, my NAS-lite is the data storage for our household. I don't have a RAID enclosure yet (I am still saving for that), so I'd rather err on the side of stability/reliability for read/write to this datastore.

Is the ksmbd unreliable to where it might corrupt data, or just drop connections under heavy load?

As for the fancy stuff... I am using the drive as a target for Windows File History for 4 machines. I do not believe this requires anything other than NTFS as a target volume, so I don't THINK I'll be needing the Shadow Volume Copy support mentioned here:

thats really a hw / fs concern... and not atypical of daemon failure modes...

best thing to do is try it and see... again... majority of issues come down to hw / fs selection and compatibility... ( which daemon selection will make very little difference to )

1 Like

Thanks for that.

I've had no issues with regards to hardware/fs in this setup for the past four years, so I know they're stable and reliable.

Hmm... I guess it could be worth giving it a go and just keeping my fingers crossed, haha.

1 Like

Quick note: ksmbd on stable (19.x) still has the issue that i cant really update the package anymore, because of some kmod update issue. So i have to wait on 20.x to pickup the snapshot changes.

So if you have the space use samba4 over ksmbd on stable. On snapshots use whatever works best.
On snapshots i also enabled io_uring for samba-4.13.x, which is the new "aio" kernel thinggy and should improve NAS performance on heavy multiuser/task/DB use cases and less so for normal sequential/single file transfers.


Does ksmbd get the io_uring update for 20.x as well, or does it not apply?

Also, do you happen to know if I can use ksmbd with Windows File History?

Only samba-4.13 has it implemented and so far no info on ksmbd adding support for it.

Not sure, you have to test yourself.

CrystalDiskMark for ksmbd:
Seemingly quite a large improvement over samba4 in CrystalDiskMark.

Things look much less rosy when doing transfers via Windows Explorer, or using FileHistory for backup/restore.

Transfer rate seems to cap out at around 1.5MBps:

Even stranger is after a reboot of the Windows 10 Client, transfer rates are back to something acceptable, but still slower than the benchmark or even before under samba4.

I also seem to have problems deleting files, which I believe I read others experienced as well:

FileHistory seems to be struggling a bit under current conditions as well. It claims to back-up files on command, but fails to actually write them. Same goes for cleaning old revisions. It counts them up, then fails to remove them after waiting a long while.

Back to samba4:

File History working properly under samba4:

1 Like

SQM QoS with Piece Of Cake set to 95% of 1Gbit (950,000kbit/s) up/down did not improve or help internal network transfers on the br-lan device.

Capped Explorer transfers to about 70MBps, and greatly reduced benchmark scores in CrystalDiskMark.

Would you ever need to connect that enclosure directly to a Windows machine? If not, why not reformat the drive into Linux native ext3/ext4?

1 Like
  1. The NAS serves as a FileHistory store for four Windows machines in the household. I do not believe ext4 will serve this purpose and I have not explored the viability of other underlying FS over SMB for FileHistory. Something to poke at, for sure.

  2. Personal anecdote: The only non-FAT filesystem I've ever had corrupt beyond repair from an unexpected powerloss was ext4. So, I normally run BTRFS or JFS on my non-Windows volumes.

Afaik if you're serving files with samba, it doesn't matter what the local file system is. I have NAS with ZFS raid and it's serving macOS and Linux clients with AFP and SMB shares and clients don't know what kind of file system NAS uses.

1 Like