On Sat, 19 May 2007, Tomas M wrote:

> > 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.
> 
> As you pointed out, the killall5 -SIGTERM will be handled by NTFS-3g and 
> it would normally unmount the partition. But not in my current case. I 
> am not using lazy unmounts, but there are still open files during the 
> SIGTERM on my NTFS disk 

In your case, loop mounting an image file on NTFS, killall5 really 
shouldn't send the signals to ntfs-3g.

> so all attempts to unmount the partition will fail as well as the SIGTERM 
> signal,

Umount should fail if files are used but the SIGTERM should arrive and the 
volume being closed (of course in your case that would be a problem).

There are actually two independent things going on here during 
mount/unmount, though they aren't in case of an in-kernel file system. 
Ntfs-3g is opening, reading/writing, closing a block device, and the FUSE 
kernel driver doing the kernel side of the mount/unmount. Ntfs-3g should 
close the volume if it gets the SIGTERM or FUSE notifies it about unmount.

> NTFS-3g would just silently ignore it (as the filesystem is busy); 

No, the signal should arrive and ntfs-3g tells FUSE to exit. In my tests, 
it always does but it could be that in your case this isn't true.

> So I really think my problem is in killall5, which should NOT kill my 
> ntfs-3g processes at the time I need it.

Yes.
 
> But here comes a suggestion for you: if ntfs-3g receives the SIGTERM 
> signal but is not able to end/unmount the filesystem cleanly, it should 
> prepare itself (it should expect) to be terminated by SIGKILL soon 
> (perhaps it should sync and ignore further writes or something). Just a 
> suggestion :) This will not help me in my case, but perhaps would be a 
> nice feature for others.

This is how it should work already. If SIGKILL arrives after sync() is 
called then everything should be fine. If it comes earlier then anything 
can happen. Sync() can't be called immediately because in-memory data 
should be updated and passed to the kernel first.

        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

Reply via email to