Hi,
On Thu, 10 May 2007, Tomas M wrote:
> > What do you exactly mean by "NTFS-3G mountpoint to fail"? What happens and
> > what do you expect to happen?
>
> This is hard to explain :)
>
> For example: first I mount the sda1 partition using ntfs-3g.
> Then I execute killall5 binary. After that, 'stat /mnt/sda1' returns:
> stat: cannot stat 'sda1': Transport endpoint is not connected.
> The same error is shown after ls /mnt/sda1 for example.
At the moment this is the expected behavior if ntfs-3g is SIGKILLed
(default signal for killall5; ntfs-3g has no chance to cleanup).
It means unclean unmount (actually no unmount, that one must be done
separately) and the effect is like a crash, power outage. Data can be
lost, volume can become inconsistent.
Typically Linux destroys processes the below way during shutdown:
killall5 -SIGTERM
sleep 5
killall5 -SIGKILL
ntfs-3g catches SIGTERM and initiates a clean unmount. If the 5 sec is not
enough then bad things can happen due to killall5 -SIGKILL.
> In my real scenario, it's even more complicated. I run a Linux distribution
> with 'persistent changes' on NTFS; in fact, a big file is opened from the NTFS
> partition and loop-mounted as a root xfs filesystem.
>
> In this case, killall5 causes the system to hang, because it can no more
> access anything from the root filesystem (which is mounted from NTFS).
>
> But my real scenario is not important I guess, as I can reproduce the problem
> on a normal Linux workstation as described at the top.
>
> I guess it's a problem of killall5.
Well, I think so.
However at the moment it does an incredible useful contribution by not
working the way it should. Why? Because most of the Linux kernels in wide
use (earlier than 2.6.20 releases) have a dangerous feature, namely, they
always do a lazy unmount for FUSE file systems. This means that devices
could be detached physically or powered down before ntfs-3g would have
finished writing all the data to the disk.
The early killall5 -SIGTERM command gives ntfs-3g more time to finish a
clean unmount than the lazy kernel unmount just before halting or
restarting the computer.
The strongly suggested way for unmounting a volume is of course using
umount(8) on a kernel 2.6.20+. If this is not the case then ntfs-3g always
warns during mount.
> But I just would like to know if NTFS crew can avoid these problems as it is
> IMHO pretty common that a distro executes killall5 during the shutdown.
SIGKILL is not catchable. If the earlier SIGTERM wasn't caught and the
unmount process started right away then data loss could happen.
> (If NTFS is first unmounted and then killall5 is called during system
> shutdown, then it's OK of course, so I understand that I can fix my problem by
> modifying shutdown scripts of my distro. What I'm looking for is a more
> general solution.)
I also think that the right way would be not sending the signals but using
the safe umount. Especially when much more people will use 2.6.20+ kernels.
> Thank you
You're welcome. I hope it was helpful.
Regards,
Szaka
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
