NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

forart
Posts: 1050
Joined: Mon Nov 29, 2004 1:36 pm
Location: Italy
Contact:

NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver

Post by forart »

OSNews.com wrote:Finally Linux has got full read-write open source NTFS support! Preliminary benchmarks show that the still unoptimized driver already sometimes twice as fast as ext3 and 20-50 faster than the commercial Paragon NTFS. Interestingly Captive NTFS, which uses the native Windows NTFS driver, fails all benchmarks with file loss.
Hope it helps !
»Forward Agency NPO
In progress we (always) trust.
keytotime
Posts: 51
Joined: Tue Jun 06, 2006 2:11 am

Post by keytotime »

Damm it you beat me to the post.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

There are many factors. I personally expect the new NTFS to get slower not faster. Not processing permissions yet. That does make a large difference on speed. Note it still should kick all the other NTFS systems for linux around the ball park.

Also someone need to learn how to read benchmarks its only faster than ext3 at deleting. Ext3 is not the fastest filesystem when it comes to deleting this can also be effected by a filesystem option. I hope the person did not enable secuirty deleting on ext3 because how much slow it got would be perfectly expected. Ie overwrite the file straight up.
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

NTFS-3G is just a FUSE driver (user mode). Read the related mailing list and then you will see that it has only partial write support and mess around with NTFS (so that you have to boot WinNT to fix the partition MFT, etc.).

... wait for the NTFS kernel driver for linux in development by an Apple dev (and former Linux NTFS team member). Even then, WinNT filesystem driver are different than linux one. A proper filesystem driver for (with I/O notify support, proper write, permission, encryption, streams, metadata, etc.) may need several devs and take a lot of time.
Plus we will also need some tools to maintain NTFS partitions/volumes (defrag, resize, etc.).
Megari
Posts: 15
Joined: Sun Jan 09, 2005 12:19 am

Post by Megari »

Read the related mailing list and then you will see that it has only partial write support and mess around with NTFS (so that you have to boot WinNT to fix the partition MFT, etc.).
I've been following the Linux-NTFS project quite closely and today is the first time I ever learned of NTFS-3G. Where is the mailinglist you're referring to, containing reports of it messing people's filesystems up (I've never heard of that happening with Linux-NTFS releases, although my common sense tells me there must be at least a few cases - nothing's perfect) and the write support of NTFS-3G still being only partial? I am disappointed in myself for not being aware of this effort and the discussion regarding it.

About partialness of the write support: according to the author's description, the write support seems to be complete at least for the normal use case (ie. no encryption or compression), with a high upper limit related to having to extend the MFT when the amount of files gets high. This limit seems to be somewhere around 100 000 according to the author, so it should be bearable until he implements MFT extension. For a measure of this limitation, my home computer used to have something like 30 000 files on its file system after years of use and practically no free space. This leads me to believe that at least a home user may not notice the missing functionality before the driver is already stable and has the feature implemented.

As a side note, one thing that once made my file system to gain a huge amount of files (more than 1 million) was when I extracted a complete freedb archive for whatever reason. If someone did that, the limit would undoubtedly be hit.

It seems Anton Altaparmakov (the head of Linux-NTFS and maintainer of in-kernel NTFS driver) is not completely happy with the current robustness and portability of the code (he is frantic about robustness and not causing corruptions because of the reputation the in-kernel driver got before he started Linux-NTFS). Unfortunately, it seems Szakacsits Szabolcs (a long-time Linux-NTFS developer, if I have not interpreted things incorrectly for the past years) doesn't see big-endian compatibility as significant as Anton and may even be a little bit hostile towards the notion of an NTFS kernel driver, citing it to be "a lost cause".

Szakacsits's view is quite controversial due to the well-known fact (which you mentioned) that Anton has said that he has already mostly finished a full-featured kernel space driver which he will make available next summer for MacOS X and Linux simultaneously. I hope they're not actually having a serious argument behind the scenes, causing the project to be irreversibly forked. Forking is not bad per se, but they are the two established FOSS experts in NTFS and not working on a common codebase would be quite unfortunate in terms of speed of development.
Plus we will also need some tools to maintain NTFS partitions/volumes (defrag, resize, etc.).
Yes, definitely. Resizing is already done (and argued to be more stable than any other implementations in existence), but defragging and file system checking are still missing. They will probably take another few years to implement.

Whoa. This turned out to be long. It seems I just vomited most of what I've learned about all of this on the screen. Sorry :)
Wag the dog.
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

I am tired today (it's late here), i will give you further links about what I read, tomorrow.
Megari
Posts: 15
Joined: Sun Jan 09, 2005 12:19 am

Post by Megari »

frik85 wrote:I am tired today (it's late here), i will give you further links about what I read, tomorrow.
Okay, thank you. Looking forward to it.
Wag the dog.
StringCheesian
Posts: 31
Joined: Mon Mar 28, 2005 11:37 pm

Post by StringCheesian »

The best part is it uses a simple API called FUSE to talk to the kernel. All the FreeBSD people had to do is implement FUSE and now this new NTFS driver (I've heard) is working on FreeBSD too.

Sounds like it shouldn't be too hard to port this to ReactOS...
Megari
Posts: 15
Joined: Sun Jan 09, 2005 12:19 am

Post by Megari »

It seems I have have already read everything you have. I am delighted to see that I have not missed anything regarding Linux-NTFS and NTFS-3G. Thank you for taking the time to gather all the links for everyone to see.

I thought you mentioned about hearing of either the official Linux-NTFS software or NTFS-3G messing up people's filesystems so that they need to reboot to Windows to fix the damage - I had not heard of such cases before and the links don't provide additional insights regarding that. Didn't such corruptions only happen with the ancient kernel driver when writing? Did I misunderstand you or is there a substantial body of such reports available somewhere?
Wag the dog.
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

Megari wrote:I thought you mentioned about hearing of either the official Linux-NTFS software or NTFS-3G messing up people's filesystems so that they need to reboot to Windows to fix the damage - I had not heard of such cases before and the links don't provide additional insights regarding that. Didn't such corruptions only happen with the ancient kernel driver when writing? Did I misunderstand you or is there a substantial body of such reports available somewhere?
I was a bit unclear, sorry.
http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697 wrote:Problem: Windows chkdsk may report minor inconsistency.
Answer: The allocation size of sparse files isn't set always correctly.
Workaround: No need.
Status: Normal priority work.
http://sourceforge.net/mailarchive/forum.php?thread_id=23836054&forum_id=2697 wrote:Problem: Only Windows Administrator can access the files created by
the driver.
Answer: File permission and ownership handling isn't implemented yet.
Workaround: As Windows Administrator, set access permissions for other
users.
Status: Solution exists but it needs to be revised and tested.
etc.

... maybe minor things, but enough to need "chkdsk" (and Windows) to check the partition/volume from time to time.

Additionally, I found some related comments of some linux ntfs devs, although I currently don't remember where it took place (i forgot the url).
SpoonmAn
Posts: 77
Joined: Mon Dec 19, 2005 6:09 pm

Post by SpoonmAn »

what about this ntfs-3g project now? looks like they have a stable version since feb 2007 now

http://www.ntfs-3g.org/index.html
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

Our position on it has not changed.
Speedator
Posts: 136
Joined: Sat Jun 17, 2006 4:42 pm

Post by Speedator »

Fuse for Windows would change the position or wouldn't it?
cppm
Posts: 289
Joined: Wed May 02, 2007 10:03 pm

Post by cppm »

Fuse for Windows would change the position or wouldn't it?
Well, that would change the position of whether NTFS-3g would be useful, yes, because it could theoretically be loaded once the system is compatible with whatever FUSE 4 win would be dependent upon.

But that's still meaningless, it wouldn't contribute anything to the ReactOS code, and ReactOS would still be unable to boot from NTFS, or use it natively, both of which are the entire point of creating an NTFS driver.

I personally think that ROS should implement NTFS, simply because it's a very good filesystem, and is easily extended. But we shouldn't neccesarily feel bound by windows compatibility here, if we want to extend NTFS, that should be an option, and if theres a simpler, i.e lower version of NTFS that works with both windows and ROS so much the better.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], DotBot [Crawler], Google [Bot] and 57 guests