Le vendredi 06 octobre 2006 17:00, Szakacsits Szabolcs a écrit : > Hi, > > Sorry to disturb your circles but I'd like to say thanks for packing and > working on ntfs-3g, and hopefully I also have some useful information. > (Zakame, I loved your blog entry and I just noticed we was born on the same > day, except me 1111 years earlier ;)
You're welcome, thanks for creating this driver too ;-) > > > THIS SOFTWARE IS STILL EXPERIMENTAL AND MAY CAUSE UNRECOVERABLE DATA > > > LOSS. > > Well, this is actually true for any software ;) > > Ok, but seriously, reliability, data consistency and stability are by > __FAR__ the highest priority for ntfs-3g. Anything else comes much behind. > About 80-90% of the development time is spent for testing and intentionally > trying to break the driver and the filesystem in all possible ways. No > ntfs-3g driver was and will be __EVER__ released with known data corruption > problem, I can guarantee that ;) > > So far there were over 50,000 source code downloads and the following other > distros include or make ntfs-3g package available via their install > systems: Ubuntu (in universe for a few days), Gentoo, Kanotix, openSUSE, > PLD Linux, Arch Linux, Puppy LiveCD, Frugalware, Slax, Musix, Slackware, > Tilix, GParted LiveCD, Trinity Rescue Kit, Vector Linux, ALT Linux, PUD > Linux, Kurumin and Pardus Linux. > > I was also informed that several major commercial companies with half and > over a few millions of clients started to use it in their solutions (no, > nobody sponsors ntfs development). > > The quality assurance effort seems to be paid of since I didn't get any > unrecoverable data loss report since the last release, only quite many very > positive ones. I don't doubt about this. I test this software on i386 and many friend did the same. No one got any problem... > I always carefully avoided the "experimental" attribute. For me, in > software engineering, the word "experimental" means something like "I don't > really know what I'm doing, let's see what happens". But this is not true > with ntfs-3g. It exactly behaves as expected and all the known issues (none > is corruption related) are documented in the README file. So, I believe the > driver is far over on the "experimental" stage and the real world > experiences seems to prove this. I think the word "experimental" could be a > bit misleading about the quality in this case. I consider removing this warning message if we know exactly which are the supported architectures ! > People are keep asking why ntfs-3g isn't marked stable yet, why it's still > in beta when for example the stable Captive NTFS crashes and corrupts NTFS > by running this simple test: > > for i in `seq 1 200` ; do touch $i ; done > > The answer is that, I'd still like to solve some issues described in the > README file (e.g. transparent unicode handling, fix posix timestamps, > running my "mission-critical" workstation Linux for at least a week on NTFS > root (everything being on only NTFS), finish completely with the posix > conformance, LTP and some other testsuite, etc). Some of the solutions > aren't trivial, and the constant testing needs quite a lot of time as well. > To be honest, it's a bit unbelievable how stable the driver performs during > general use for so many people ... > > > > For now ntfs-3g is available for all Debian architectures but upstream > > > say it works for 32 bits / little endian systems. > > > > I would rather say: > > > > Presently, ntfs-3g is available for all Debian architectures. > > However, upstream says it only works for 32-bit little-endian > > systems. > > Some minor correction: 32-bit, little-endian is the __supported__ > (guaranteed to work) because that's the only hardware architecture > we can test. > > 64-bit, little-endian (well, only amd64, compile problem on Alpha) is > reported to work and used by many people with satisfaction (NTFS is fully > 64 bit). But we don't support since we can't test it. The regression > procedure consists of many test suites and they are running half a day, > covering millions of cases. Potential problem could be in the kernel, > glibc, fuse, hardware or ntfs-3g. Without real hardware we can not > investigate bug reports thus we can't support these architectures, > unfortunately. Okay i386, amd64 (unofficial) supported. Great. What's about 32 bits little-endian other arches, I mean arm and mipsel ? Any feedbacks ? > Big-endian: this is known not to work. There are known, easy-to-fix > problems at least in fuse and ntfs-3g. The codes are almost endian-safe and > in the best case they could be made supported probably in a few weeks. > However no dedicated hardware for support (temporary access is not ok, > since the tests are running non-stop on dedicated hardwares to guarantee > flawless > operation). I can give you ssh root access on an old sparc station (ultra5) with 80Gb hard disk. Feel free to ask for it if yu think it can ben helpful ! > Thanks for reading so far and if you have any question or critic then > please just drop me an email anytime. > > Cheers, > Szaka Regards, Adam.
