NTFS-3G (FUSE)

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias » Wed Oct 18, 2006 11:13 am

frik85 wrote:If it "just works" for you and several other people, that's fine, but a filesystem is the single most critical part which has to be 99,9% bug-free and a very good performance. And alternative NTFS driver are not yet there.
I can't do anything but repeat that this isn't true. 10 000s of people have tested ntfs-3g, and up to now, there has *not* been a *single* case where ntfs-3g messed up an NTFS drive. If you say that ntfs-3g is not reliable, you must be able to prove it, or stop spreading FUD! Also, as Phalanx said already, the remaining bugs will be fixed soon anyway, most probably before a port to ReactOS would be finished. Besides that, i'm quite sure that ReactOS's FAT driver has bugs as well, and probably more serious ones than ntfs-3g.

As for performance, ntfs-3g achieves a very good performance already.

Code: Select all

Below are the averaged file creation, deletion and access performance
numbers got by running 'bonnie++ -s0' using several filesystems (the
benchmark used 16,000 files per directory in each sessions):

Version  1.03    ------Sequential Create------ --------Random Create--------
                 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
           files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
reiserfs     16k 21459  99 +++++ +++ 17856  96 20172  98 +++++ +++ 16414  96
jfs          16k  7015  13 +++++ +++  5868  10  3068  14 +++++ +++  1075   3
ntfs-3g      16k  3021  99 14291  99  5226  99  3548  99 16149  99  5223  99
xfs          16k  2401  17 +++++ +++  2095  15  2301  20 +++++ +++   347   2
ext3         16k  1862  96 +++++ +++ +++++ +++  1914  96 +++++ +++  9695  98
minix        16k  1450  97 +++++ +++ 18148  94  1694  97 +++++ +++  4847  98
fat32        16k   366  97 +++++ +++  1809  97   428  97 +++++ +++  1361  97
paragon ntfs 16k    58  98  1259  99   245  99    55  99 +++++ +++   832  99
As you can see, ntfs-3g can keep up well with many file systems in the Linux kernel.
And please keep your rude attitude at home!
I will, as soon as you fix the forum. You probably know about broken stuff already, so i guess there's not much point in telling you again.

jbond_00
Posts: 31
Joined: Fri Sep 08, 2006 8:08 am

sigh

Post by jbond_00 » Wed Oct 18, 2006 12:38 pm

The wiki says ntfs (read/write) support is due at 0.5.x. the question of where or not it is available now (windows ntfs driver) or available now as a *viable alternative (ntfs-3g, etc) is kinda pointless right now considering, as well as taking into account the previous statement. you could argue about it now, but why do so when time will "cure" all?

can a mod lock this tread? the original question has already been answered and, in its current state, no new info will be gleamed.

Matt

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Wed Oct 18, 2006 2:12 pm

Matthias I have to say this. Everyone in IRC knows this of me. I am a linux user/admin.

I know the limits and troubles of ntfs-3g first hand. Yes I have systems with lots of files.

Not a single case of it destorying a fileystem. True.

Many cases of it becoming a Read only filesystem without notice. Yes I have had that one happen. Ok lest just copy 10000 files accross opps nop that was a no go. Yes I am dealing with larger number of files that normal users. But normal users can get to my size in time.

ntfs-3g performance figures are completely useless.

Reason to work effectively with Reactos it will have to be ported from fuse to a normal windows filesystem driver. Most likely the Reactos driver will perform better. Also the reason why starting it before the ntfs fuse driver is working correctly is unlikely. This is a lot of work and a revision in the ntfs fuse driver could see a major rewrite in the ROS driver.

Note frik85 was right just was not clear enough.

NT Style kernel is different to a linux or freebsd one. Fuse style where running filesystem driver in user space is not practical in anyway with a NT style kernel.

Matthias I don't like insulting of people who have done a lot of work for a project. Be thankful with frik85 and people like him you would not have this forum to speek freely in. Even if a fault looks simple it can be really hard to fix. If you think you can do better than frik85 the web site source is in the svn go prove you self as better. If you cannot do not insult.

Sad bit both people where lacking knollage. One made the mistake of getting up on a high horse and insulting another.
i'm quite sure that ReactOS's FAT driver has bugs as well
Sorry to say no it does not. Its main bugs come from hacks that were done to it to make it work with defective parts in kernel most have been fixed and removed from it. IE patchs around defects that stops the normal MS NTFS driver from working. Its function does not have any strange limits. It will not suddenly change from read/write to read without running out of disk space.

Please keep your comments about reactos code faults to fact.

Fat is a lot simpler filesystem than NTFS. Also completely publicly documented. So if a developer stuffs it up they will have a lot of questions to answer. If you know of something wrong in the fat driver speek up now.

Major things wrong with the FAT driver is just the same limit problems the Microsoft FAT driver has.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 » Wed Oct 18, 2006 5:53 pm

One doesn't even need to be an admin of any kind to run over 100,000 files. A poweruser would easily do that.

And as much as I'd like an NTFS driver, it wouldn't do me much good if it can't handle that many and can't do mass writings/moving. But since ReactOS is a long way from becoming a viable, stable Windows alternative, this isn't a major issue until at least 0.5.0 for me, since it barely runs on any of my systems.

frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 » Wed Oct 18, 2006 7:17 pm

I have splitted the thread and moved the unix fuse related discussion away from the "FAT/NTFS" thread.
Matthias wrote:I can't do anything but repeat that this isn't true. 10 000s of people have tested ntfs-3g, and up to now, there has *not* been a *single* case where ntfs-3g messed up an NTFS drive. If you say that ntfs-3g is not reliable, you must be able to prove it, or stop spreading FUD!
Please read up again! I have spoken in generally!

I know about that project (ntfs-3g), since it has been on slashdot frontpage. I read a lot of mails in their mailing list, user reports and even tested it out myself.

58,000 downloads as the their "official" website http://mlf.linux.rulez.org/mlf/ezaz/ntf ... nload.html (Updated: October 16, 2006). But plain numbers proof nothing at all which is relevant of the project status, quality, etc.

As I said that I am convinced that there is no NTFS driver alternative which reached "gold-status".

Even sysinternals/winternals (now part of Microsoft anyway) NTFS driver for DOS and Win9x are not full-featured.

As it turns out, there is just a hype around 3g for a periode of time, a similar hype has happend as the news of capative went around.

100000 files are nothing. I have million(s) of files, as most of you too: applications, driver collected data (pictures, videos, documents of all sorts, etc.).
Some noobs may have just WinHome+Word/Works+20 doc files, but in generally people collect data over years and bought at least one additional harddisc.

Even my "Program Files" directory have way more than 100000 files and that's just a part of my windows partition.
I have installed an application which come with more than 75000 files (on another partition), it's an enterprise app.

Matthias wrote:Besides that, i'm quite sure that ReactOS's FAT driver has bugs as well, and probably more serious ones than ntfs-3g.
Afaik, only the setup format partition code is buggy, but not our fat dríver.

WinNT driver are a way more complex as unix file system "driver". WinNT filesystem drivers are real driver which sits not in the kernel. Beside that in NT world, the kernel don't know about too detailed info of filesystem at all. Every filesystem driver come with it's own implementation of a lot of "features".
e.g. I/O-notify
In unix clones/derivatives and most other operating systems, every new feature requiere a kernel improvement, altered API, etc. ... where-as in NT world it's just a matter of a improved driver. This advantage allows you to use 10+ year old filesystem (or what ever) driver in the NT world. Of course it may not be reasonable in most cases to use an early NTFS driver from NT 3, which was very unstable back then. But I think you get what I meant.

As almost everything, this advantages of NT filesystem driver (architecture), it comes also with downsides, coding a NT-filesystem driver is a non-trivial task and requiere men-years of development.
I will, as soon as you fix the forum. You probably know about broken stuff already, so i guess there's not much point in telling you again.
Make sure, the bugs you think of, are in the ReactOS Bugzilla, if not please file bug(s).
(forum frontpage login box, latest posts highlighting bug)

Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias » Thu Oct 19, 2006 3:07 am

frik85 wrote:58,000 downloads as the their "official" website http://mlf.linux.rulez.org/mlf/ezaz/ntf ... nload.html (Updated: October 16, 2006). But plain numbers proof nothing at all which is relevant of the project status, quality, etc.
If 60 000 tests without a single file being destroyed isn't enough, what is?
frik85 wrote:As it turns out, there is just a hype around 3g for a periode of time, a similar hype has happend as the news of capative went around.
There is no such thing as an unjustified hype about ntfs-3g. It's a working ntfs driver, that's ist. Nothing more, nothing less.
frik85 wrote:100000 files are nothing. I have million(s) of files, as most of you too: applications, driver collected data (pictures, videos, documents of all sorts, etc.).
100 000 files is not too much for a production system (my Linux Partition has about 300 000). However, ReactOS isn't ready for production systems anyway. ntfs-3g isn't perfect, but it's definately good enough for ReactOS, espepcially if you consider that this bug will probably be fixed soon (waaaaayyy before ReactOS 1.0, that is). Let's face it: the idea of having more than 100 000 on a ReactOS partition is currently quite ridiculous. ReactOS isn't being worked with, but it's being tested, and ntfs-3g is perfectly sufficient for that.
frik85 wrote:Afaik, only the setup format partition code is buggy, but not our fat dríver.
OK, now how many people have actually thoroughly tested the ReactOS FAT driver? 1000 at best. If you don't know any bugs in the ROS FAT driver, fine. That doesn't mean they aren't there (i'm willing to bet that they _do_ exist). The ntfs-3g driver was tested much more thoroughly and consequently probably has less bugs. Let alone the fact that to date it didn't cause _any_ data loss shows the high quality of this driver. ReactOS screwed up it's own partition dozens of times here.
frik85 wrote:WinNT driver are a way more complex as unix file system "driver". WinNT filesystem drivers are real driver which sits not in the kernel.
ntfs-3g doesn't run inside the kernel. I don't know about Windows' file system drivers.
frik85 wrote: Beside that in NT world, the kernel don't know about too detailed info of filesystem at all. Every filesystem driver come with it's own implementation of a lot of "features".
e.g. I/O-notify
In unix clones/derivatives and most other operating systems, every new feature requiere a kernel improvement, altered API, etc. ... where-as in NT world it's just a matter of a improved driver.
That is total, utter, stupid bs. Please, stop talking about things you don't understand, and stop spreading FUD about OSes you don't seem to know. Linux's file system driver APIs haven't been changed in a _looong_ time, even though new, exciting file systems like Reiser4 or ZFS are being implemented with it (ZFS for Linux uses FUSE though, but that doesn't matter). Yes it's true, that Windows file system drivers are more complex, but that is because Microsoft messed up their design ad made thatAPI much more complicated than necessery (there is about half a dozen different APis only for listing the content of a directory).
frik85 wrote:As almost everything, this advantages of NT filesystem driver (architecture), it comes also with downsides, coding a NT-filesystem driver is a non-trivial task and requiere men-years of development.
To me that translates to: "If someone starts to port ntfs-3g now, by the he'll finish, ntfs-3g's last bugs will have been fixed."

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Thu Oct 19, 2006 1:52 pm

Matthias the fat driver is one of the first drivers in reactos. So a lot of testing. Over 9 years of it. So its alot more than 60000 tests and and corrections. Its also the reason why its so bug free.

So if there is a bug in their please speek up in the Bugzilla. That section kinda needs a bug.

Matthias With fat driver it was used for a while installed side by side with Windows 98 machines and the like without trouble. A lot of people here whould expect the same effect from the reactos NTFS driver.

So it might be 90000 files Windows XP and 10000 files Reactos or even smaller.
ReactOS screwed up it's own partition dozens of times here.
So does windows on FAT or NTFS if the crash it at the right time.

Reactos 0.3.1 this will be a lot less likely. Most likely causes of kernel crashing out without giving filesystem driver a chance to complete write to disk. Note this will cause any filesystem driver to destroy a partition.

Nothing wrong in the Fat Driver causing the Partition fails these days other than the limits of Fat ie no journalling.

I still see people kill there USB keys in Windows or Linux due to the same problem. So reactos is not alone at destorying FAT32/16/12 media. Note I make good side cash from these. 20-100 dollars for the recovery. With tools normally only takes me 30 mins. 200 dollars a hour I don't sneeze at.

Ie FAT is a nasty bad filesystem. So Stop Trying to use FUD about the Reactos FAT driver. That is not going to win here.

Ok nice thanks I did not know that ZFS was part on linux. That might see the end of a solarias box.

It getting annoying. Please learn about the Windows NT Filesystem Drivers at least before making any more comments that frik85 is wrong.

Reiser4 and ZFS are posix style filesystems. Windows NT allows insane filesystems. All drivers under linux must use partical interfaces to talk to the filesystem to be compad with VFS.

Under Windows NT if a feature is not present in driver it will respond that its not avaible. The upper API is different to the Driver API.

So in one way Windows drivers are simpler. Problem is programs expect partical API's in the driver. NTFS-3G does not do NTFS secuirty completely either. There is still a lot of work to bring NTFS-3G upto standard.

Fat is one of the simplest Windows NT drivers you will find.

frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 » Thu Oct 19, 2006 2:19 pm

Matthias wrote: If 60 000 tests without a single file being destroyed isn't enough, what is?
... just guessing, right? Only a minor percent of people report failures back to the community. As I said that means nothing.
Matthias wrote:OK, now how many people have actually thoroughly tested the ReactOS FAT driver? 1000 at best. If you don't know any bugs in the ROS FAT driver, fine.
Visit the sourceforge project page of the ReactOS project for download stats. More than 150000 downloads of ReactOS 0.3.0 (~ 6 weeks) so far.
Matthias wrote:The ntfs-3g driver was tested much more thoroughly and consequently probably has less bugs. Let alone the fact that to date it didn't cause _any_ data loss shows the high quality of this driver. ReactOS screwed up it's own partition dozens of times here.
You speak of a user-mode driver on the one hand and a full operating system plus fat kernel driver on the other hand.
ReactOS undergoes kernel improvements which may break things which caused setup problems in trunk, etc.
You should try to differ and sort out things in your mind. The real world neither black nor white.
Matthias wrote:ntfs-3g doesn't run inside the kernel. I don't know about Windows' file system drivers.
... what are you talking about? ntfs-3g is a fuse plugin/driver and cannot be compared with rock solid kernel mode drivers (for NT, unix, what ever).
Matthias wrote:Linux's file system driver APIs haven't been changed in a _looong_ time, even though new, exciting file systems like Reiser4 or ZFS are being implemented with it (ZFS for Linux uses FUSE though, but that doesn't matter).
inotify anyone? ... a kernel update just to support features which have been available for decades elsewhere.

(and I haven't mentioned support for cluster FS, SCSI hacks, etc.)

Reiser(FS)4 need(ed) a ext2/3 compatible metadata and rights management, and xttr so that beagle & co. will work.
Matthias wrote:Yes it's true, that Windows file system drivers are more complex, but that is because Microsoft messed up their design ad made thatAPI much more complicated than necessery (there is about half a dozen different APis only for listing the content of a directory).
In NT world, you have to differ WinAPI with native NT-API. Win32 is just a subsystem.
In *nix you have no layer between and have to use more or less posix compatible functions and system own additions.
NT fs driver are more feature-rich and can achive things which would requiere in unix world a kernel change, as I already wrote above. This implies that each driver need it's own e.g. i/o notify code
Matthias wrote:That is total, utter, stupid bs. Please, stop talking about things you don't understand, and stop spreading FUD about OSes you don't seem to know.
I don't like rude comments and additionally if someone deny clear facts.
It clearly shows that you are a user of that filesystem driver, and you may not have deeper understanding how things internal work (especially NT world things).
Please calm down, your comments had often a fanatic and/or rude touch in the past. We don't want "wars" in the ReactOS community and other fanatic, rude, religious, etc. behaviours.

Most of us want a NTFS driver for ReactOS, but it's not that easy as some of you think.

Locked

Who is online

Users browsing this forum: No registered users and 4 guests