Trying to mount an NTFS partition in Linux that was left hibernated by Windows can create a real mess.
No, it can not. Read-only mount is allowed but read-write mount is refused unless the 'remove_hiberfile' mount option is specified.
Microsoft designed hibernation in mind for the case when the hibernation file must be removed and they ensure that the filesystem remains consistent. They didn't do it for Linux interoperability but for themself when they are not able too boot otherwise.
Yes. And sadly FAT and ext3 is even slower. There can be many explanations for slowness, some are apparently explained on http://www.ntfs-3g.org/support.html#slow
The free NTFS-3G driver is slower than the commercial, also FUSE based one which overperforms stable kernel file systems, except ext4. Most file system requests are served by the FUSE kernel module without any user space involvement.
FUSE is a kernel module, a user space library (libfuse), a user space helper application (fusermount) and a user space helper script (mount.fuse). Well, at least:-)
"FUSE defeats the entire purpose. ZFS is meant to run and support a large/huge file store. What admin in their right mind would do that through userspace unless it's solely for backup?"
Who doesn't want his system to crash when a transient hardware error hit non-redundant ZFS kernel code.
The original NTFS-3G source code doesn't compile on Mac OS X without some changes but the MacFUSE and NTFS-3G precompiled packages are available from IUseThis.
It's called NTFS-3G: http://www.ntfs-3g.org/
The documentation is the binary ntfs driver, chkdsk and the NTFS on-disk file format one can find on any Windows box. These are the *REAL* documentation, which are *MUCH* detailed than any technical specification could ever be.
NTFS-3G has full read-write, open source NTFS support for a few months: http://www.ntfs-3g.org/
Fedora Extra, Debian, Ubuntu and many others have it already.
Feb 24, 2005: Ubuntu 5.04, codenamed "Hoary Hedgehog", is the newest distribution that added support for non-destructive NTFS resizing during installation by the use Partman and ntfsresize. Here is how you can do it when the [Partitioning disks] screen appears:
1. Choose the "Manually edit partition table" option.
2. Choose the NTFS partition you want to resize.
3. Choose the "Size:" line.
4. Choose if you are asked about "Write changes to disk and resize the partition?".
5. Enter the new size.
6. Please wait patiently until the resize process frees the needed space for Ubuntu installation.
Knoppix uses the rewritten NTFS driver which supports loopback read-write mounting a file on NTFS. Nothing new, the now also dead Phat Linux already did the same in 2002 with the same open source kernel driver. Currently the most popular "run Linux from NTFS" distribution is TopologiLinux.
It's not as easy to destroy all data as usually thought. In theory, three things might go wrong during resizing an NTFS partition and setting it up for dual boot,
1. NTFS resizing by ntfsresize.
2. Repartitioning by fdisk, cfdisk, Parted, QTParted, DiskDrake, YaST, etc.
3. Boot manager setup using LILO, GRUB, etc.
In all cases, we have met, the problem was introduced in either step 2 or step 3 and not by the use of ntfsresize. In most cases this means, your data is still intact but you can't access it.
Most often a Windows boot problem occurs if one edited the partition table by Parted version less than 1.6.12 or a libparted based partitioning tool. This is especially true if a Linux 2.6 kernel was used. The Linux 2.6 kernels report different disk geometries as previously for the same disk an incompatible way therefore fooling softwares like Parted. Unluckily many partitioning tools weren't adjusted accordingly thus in some cases they might render Windows unbootable and even your data inaccessible by saving an incorrect partition table. Known major distributions having this problem are but not limited to Mandrake 10, SUSE 9.1, Fedora 2.
If you used a distribution having this problem then please check your vendors errata or see below for possible recovery solutions. We'd like to emphasize again, this is not an NTFS related problem and it is not caused by the usage of ntfsresize.
The problem was fixed in a recent parted what QTParted and most other partitioners use internally.
Everybody knows that NTFS is patented and dangerous to use, right?
No. NTFS is neither patented, nor dangerous to use.
The history. All started about 5 years ago. The old NTFS driver was written for NT4 NTFS but Windows 2000 introduced some improvements. The changes were important enough not to work with the NT4 driver. Unfortunately the driver didn't check the NTFS version, developers vanished thus it thrashed quite many people's filesystem. Unfortunately nobody cared to fix it for a long time.
Here comes Merkey to the picture. He generously offered people a Linux utility, free of charge that had Windows fix NTFS itself (aka run fsck during boot). Unfortunately he had an NDA with Microsoft, not to reveal internals of NTFS. According to him, Microsoft threatened him with a suit. Microsoft claims that it never threatened him or his company with a suit.
More about the issue here.
The story got Slashdot attention but with some twists: Microsoft Litigation vs. Linux NTFS Kernel Support. The minor problem was, that the Linux support for NTFS had nothing to do with Jeff Merkey or his company. Still, the Linux community thought they were directly threatened by Microsoft.
Conclusion? Linux NTFS development slowed down a lot. Red Hat has removed NTFS support completely and after 4 years, they still refer to non-existent NTFS patents, even if they would be void due to laws, e.g. the project is for the purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA.
And why NTFS isn't dangerous? Write support was disabled about 3-4 years ago and a new driver was written from scratch for 2.6 kernels that doesn't implement write, except file overwriting.
Due to Captive NTFS the ntfsprogs version was downgraded (I don't know why, Captive works fine with the latest ntfsprogs too).
The other very annoying consequence is that, ntfsresize from ntfsprogs became also too old hereby and QTParted or ntfsresize can't resize fragmented NTFS. I had to switch to SystemRescueCD. A very cool, up-to-date admin & rescue CD!
Last I heard write was still experiencing random failures [...]
That was 4-5 years ago. Then Anton Altaparmakov disabled the unreliable write support and started to write a new driver from scratch. Today that one is included in Linux 2.6 kernels and it's reliable. Altough the write support is still limited but for example
NTFS resizing is widely used and very reliable for over two years.
There are also two additional binary-only, full-featured, read-write NTFS drivers. One of them is Captive NTFS, using Windows' own NTFS driver the Wine way, and the other one is Paragon's NTFS driver.
Knoppix has four of the NTFS drivers:
1) old, broken NTFS in 2.4 kernels
2) new, safe NTFS in 2.6 kernels
3) Captive NTFS
4) userspace utilities: shared code with 2) but no kernel driver needed
The "Inside the Windows NT File System" book is 10 years old and discusses an at least 14-15 years old design.
However over the last 10 years, apparently Microsoft worked hard on NTFS because it was improved a lot performance (pre-fetching data, metadata rearrangements, block allocation optimizations, etc), features (sparse file, compression, encryption, quota, symlinks support, etc) and reliablility-wise.
NTFS was usually between Reiserfs and Reiser4
in the benchmarks I've seen so far. Reiser4 being always the fastest by about 5-20%.
Another good client is called ctorrent, written in C, a console app. It segfaults when the d/l is > 2gigs (I think thats why), and sometimes doesnt redownload failed segments.. I had to drag some downloads to a windows box and finish them up with the real client. Shame about the bugs, it's a very light and fast app, I hope it's finished.
Did you report these problems to the developers? Often they aren't aware of all the problems so you can't expect the bugs will be fixed without telling them first.
Slashdot Mirror
Trying to mount an NTFS partition in Linux that was left hibernated by Windows can create a real mess.
No, it can not. Read-only mount is allowed but read-write mount is refused unless the 'remove_hiberfile' mount option is specified.
Microsoft designed hibernation in mind for the case when the hibernation file must be removed and they ensure that the filesystem remains consistent. They didn't do it for Linux interoperability but for themself when they are not able too boot otherwise.
NTFS on Linux is slow.
Yes. And sadly FAT and ext3 is even slower. There can be many explanations for slowness, some are apparently explained on http://www.ntfs-3g.org/support.html#slow
The free NTFS-3G driver is slower than the commercial, also FUSE based one which overperforms stable kernel file systems, except ext4. Most file system requests are served by the FUSE kernel module without any user space involvement.
NTFS-3G implements online recovery. Look for the recover and norecover mount options: http://www.ntfs-3g.org/releases.html
Have you EVER seen a Mac in production running on top of a NTFS read-write RAID?
Never. Only on Linux using WUBI.
Btw, does Mac indeed support RAID already?
Absolutely. The current NTFS-3G project leader wrote the only open source NTFS resizer 6 years ago.
"FUSE is a kernel module."
:-)
FUSE is a kernel module, a user space library (libfuse), a user space helper application (fusermount) and a user space helper script (mount.fuse). Well, at least
"FUSE defeats the entire purpose. ZFS is meant to run and support a large/huge file store. What admin in their right mind would do that through userspace unless it's solely for backup?"
Who doesn't want his system to crash when a transient hardware error hit non-redundant ZFS kernel code.
NTFS is open source and took less than a decade to get support on multiple systems?
Yes, NTFS-3G
Mount_ntfs doesn't have full read/write possibility. NTFS-3G has and it's commonly used on Linux.
The original NTFS-3G source code doesn't compile on Mac OS X without some changes but the MacFUSE and NTFS-3G precompiled packages are available from IUseThis.
ntfs-3g has stable write for months. Many distro use it already: http://ntfs-3g.org/ ;-)
It's also open source, so you can learn from it as you wished
The real specific is the Windows binary NTFS driver. Anything else is auxiliary for interoperability and quality assurance.
It's called NTFS-3G: http://www.ntfs-3g.org/ The documentation is the binary ntfs driver, chkdsk and the NTFS on-disk file format one can find on any Windows box. These are the *REAL* documentation, which are *MUCH* detailed than any technical specification could ever be.
NTFS-3G has full read-write, open source NTFS support for a few months: http://www.ntfs-3g.org/ Fedora Extra, Debian, Ubuntu and many others have it already.
Feb 24, 2005: Ubuntu 5.04, codenamed "Hoary Hedgehog", is the newest distribution that added support for non-destructive NTFS resizing during installation by the use Partman and ntfsresize. Here is how you can do it when the [Partitioning disks] screen appears:
1. Choose the "Manually edit partition table" option.
2. Choose the NTFS partition you want to resize.
3. Choose the "Size:" line.
4. Choose if you are asked about "Write changes to disk and resize the partition?".
5. Enter the new size.
6. Please wait patiently until the resize process frees the needed space for Ubuntu installation.
Experience. Captive NTFS corruption problems are also posted to its mailling list and documented in its TODO file.
Knoppix uses the rewritten NTFS driver which supports loopback read-write mounting a file on NTFS. Nothing new, the now also dead Phat Linux already did the same in 2002 with the same open source kernel driver. Currently the most popular "run Linux from NTFS" distribution is TopologiLinux.
It's very nice to see Knoppix caught up too.
It's not as easy to destroy all data as usually thought. In theory, three things might go wrong during resizing an NTFS partition and setting it up for dual boot,
1. NTFS resizing by ntfsresize.
2. Repartitioning by fdisk, cfdisk, Parted, QTParted, DiskDrake, YaST, etc.
3. Boot manager setup using LILO, GRUB, etc.
In all cases, we have met, the problem was introduced in either step 2 or step 3 and not by the use of ntfsresize. In most cases this means, your data is still intact but you can't access it.
Most often a Windows boot problem occurs if one edited the partition table by Parted version less than 1.6.12 or a libparted based partitioning tool. This is especially true if a Linux 2.6 kernel was used. The Linux 2.6 kernels report different disk geometries as previously for the same disk an incompatible way therefore fooling softwares like Parted. Unluckily many partitioning tools weren't adjusted accordingly thus in some cases they might render Windows unbootable and even your data inaccessible by saving an incorrect partition table. Known major distributions having this problem are but not limited to Mandrake 10, SUSE 9.1, Fedora 2.
If you used a distribution having this problem then please check your vendors errata or see below for possible recovery solutions. We'd like to emphasize again, this is not an NTFS related problem and it is not caused by the usage of ntfsresize.
The problem was fixed in a recent parted what QTParted and most other partitioners use internally.
No. NTFS is neither patented, nor dangerous to use.
The history. All started about 5 years ago. The old NTFS driver was written for NT4 NTFS but Windows 2000 introduced some improvements. The changes were important enough not to work with the NT4 driver. Unfortunately the driver didn't check the NTFS version, developers vanished thus it thrashed quite many people's filesystem. Unfortunately nobody cared to fix it for a long time.
Here comes Merkey to the picture. He generously offered people a Linux utility, free of charge that had Windows fix NTFS itself (aka run fsck during boot). Unfortunately he had an NDA with Microsoft, not to reveal internals of NTFS. According to him, Microsoft threatened him with a suit. Microsoft claims that it never threatened him or his company with a suit. More about the issue here.
The story got Slashdot attention but with some twists: Microsoft Litigation vs. Linux NTFS Kernel Support. The minor problem was, that the Linux support for NTFS had nothing to do with Jeff Merkey or his company. Still, the Linux community thought they were directly threatened by Microsoft.
Conclusion? Linux NTFS development slowed down a lot. Red Hat has removed NTFS support completely and after 4 years, they still refer to non-existent NTFS patents, even if they would be void due to laws, e.g. the project is for the purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA.
And why NTFS isn't dangerous? Write support was disabled about 3-4 years ago and a new driver was written from scratch for 2.6 kernels that doesn't implement write, except file overwriting.
On an amplifying note, most linux install kernels do not have vfat or ntfs drivers
In my experience, all major distros include these drivers with the exception of RedHat/Fedora. Red Hat refers to non-existent patents.
The other very annoying consequence is that, ntfsresize from ntfsprogs became also too old hereby and QTParted or ntfsresize can't resize fragmented NTFS. I had to switch to SystemRescueCD. A very cool, up-to-date admin & rescue CD!
Last I heard write was still experiencing random failures [...]
That was 4-5 years ago. Then Anton Altaparmakov disabled the unreliable write support and started to write a new driver from scratch. Today that one is included in Linux 2.6 kernels and it's reliable. Altough the write support is still limited but for example NTFS resizing is widely used and very reliable for over two years.
There are also two additional binary-only, full-featured, read-write NTFS drivers. One of them is Captive NTFS, using Windows' own NTFS driver the Wine way, and the other one is Paragon's NTFS driver.
Knoppix has four of the NTFS drivers:
1) old, broken NTFS in 2.4 kernels
2) new, safe NTFS in 2.6 kernels
3) Captive NTFS
4) userspace utilities: shared code with 2) but no kernel driver needed
NTFS was usually between Reiserfs and Reiser4 in the benchmarks I've seen so far. Reiser4 being always the fastest by about 5-20%.
Did you report these problems to the developers? Often they aren't aware of all the problems so you can't expect the bugs will be fixed without telling them first.