new solid state drives for NAS / router testing

Windows has a lot of overhead in NTFS and NTFS<->samba. I think it's more than a NAS and its file system as Linux drivers and stacks tend to be leaner and less layers of abstraction than in .net.

stevech said:

Windows has a lot of overhead in NTFS and NTFS<->samba. I think it's more than a NAS and its file system as Linux drivers and stacks tend to be leaner and less layers of abstraction than in .net.

Click to expand...

A good bit of the NTFS functionality is moved to Samba (such as ACL handling), so that pretty much offsets any "benefit" you might have from using a leaner filesystem such as ext4. And that's assuming you don't use a filesystem with native ACL support, such as xfs.

ext4 generally will give better performance than NTFS on a Linux platform - the ntfs driver is getting better all the time, but ext4 is far more mature...

My experience is that NTFS on LInux and the NAS is much slower than under windows, and for writing, much, much slower. Like 50%.

re post #22 - confuses me - my point was that NTFS on windows combined with samba is much slower than windows-to-windows LAN transfers.

stevech said:

re post #22 - confuses me - my point was that NTFS on windows combined with samba is much slower than windows-to-windows LAN transfers.

Click to expand...

Windows to Windows is still "Windows with NTFS", so I don't understand your performance claim here. If Samba runs on the remote Linux endpoint, then it doesn't matter which filesystem the Windows client runs - the potential bottleneck will be the filesystem used on the Samba server.

My experience is that NTFS on Linux and the NAS is much slower than under windows. I used to do external backups to extfs for speed reasons. I can read extfs when the drive is plugged into a windows PC. But now I use NTFS on the external backup drive. After the first backup, the deltas do take a lot longer, but a half hour or so. And I just let it run. There are manually initiated backups because that external 2TB 2.5 in. drive is hidden away when not in use.

That's about all there is to say.

stevech said:

My experience is that NTFS on Linux and the NAS is much slower than under windows.

Click to expand...

And that is definitely correct, especially when using NTFS-3G. We were just talking about two different things there.

RMerlin said:

And that is definitely correct, especially when using NTFS-3G. We were just talking about two different things there.

Click to expand...

Oh. NTFS-3G .. new term for me.

stevech said:

Oh. NTFS-3G .. new term for me.

Click to expand...

There's a couple of NTFS drivers - ntfs3g is one, and there's the FUSE NTFS driver - both are more focused perhaps on doing it right, so performance compared to native file systems takes a back seat...

stevech said:

Oh. NTFS-3G .. new term for me.

Click to expand...

NTFS-3G is the most commonly used NTFS driver for Linux. Its main developer, Tuxera, also sell a high performance commercial product, which is used by Asus in their newer ARM-based routers. I think QNAP also uses the Tuxera commercial driver.

(as an aside, I exchanged a few emails with the Tuxera CEO a few years ago. Really friendly guy.)

The other well-known product is from Paragon, who has a free-for-personal-use driver, as well as a high performance commercial solution. The Paragon solution is used by Asus's MIPS routers, as well as a number of other router and NAS manufacturers (such as Asustor). WD also uses it for the WDTV.

The performance of these commercial solutions is fairly decent. I can push my RT-AC88U to over 80 MB/s with it, over USB 3.0 (despite BCM's poor USB 3.0 design). What is usually more worrying is the reliability. Paragon used to be pretty bad at corrupting filesystems back to its 8.5/8.6 releases, for instance.

The performance of the open sourced products however is pretty average.

I have noticed that NTFS writes under Linux are a LOT faster than say 3 or so years ago.

I too had problems with data corruption using the Paragon driver. I haven't tried it lately though.