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)
3 Likes
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…
3 Likes
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.
3 Likes
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
-
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.
1 Like
FileHistory is a special case as it relies upon Volume Shadow Copy Service, so I'm not sure it won't care, or if ext4 can support that.
Also, windows clients can see the underlying FS. Explorer reports it.
technically... afaik... this is not correct... windows reports whats reported by samba... which, dependent on version may or may not 'translate' whatever calls between an smbclient and its local filesystem types...
1 Like
Not really, the connected OS only sees what is set in the samba config and the options are:
(From our template config, at the end)
## reported filesystem type (NTFS,Samba,FAT)
#fstype = FAT
The default in samba-4.x is NTFS, in samba-3.x and older was Samba which acts like a special network filesystem.
So technically you could have a FAT partition and set samba to NTFS!
The reported type relates to security (ACL) handling, locking behavior (type2 locks) and file attributes.
Samba can handle (if added as option) Shadow Copy Services via its own VFS module, which you can either add in the vfs objects luci field (shadow_copy2) or manually add globally or per share to the template file itself if you want to config anything that's not default.
https://www.samba.org/samba/docs/current/man-html/vfs_shadow_copy2.8.html
PS: That is the list of default VFS modules we ship with, if you want to read on those here:
vfs_fruit
vfs_shadow_copy2
vfs_recycle
vfs_fake_perms
vfs_readonly
vfs_cap
vfs_offline
vfs_crossrename
vfs_catia
vfs_streams_xattr
vfs_xattr_tdb
vfs_default_quota
vfs_btrfs
vfs_linux_xfs_sgid
on snapshots vfs_io_uring is enabled by default if the kernel supports it.
2 Likes
Thanks to you both for correcting me.
I still need to test if other underlying FS will behave correctly with FileHistory when set to report as NTFS, and if it gains me anything significant.