|
From: Szakacsits S. <sz...@si...> - 2004-02-04 12:43:35
|
Hello, On Wed, 4 Feb 2004, Jan Kratochvil wrote: > On Thu, 29 Jan 2004 08:41:42 +0100, Reuben Thomas wrote: > ... > > Anyway, I'm not really talking about what's desirable, but what I am > > guessing will happen. I think the native Linux driver already has enough > > momentum that it will mature and become reliable (as I understand it it > > already has write support, it's just not yet ready for production use). There are two different open source NTFS kernel drivers. In short, the old one has broken NTFS write support (it's not for production use), the rewritten NTFS source base has very limited write support and it's in production use over a year (e.g. Linux install on NTFS or keeping home, config, etc files via read/write loopback mount from NTFS). Please see more details here about the differences and just let us know if something is unclear or what we could do to improve the wording, descriptions, etc. http://linux-ntfs.sourceforge.net/status.html > Yet another mail for this issue - No, no, no. Linux-NTFS Linux kernel driver > has "write support" which means you can "rewrite existing data blocks". You can > never create a new file, extend existing file's file size, delete a file etc. > etc. Their "write support" wording is just a lie but hey are bold enough to > keep it this way. Here is our wording from the above page (it's there for quite a while): "Still read-only, but with safe file overwrite support on all Windows versions without changes to the file size and if the file is over 1 kB." Or from the kernel source http://lxr.linux.no/source/fs/Kconfig?v=2.6.1 config NTFS_RW bool "NTFS write support" This enables the partial, but safe, write support in the NTFS driver. The only supported operation is overwriting existing files, without changing the file length. No file or directory creation, deletion or renaming is possible [...] I can't find lies here. If you have idea what/where to improve/correct the wording or "lies", please let us know. Nevertheless we can do more than just overwrite, also safely, although only in userspace yet: truncate (change file size) and [meta]data relocations. These were enough to finish a stable, 99+% feature complete offline NTFS resizer. Just like Anton, I also can't see technical problems to implement the missing write features. However NTFS is one of the most complex filesystems in the world. Actually I'm afraid it's the most complex (Reiser4 could compete in the future when it gets stable after about 2-3 years from now). The Windows NTFS binary driver is over half MB, just like XFS. But there are also additional modules for NTFS I didn't count. Here is a list of the filesystem source sizes from the 2.6.1 kernel, kByte filesystem 3700 xfs 904 jfs 784 reiserfs 592 ntfs 396 ext3 264 ext2 92 fat 36 vfat NTFS is already quite big in size, still it's nowhere to XFS where it should be for "full" functionality. I estimate writing 2-3x more code that exists today should get us to a usable read/write driver (but without journaling, quota, encryption and other extra features). Of course this part of the work is much harder. Reiser4 and XFS has several full time paid developers to work on a filesystem what they designed. NTFS has about one-two developers who code in their very limited free time, maybe some hours a week. So no fast progress should be expected unless things change radically by e.g. some highly talented, motivated, skillful, persistent developer(s) with lots of free time willing to work on the driver. And no, no reverse engineering is needed, just a lot of docs and code needed to be understood and new code to be written very carefully and verified. But I think it's worth the effort to continue. The driver and tools work on the new 64 bit platforms (ia64, x86-64) and with all Longhorn betas released so far. Szaka |
