Hope it helps !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.
NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Moderator: Moderator Team
NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
»Forward Agency NPO
In progress we (always) trust.
In progress we (always) trust.
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.
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.
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.).
... 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.).
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.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.).
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.
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.Plus we will also need some tools to maintain NTFS partitions/volumes (defrag, resize, etc.).
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.
-
- Posts: 31
- Joined: Mon Mar 28, 2005 11:37 pm
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...
Sounds like it shouldn't be too hard to port this to ReactOS...
Scroll down and read, the comments explains a lot, the FAQ too:Megari wrote:Okay, thank you. Looking forward to it.frik85 wrote:I am tired today (it's late here), i will give you further links about what I read, tomorrow.
http://sourceforge.net/mailarchive/foru ... um_id=2697
Several useful links with further information:
http://www.kernel-traffic.org/kernel-tr ... makov.html
http://rpmfind.net/linux/RPM/Anton_Alta ... .net_.html
http://marc.theaimsgroup.com/?l=linux-n ... 707733&w=2
http://marc.theaimsgroup.com/?t=114902070100003&r=1&w=2
http://apple.slashdot.org/comments.pl?s ... d=14787915
http://lists.freebsd.org/pipermail/free ... 04828.html
http://www.pro-linux.de/news/2006/9915.html (german)
http://lists.apple.com/archives/darwin- ... 00026.html
http://lwn.net/Articles/89720/
http://article.gmane.org/gmane.linux.fi ... devel/2597
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html
http://www.cgsecurity.org/wiki/TestDisk
http://www.linux-ntfs.org/
http://fuse.sourceforge.net/
http://www.amazon.com/gp/product/1565922492/
http://www.microsoft.com/whdc/devtools/ ... fault.mspx
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?
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.
I was a bit unclear, sorry.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?
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.
etc.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.
... 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).
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
http://www.ntfs-3g.org/index.html
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.Fuse for Windows would change the position or wouldn't it?
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.
Who is online
Users browsing this forum: Bing [Bot] and 56 guests