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.
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.
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.
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 )
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.
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.
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.
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.
