---------- Forwarded message ----------
From: Szabolcs Szakacsits <szaka@...>
Date: Tue, May 6, 2008 at 5:48 AM
Subject: [ntfs-3g-news] Stable NTFS-3G 1.2506 released
To: ntfs-3g-news@...
Cc: ntfs-3g-devel@...



Good Day,

Summary:

 *  Important bugfix release, upgrade is strongly recommended
 *  Experimental POSIX ACL support
 *  $100 Logo Design Competition
 *  Credits

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The top priority of the project, above anything else, is reliability.
Quite a lot of time, resources and engineering is invested to ensure
quality. The latest NTFS-3G release never has known reliability fault.

When we receive or see anywhere online or on public forums a bug report
which is subject to some potential driver reliability defect then we
immediately start to track down the potential culprit. There was a truly
long list of root causes in both software and hardware which were
absolutely unrelated to NTFS-3G. However this time it was different.

During the quality assurance process of the next major driver release
having a long-waited new feature, we have found a corruption. It can happen
basically anywhere on the partition except the NTFS boot sector. We thought
the bug is in the new feature but it turned out that all stable releases
have it except, ironically, the 1.0 version.

This stable release includes only the fix for this long time hiding bug,
besides some minor documentation updates.

How did this bug could survive for so long unnoticed and despite using
extensive quality testing summarized at http://ntfs-3g.org/quality.html ?

The true explanation is not so short and somewhat subtle because there are
many factors.

Until very recently, FUSE has restricted write block size to 4 KB. It also
happens that the typical NTFS cluster (block) size is also 4 KB. This means
that basically all write operations ended up allocating only a new, single
cluster. However the corruption could happen only in some rare cases during
multi-cluster allocations.

But the cluster allocator, which decides where the data goes on the disk,
is also used internally to place the NTFS metadata. One case again used
only single cluster allocations but another one didn't. And this could
result corruption if all the below conditions were also true:

 - last used MFT cluster was "unaligned"
 - there was free space only at the end of a cluster allocation group (CAG)
 - more space was requested than the free space at the end of CAG
 - the incorrectly read memory had "unlucky" values

Another lucky factor was that the metadata which required multi-cluster
allocation used a different, exclusive to itself allocation zone unlike
anything else, so it couldn't mix and corrupt any other allocations ...
until the volume got close to full disk.

But this is not all. There was another lucky factor which typically
prevented this to happen. Namely the lack of the below feature which
at some point completely blocked the metadata multi-cluster allocations:
http://ntfs-3g.org/support.html#filecreate

NTFS volumes using less than 4 KB cluster size (512, 1024, 2048) are in
much greater risk. The highest risk is for volumes using 512 byte cluster
size.

We are also __very__ lucky to find this problem just in the last moment.
The next stable Linux 2.6.26 kernel can send bigger than 4 KB write blocks
which would have exposed the so far thankfully underutilized bug in NTFS-3G
resulting random NTFS corruptions on large scale.

Thankfully Miklos Szeredi promptly suggested and agreed to implement making
FUSE large write support optional and default to OFF. This means that the
kernel upgrade can not cause NTFS data corruptions, only if the NTFS driver
isn't upgraded to 1.2506 version.

NTFS-3G will enable large block support when the driver passes all our
general and targeted tests.

The stable NTFS-3G driver can be downloaded from

 http://ntfs-3g.org/

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Jean-Pierre Andre has implemented two-way mappings between
NTFS and POSIX ACLs. Please see more information at:

 http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/524

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The NTFS-3G project is pleased to invite graphic designers to a logo
competition. The contest rules can be found at

 http://ntfs-3g.org/logo.html

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Many thanks to: Jean-Pierre Andre, Miklos Szeredi, Bernhard Kaindl,
Dominique L Bouix, Erik Larsson, Alejandro Pulver, Leann Ogasawara,
Carlos Reyes, Roberto Franceschini, Tom Kerremans, Jose Bernardo,
Bradley Dean, Joshua Weage, JD, Kent Robotti, Jason Perlow, Ralph
Corderoy, ...

Best regards,
               Szabolcs


_______________________________________________
ntfs-3g-news mailing list
ntfs-3g-news@...
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-news