Re: [announcement] ntfs-3g: open source read-writedriver - bugreport (???)

On 7/19/06, Boross Péter wrote:
> Welcome!
>
> I'm using an AMD Duron 850 MHz with VIA chipset; with UHU-Linux 1.2
> (kernel 2.6.9-19, but patched by UHU-developers) and Windows 2000 SP4 as
> "NTFS-maker".
>
> I tried yesterday the driver on the partition /dev/hdb3.
>
> FUSE install (from source): OK
> ntfs-3g install (from source): OK
>
>  > umount /dev/hdb3
>  > modprobe fuse
>  > ntfs-3g /dev/hdb3 /Win2000/NTFS-Tmp
> everything were OK.
>
> I made a new directory on /dev/hdb3, and copied a big (approx. 2GB) file
> into it with Midnight Commander. The file were copied succesfully. I
> made some ls -l commands to compare the source and target file lengts,
> it was OK. After it, I restarted the computer, again with UHU 1.2., but
> (with my default settings) the /dev/hdb3 were mounted with kernel NTFS
> in read-only mode (UHU disables the limited kernel-NTFS write access).
> The mc showed the new (previously made) directory on /dev/hdb3 in red,
> and I wasn't able to step into it. With the gnome nautilus filemanager
> the situation was the same.
> I started windows, the Total Commander were no able to change to the new
> directory too. I typed
>  > chkdsk d:\NTFS-Tmp /f ( in my computer, the /dev/hdb3 is mounted in
> windows into the NTFS-Tmp directory of the main drive D: )
> chkdsk found some inode and free space errors, it repaired them, and
> voilà: The new directory created under linux were disappeared.
> I were able to repeat it every time, without exception (with small(er)
> files too).
> I would use NTFS under linux. What do I miss?
> May be a problem if captive-NTFS (and its requirements, e.g. LUFS) is
> installed on the computer (although it was not used)?
>
> Thank you for your help
> Péter Boross

After a few private mails, here is the conclusion:

The volume was not unmounted properly. Unmounting manually made the
problem go away.

It seems that UHU-Linux 1.2's (and probably other distribution's) init
scripts were not enough for ntfs-3g (and maybe other fuse-based file
systems). We did not try to pinpoint the exact problem with the
scripts nor to fix it.

A fix was committed to ntfsmount (ntfs-3g is being merged back to
ntfsmount) and available here:
http://sourceforge.net/mailarchive/forum.php?thread_id=26370779&forum_id=44768
People are encouraged to apply the fix to ntfs-3g, or unmount cleanly.

Note that we can't do much about data-loss on unclean mount! We can
only minimize some types of damage.

Warning: Technical details follow.

Every inode is modified in memory, and written to disk when it is
closed. However, inode 0 (the MFT) is only closed on unmount.
Therefore, if the MFT was extended during normal operation, the new
size was not written to disk (unlike the contents, which are written).
Thus, after a reboot, and a second mount, the new inodes are
referenced by some indexes (directories), but are not found within the
initialized MFT boundaries.

The fix syncs the MFT after each extension. It will probably hurt the
benchmarks, but not much, since data is already written to disk. A
better fix that will hurt benchmarks less would be to extend the MFT
in more than one record at a time, and sync it all at once. The
concept of "only optimize bottlenecks" postpone it to another day.

-- 
Yuval Fledel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV