Fully Open Source NTFS Support Under Linux 310
lord_rob the only on writes "The Linux NTFS project has released a beta version of its fully open source userspace (using FUSE) 3G-Linux NTFS support driver. According to the developer, this driver beats hands down other NTFS support solutions performance-wise (including commercial Paragon NTFS driver and also Captive NTFS, which is using windows ntfs.sys driver under WINE)." That's right, writing to NTFS even works. Soon it'll mean one less recovery disk to keep around, I hope.
Re:Yay (Score:2, Insightful)
Re:Not Just Linux (Score:3, Insightful)
Re:Yay (Score:2, Insightful)
Comment removed (Score:5, Insightful)
Re:Performance (Score:3, Insightful)
Re:Awesome! (Score:3, Insightful)
From TFA, The driver currently is in BETA status: before release of this software we haven't experienced any driver crashes or data loss during our heavy quality testing, however we are aware of some minor issues which will be resolved in the near future.
It's still in beta. While it's a GPL'd beta, and probably far more stable than beta implies. It's still beta, and you should expect it to bug out from time to time (whether or not this is actually the case.)
So, if you have it when it bugs out as a kernel module you get a kernel panic. I don't like kernel panics, and you shouldn't like them either. So keeping it to the userland is probably best for now. Do you really need it as a kernel module?
Re:Awesome! (Score:3, Insightful)
Re:Great news. (Score:5, Insightful)
Cue drumroll for New! Improved! MS file system (Score:3, Insightful)
If I were Microsoft, I'd make just enough undocumented changes to screw up reverse-engineered implementations of NTFS... providing just enough increased functionality to which I could Point With Pride.
I might even called it WinFS 2007 or WinFS X-Treme or Enterprise WinFS. It wouldn't have anything to do with the real WinFS... anything more than Javascript had to do with Java, or Mac OS 9 had to do with Copland, but it would certainly muddy the buzzword waters.
Imagine a meeting with nerds and suits present in which the nerds make the mistake of mentioning Microsoft's failure to deliver WinFS, the suits would wave their magazine and say they had, then drum their fingers, yawn, and look at their watches while the poor nerds try to explain the complex technical issues and how WinFS was supposed to therblig the frammistan while WinFS Gold merely globulorns the ferthbernder.
Re:This is great news (Score:4, Insightful)
Result? We were and are still playing catch up depending on who you speak to.
It is good news ... But ... (Score:5, Insightful)
But, keep in mind that NTFS remains proprietary and Microsoft can break it for newly written files any time it suits their business purposes to do so. All it takes is one update.
No one but me seems to care about this, but I think that the proprietary and undocumented nature of NTFS is an important reason why System Administrators need to have a workable exit strategy for Windows. They don't need to exit now. But in three or five or ten years if (when) Microsoft decides to lock in its user base, users should want to make sure that they have the option of being outside the door that Microsoft is slamming shut.
Re:Performance (Score:2, Insightful)
Re:It is good news ... But ... (Score:5, Insightful)
Hypothetically, yes. However, there are few things that they -- or any OS developer -- are more paranoid about altering than the filesystem. You can recover from a bad driver, or a bad patch for most functions; recovering fully from a bad filesystem alteration may be nigh-on impossible, and Microsoft is going to think really, really hard before they go and do something that may result in lost data.
Re:Performance (Score:1, Insightful)
That's 20+ years of Microsoft support and Linux still beats it.
Just because an FS is M$'s baby doesn't mean they know how to treat it right.
Re:My thoughts on this... (Score:5, Insightful)
Re:This is great news (Score:4, Insightful)
One nice thing is that Microsoft can't change things willy-nilly with NTFS as it could with, for example, the Word file format. The worst problem with NTFS write support is that a naive driver can cause data corruption. Once the free/open-source driver is sophisticated enough, there won't be much Microsoft will be able to do to exclude it, except by adding new optional features. There will come a point where anything that Microsoft does to break the free driver will also break older versions of its own drivers. Microsoft can't really afford to let that happen, since once thing businesses will not tolerate is a file system that arbitrarily loses data, especially since NTFS is currently viewed as being very stable in the Windows-using world.
Breaking filesystems is much more drastic than breaking network protocols. The only thing that Microsoft could do that would effectively deter users of the free driver is to make it (and any older version of Microsoft's own NTFS drivers) cause data corruption. Even Microsoft isn't stupid enough to do that.
Re:Performance (Score:3, Insightful)
It's a widely-believed myth, mainly due to the poor performance of bloated first-generation microkernels
No, it's a widely-proven fact. Now, it may be possible to have a decent performing microkernel, but to dismiss performance problems as a "myth" is disengenious at best.
some people are actually devoting much of their time to solving these problems.
Exactly. "solving", implying that performance problems are hardly a solved issue. Now, I'm not here to knock microkernels -- they certainly have their place, and the advantages may end up outweighing the performance problems (as high level languages did with assembly language), but microkernel advocates really need to get over their oversensitivity on the issue. Screaming "myth" when everone's experience is to the contrary does your movement no good.
Advocates ought to be saying, "Yes, microkernels are slower than monolithic kernels and probably always will be due to their nature, but with care the cost can be minimized, and we believe the clear benefits outweight the cost.
That's at least a debatable statement.
Re:No 64-bit (Score:3, Insightful)
I would have thought that fiddling with bitwise data structures on disk is pretty much one of the cases where endianness and word size is very relevant. I mean, I could be wrong.
Hmm. Let's try reading a 32-bit value from the disk surface and masking out the top 3 bits (random file-systemesque example chosen off the top of my head). Yep, I reckon you'd have to go out of your way to make sure that it did work across platforms with different word size or endianness. It's not exactly hard, but you'd certainly have to go out of your way.
Especially as I'm guessing the number of times this driver has been run on a Linux PC that is not a 32-bit Intel x86 machine is currently close to zero, given the typical application of this software.
Re:It is good news ... But ... (Score:3, Insightful)
Because every web developer in the world needs direct write access to any where they like on the hard drive, that doesn't have permission controls of any kind.
Re:My thoughts on this... (Score:2, Insightful)
Re:Performance (Score:2, Insightful)
He says that are basically only a few basic classes of drivers that you need this kind of complexity for, I imagine extending one for your particular filesystem, hardware, etc is a lot easier than having to write one from scratch each time.
Re:Great news. (Score:4, Insightful)
Re:Performance (Score:2, Insightful)
come on! The GP clearly said:
Look at the keyword "fundamental" here, THAT's the myth and the fact that several people, AST being one of them, have proven that there is no such "fundamental" difference is the "fact" here. Even coming up with a long list of examples where the performance is actually worse does not mean a thing, it might just mean it's very difficult or that no microkernel has ever gotten the same kind of attention as monolithic kernels.
Go read some of the work being done on microkernels, jeez just reading http://en.wikipedia.org/wiki/L4_microkernel_famil
That's why people are screaming "myth" because people like you have already made up their mind and keep repeating the same old adage when it just isn't true.
Re:Great news. (Score:3, Insightful)
You would, of course, have to have a copy on your recovery disk. The first thing I would expect a rootkit to do is patch the NTFS driver, so relying on the infected one would not be a good idea.
Re:No 64-bit (Score:3, Insightful)
I refer you to your original comment:
and then your supplied code:
That code looks like it's going out of its way to deal with endian issues to me.
As I said, it's not hard, but it's not free either. Perhaps we should just agree that your original comment was hyperbole and leave it at that.
Re:It is good news ... But ... (Score:3, Insightful)
Take off the FUD hat and re-read what you wrote there. Do you really think that trashing 1%-2% of the install base would be smoothed over with a patch?
Back in 2004, when SP2 was released, the estimated installation base for XP was more than 250 million systems. Throw in Windows 2000, plus growth since then, and I would think that a conservative estimate of 400 million 2000/XP/2003 systems wouldn't be out of line. The suggestion that four to eight million systems -- servers included -- could lose data and that Microsoft could just release a few new bytes to handle it is ludicrous at best. Microsoft would be hit with a class-action suit -- and deserve it -- for taking out so many systems.
You can break drivers. You can break compatibility. You can even break mainboard hardware. In each case, people will move on. But when you break people's data, forgiveness is often impossible to find.