Bug#390778: ITP: ntfs-3g -- A read-write NTFS driver for FUSE
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.
Reply to: