Slashdot Log In
Fully Open Source NTFS Support Under Linux
Posted by
CowboyNeal
on Sat Jul 15, 2006 09:33 AM
from the long-time-coming dept.
from the long-time-coming dept.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Great news. (Score:5, Interesting)
Re:Great news. (Score:5, Informative)
Of course, the more tools you have available to you, the better, and while it's very unlikely that a rootkit from one install can infect another as long as you're careful, it's *extremely* unlikely that it'll be able to infect a Linux install. That may change with time, of course - as with so many things, it's an arms race, and this one is unlikely to do anything but get hotter.
Parent
Re:Great news. (Score:5, Interesting)
Interesting approach: install VMware Server (free), install Windows into a VM (free if you have 2003--IIRC*, Microsoft allows 4 instances, 1 host and 3 virtual), then connect the physical drive to the VM. Not sure whether VMware will bypass the drivers and allow you complete physical access as I haven't tried it but that's one of the options when creating a new virtual hard drive.
You probably don't want to run the VM from the same drive that you attach to it, though... I haven't tested this, but it might be a nice option for investigating without taking down any services that may happen to be running on the potentially-infected PC.
* -- is this the sound made by a crashing car?
Parent
Re:Great news. (Score:4, Insightful)
Parent
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.
Parent
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.
Parent
Re:It is good news ... But ... (Score:5, Informative)
Parent
EVEN BETTER NEWS (Score:3, Interesting)
A given distro can now come with a handy Windows InstallShield Wizard and INSTALL UNDER WINDOWS and BOOT/SHARE the same partition.
This is huge. Who wants to be the first to make a Linux ActiveX malware distro?
Re:Great news. (Score:5, Informative)
Parent
Re:Great news. (Score:5, Insightful)
Parent
Nothing for you to see here. Please move along. (Score:4, Funny)
Is Slashdot testing out the NTFS writing ability on their site?
We always could write to NTFS (Score:5, Funny)
It's really fast, despite being in userspace, though it can still take a while because there is so much that it needs to do. Start it before you leave work, or before you go to bed.
As a side effect, your NTFS partition will finally be free of spyware. It's the only way.
Parent
Re:We always could write to NTFS (Score:5, Funny)
Parent
Performance (Score:5, Interesting)
Unless I missed it, I notice the performance numbers are only single process. I'm suspicious of this because user-mode filesystems (as under microkernel operation systems) typically crash and burn performance-wise under simultaneous load, not under single-user use.
I know that user-mode is easier to debug, but they really should turn this into a kernel module.
Re:Performance (Score:5, Insightful)
Sure, user-mode will be a performance issue, but I think the context-switch + work is only necessary, when the kernel decides to either read data (on a cache miss) or write out its file buffers to disk. So if you don't use NTFS as your native disk (not sure how that'll work with permissions and stuff), you should really by fine. Maybe there's an option somewhere to turn on big read-write chunks (so that the kernel will always read/write huge blocks from the user daemon, which would make context-switch time negligible).
Parent
Re:Performance (Score:3, Insightful)
Re:Performance (Score:4, Interesting)
For the purposes of making a dual-boot system less painful, it's great. Now all we need is a Windows driver for Reiser...
Parent
Re:Performance (Score:3, Interesting)
Any sources or references for that?
Performance problems are a well-known fundamental problem with microkernel architectures that use user-mode processes. If you're interested in the subject, there are lots (and lots) of discussions about it (hint: your instincts above are wrong). Google is your friend.
Re:Performance (Score:5, Informative)
It's a widely-believed myth, mainly due to the poor performance of bloated first-generation microkernels like Mach, although I suppose it probably also applies to Linux when Linux acts as a microkernel.
Just because Linus Torvalds thought something was impossible during the 1990s doesn't make it so, so I suggest you skip the infamous Linus vs. AST discussion from that time period.
The reality is that:
Unlike Linus, some people are actually devoting much of their time to solving these problems. AST is one such person. See this page [cs.vu.nl] on the subject.
Parent
Re:Performance (Score:4, Interesting)
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.
AST himself said at the site the poster above linked to, "In this paper we argue that for most computer users, reliability is more important than performance and discuss four current research projects striving to improve operating system reliability."
If performance is exactly the same or better than monolithic kernels, as you claim, why would AST make an issue that reliability is more important than it, unless performance WAS an issue? Why wouldn't he write a paper titled, "Having your cake and eating it too... better performance AND better reliability. Why microkernels have won the war."
The answer is because they AREN'T and NEVER will be for general purposes. Sure, you can find isolated tests or isolated projects where they might do better (and the cost of doing better is generally insane complexity), but it's just foolish to argue that they're anywhere close in performance in the general case.
Look, extraordinary claims require extraordinary evidence. Show me the big database servers running on microkernels. Show me the big web servers. Show me big mail servers. And show me how the performance compares to the monolithic kernel operating system on the same hardware.
Sure, microkernels "work", but who cares? I can get DOS to "work". Show me something that works *better*. Or to put it another way, when microkernels are truly better, you won't need to sell everyone, they'll sell themselves. So far, they haven't for general purpose operating systems that care about performance.
Parent
Re:Performance (Score:5, Informative)
Wow, I don't know where to start with this. First, mod parent down using -1, vague.
Have you written a filesystem? I have. The "virtual memory" you're apparently referring to is the process' virtual memory. This sounds like what you're trying to say is that the protection provided by process virtual memory isn't available in the kernel. And that's true. But that doesn't change the fact that the kernel can map any physical memory to any effective address. So the statement that the "kernel can not use virtual memory," is extremely bogus. ("Bogus" is a technical term. It means "completely wrong.")
Concerning "explicit multithreading," you must be referring to the idea that the kernel can't call pthread_create()? But there's no reason for the kernel to do so. Multi-threading in a user-level process is often done to achieve concurrency related to the delays that a single-threaded application would have if it had to wait for I/O to complete. The kernel doesn't have to do that at all. The kernel would queue up the I/O request, then continue on its merry way. When the interrupt from the device signals that the I/O has completed, a separate handler takes care of it. In a user process, threads are useful in order to modularize the I/O functions. In the kernel, they often aren't needed, since callbacks are used instead. Same functionality, different design technique. And even if they are needed for some obscure reason, all modern kernels (Linux included) support kernel threads. (My SUSE Linux 10 box currently has 19 kernel threads executing.)
The "advanced algorithms" you're referring to are probably coming out of user-space libraries. And in this regard, you're correct -- user-space libraries cannot (currently) be linked into the kernel and there is plenty of debate about whether such abilities should even be attempted. (The problem with user-space libraries inside kernel space revolves mostly around bugs and implementation deficiencies. The truth is that an algorithm that is mostly cpu-intensive probably could be loaded into kernel space using some kind of hack, and there are open source projects that are already working along these lines.)
In any case, there's no reason why those algorithms couldn't be executed inside the kernel. For example, take the find() generic algorithm from the STL (a macro from one of the libraries you mentioned). Why can't I use it? (The truth is I can.) And why can't I use the list class from the same library? I admit that linking large objects into the kernel could result in quite a bit of bloat, but there is not a technical reason that it couldn't be done. (Except in the case of C++ exceptions within the kernel. There is a group that has patches available for the Linux kernel that add support for C++ exception handling. With those patches, any STL code should be able to work in kernel space, although I've not tried it personally.)
It seems to me like the parent has read a magazine article and jumped to conclusions. Or perhaps they are even an experienced developer, but took huge liberties with the wording of their statement. But as "Captain Obvious," I felt it was my slashdot civic duty to clarify he issue. :)
Parent
Not Just Linux (Score:5, Informative)
Re:Not Just Linux (Score:3, Insightful)
Re:Not Just Linux (Score:4, Informative)
I changed the motherboard in my Windows machine once, but didn't reinstall the OS straight away - was curious if it would 'just work'.
I was running a dual boot Windows 98 and Windows 2000 system.
Windows 98 booted up and said "Crikey chief! It's all changed!", then had a bit of a scurry, and rebooted.
Then it did it again.
And again. And again. And again.
Then it worked.
After 5 reboots all my hardware had been auto-detected and configured, and Windows 98 was ready to go. I never had any problems with the installation after that.
Then I booted to Windows 2000. It crashed out in the text mode boot screens and died in a flaming heap, telling me I'd committed some heinous act or other. I never got it past that. In the end I did a clean install of Windows 2000.
I was impressed with 98, not so much with 2000. Surprising, as I'd fully expected the opposite result.
Parent
Re:Not Just Linux (Score:4, Informative)
For W2k and XP (not sure about NT) there are basically 2 drivers which it absolutely needs to be able to boot. One is the graphic driver, which has fortunately a fallback to generic VGA. The other is the disk driver, so if you change your board to one with a different hd controller (for typical setups that means different chipset, though you might get lucky if it's a different chipset but which can use the same driver, dunno) then it will not boot. There are documented ways around this (for instance in the MS knowledgebase), though yes if you ask me it's really lame that there is no generic ide fallback. Apart from that board swaps seem to work pretty well with W2k (even though not recommended by MS), of course you might need to change hal (uniprocessor to multiprocessor and such things) and other drivers later.
(Actually IME hd cloning / swapping is more problematic due to recognition of drives with some unique identifiers)
Parent
No 64-bit (Score:5, Informative)
Problem: Why doesn't the driver work on 64-bit and bigendian systems?
Answer: We have no resource for that. Neither hardware, nor workforce.
Status: Low priority.
Awesome! (Score:3, Funny)
Re:Awesome! (Score:5, Informative)
Currently I'm not interested in the kernel driver. It's a lost case for over a decade. Full read-write could be done in user space pretty fast and I can't see drawbacks, only benefits:
- NTFS is huge and complex, not for the kernel. Crash in kernel (hw error, corrupt ntfs, etc) and game is over. Crash in user space then just restart the service.
- kernel has a lot of limitations, restrictions which are all gone.
- fedora/redhat users have never ending hassles with installing the driver. Instead they could install ntfs-3g once and forget the issue forever.
Parent
That's a pity (Score:5, Funny)
Parent
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 mo
Re:Awesome! (Score:3, Insightful)
Re:Awesome! (Score:4, Informative)
Then reboot from the CD and reformat the drive.
Sometimes the partition software can get confused by what's there, and the kernel will cobble up reasonable information about the drive from the drive's response itself.
Of course if you want to preserve your NTFS partition that's not a good approach. However, I've had bad luck with resizing windows partitions, so my approach is to backup, reformat, reinstall, and reload from the backup.
Parent
Re:Awesome! (Score:3, Informative)
Re:Awesome! (Score:5, Informative)
Assuming partition tables are "fubar".
#1 BACK UP ALL YOUR DATA. This is normally a sign of a failing drive.
#2 Download and burn a bootable CD of you hard drive vendors diagnostic kit.
#3 Run it, and "recertify" your drive. May take a couple of hours (and, you may just want to dumpster the drive, if your time is valuable). If the drive does not certify, discard it.
#4 Boot your system with Knoppix, or another recovery Linux system. Issue the command: "dd if=/dev/zero of=/dev/hda" (replace hda with hdb, hdc, hdd, etc. depending on which hard drive it is).
#5 Run Linux partitioning tool "fdisk
#5b Alternatively, boot a Linux installation CD, and load Linux. Ignore warnings about "improper partitioning", and choose to have the partition table replaced.
The IMPORTANT steps are 1 to 3. If the partition table cannot be manipulated, it is an almost sure sign your drive is heading south.
Ratboy
Parent
Re:Awesome! (Score:3, Informative)
Time to change my main partition... (Score:3, Funny)
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.
Is it stable? (Score:3, Informative)
FUSE is too slow (Score:4, Interesting)
When the ntfs driver is stable, I hope it will be put in the kernel (at least as a native file system). Then we can consider adding a unix layer on it and install linux to the same drive as Windows, for those that want to dual-boot.
Now it's time to... (Score:5, Funny)
Ubuntu Install (Score:4, Informative)
http://www.debuntu.org/2006/06/26/71-fuse-253-for
I've installed that on my desktop machine and managed to mount my ntfs drive (for dual boot) and read files. I didn't try to write anything yet, though. It seems to work fine.
Enjoy!
WRONG - ntfs-3g != ntsfmount (Score:4, Informative)
Parent
Re:This is great news (Score:4, Funny)
Parent
Re:This is great news (Score:4, Insightful)
Result? We were and are still playing catch up depending on who you speak to.
Parent
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.
Parent
ntfsmount != ntfs-3g (Score:5, Informative)
Parent
Re:My thoughts on this... (Score:5, Insightful)
Parent
Re: My stealing of this... (Score:4, Funny)
Now excuse me, I have to go to my (obviously stolen) kitchen and steal me a sandwich. The flavor is peanut butter crime.
Parent
Re:use ext3 in windows instead (Score:4, Informative)
Parent
Re:Yay (Score:4, Interesting)
NTFS was actually launched in 1993, 13 years ago, when Windows NT 3.1 (really 1.0, but the version was matched to the MS-DOS-based Windows 3.1) was released.
It's interesting to note that this means XP (which identifies itself internally as NT 5.1) is actually NT release 3.1.
3.1 is typically the best version of any microsoft product (except DOS; 3.3 was generally regarded as better). Version 4 (e.g. Win95, DOS 4.00,
So, when Vista flops, what are MS going to replace it with?
Parent