Originally Posted by RealNC
Stores file owner↓
POSIX file permissions↓
Last access/ read timestamps↓
Last content modification timestamps↓
This copy created↓
Last metadata change timestamps↓
Last archive timestamps↓
Access control lists↓
Security/ MAC labels↓
Extended attributes/ Alternate data streams/ forks↓
Maximum filename length↓
- NTFS: 255 characters
- EXT4: 256 bytes
Allowable characters in directory entries↓
- NTFS: Any Unicode except NUL and \ / : * ? " < > |
- EXT4: Any byte except NUL and /
Maximum pathname length↓
- NTFS: 32,767 Unicode characters with each path component (directory or filename) commonly up to 255 characters long
- EXT4: No limit defined
Maximum file size↓
- NTFS: 16 EB (16 × 10246 bytes)
- EXT4: 16 GB to 16 TB
Maximum volume size
- NTFS: 16 EB
- EXT4: 1 EB (but user tools limited to 16 TB)
File Change Log↓
Volumes are resizeable↓
Right off hand RealNC, I think you would be the clueless one.
Okay, in all fairness, this listing isn't entirely accurate. For starters I'm referencing WikiPedia, which like RealNC, isn't exactly known for it's accuracy. Most of the listed data seems to check out.
Another problem is that the NTFS entry isn't exactly accurate. Let me explain.
While most file-systems have a clear pedigree of development, NTFS does not. Microsoft obscures their own NTFS version history. While there are some technical documents outlining Versions 1.0, 1.1, 1.2, 3.0, and 3.1, there are additional versions such as 5.0, 5.1, 5.2, 6.0, 6.1 that have also been mentioned.
These updated versions of the NTFS file system often ship with new editions of Microsoft Windows releases. These new versions may, or may not be, backwards compatible with previous Microsoft Windows Operating System installations.
Now, from a purely factual point of view, based on the available documentation, the only real advantage NTFS has is it's size capacity. NTFS 6.1 will address up to 16 Exabytes. EXT4 will only do 16 Terabytes.
However, EXT4 isn't targeted for that market. For tasks that require that much data storage NTFS's opponent would be BtrFS, where NTFS is, in factual terms, way behind. Pretty much every-place that NTFS has a "NO" or a limit, BtrFS has a "YES" or "Work-in-Progress"
To be blunt, the comments from Tuxera, and RealNC in this thread, are a "Mug's Game"
Other forum posters have already singled out one specific problem. Are the Tuxera benchmarks being run within a manufactured environment, or are they benchmarks that reflect daily use?
This raises other questions, such as:
Do the Tuxera benchmarks implement the full range of features NTFS offers, or do they only reference the features exposed in non-commercial editions of Microsoft Windows?
Do the Tuxera benchmarks cover all known versions of the NTFS file system, or do they cover a specific version of the File System?
Until these questions are answered no performance judgment can be made.
Now, as to NTFS as a file-system itself. Keep in mind that when NTFS 3.0 hit with Windows 2000, Microsoft could afford to hire, or in some cases blackmail, the best file-system engineers on the planet to work for them. Yes that was a non-subtle reference to the fact that the Microsoft Corporation is a Convicted Felon.
As a file-system NTFS is indeed competent and competitive. However, that is all that NTFS is. A competent competitor. NTFS is not, by anybody's imagination, a file-system that is years ahead of any other "modern" file-system.
Keep this in mind. The EXT4 specification was announced in 2006 and was stabilized in 2008.
Windows 7 launched a year later in 2009. Despite an extra-development-year on Microsoft's part, the NTFS 6.1 version only has one major advantage over EXT4. NTFS will do 16 Exabytes. That's it.
On top of that, EXT4 retained backwards / fowards compatibility with EXT3: http://www.ibm.com/developerworks/li...xt4/index.html
Take that how you will.
No news here...
I would think that anyone could make a sloppy filesystem really really fast. Right? I mean, who cares? NTFS fragments like crazy... why is this good? Who cares if this performs slightly better... you know that tomorrow it won't.
Originally Posted by RealNC
Unix filesystems have had ACL support for years and Linux has for about a decade. Practically no-one uses them because they're so easy to screw up in a manner which will make your system pretty much impossible to fix. If I remember correctly, the Unix-style file permissions were created precisely to eliminate the hassle of dealing with ACLs on older operating systems.
BTW, you do realise that NTFS was 'invented in the previous century', right? As were ACLs?
Well, we all know that MS security is just a practice in smoke and mirrors anyway. No need to worry about what is effectively not really there and certainly nothing to be afraid of. Whether it is a very complicated execution of smoke and mirrors is besides the point.
I find the claims of superior performance to be a bit out to lunch. When all is said and done, you can't go faster than the actual physical media, and existing filesystem performance isn't so far behind that you could even remotely expect such massive improvements. Somewhere along the line, someone is faking the numbers, or the numbers are selected very very specifically in order to generate misleading results.
This "Anton" is just blowing out of his ass. There's no news here, its just nonsense claims about a proprietary driver that might not even exist.
190mb/sec sounds just like the data never hits the disk.
Hadn't thought about it, but yes. Moreover the storage medium being used is not reported.
Originally Posted by energyman
Its worse than that... by a factory of 8.... They're claiming BYTES, not just bits.
Originally Posted by energyman
NTFS-3G is already quite fast; my Freecom 80GB USB disk works with 25 MB/s write speed using Linux. On Windows it writes at 20 MB/s, using exactly the same laptop. (The limit is not the disk on the other side of the copy; the Western Digital 250GB of my laptop can read files much faster)
I wouldn't put too much relevance on your observations regarding your USB disk. The bottleneck there is the USB, not the filesystem driver or disk. Speed difference between windows and linux there is more likely a function of the USB driver.
Originally Posted by AlbertP
What is this "smoke and mirrors" game that you are talking about? I mean in particular, not some vague accusation about NTFS. What about its security model is "smoke and mirrors"? And don't claim that the fact that pre-Vista Windows tended to have home users run as admin, or that Vista and later have UAC to allow elevation necessary to operate on files the user doesn't have permissions on. That's a shell, user policy thing, not an issue with NTFS.
Originally Posted by droidhacker