Disk sync at shutdown and fusefs filesystems

[Alejandro Pulver]

On Mon, 17 Dec 2007 02:21:53 +0100
Csaba Henk <csaba at beastie.creo.hu> wrote:

> >> They have already discovered issues with system shutdown on Linux, and
> >> Miklos has implemented a solution for this dubbed as "synchronous
> >> umount". According to this, the protocol is enhanced with a new message
> >> called DESTROY. Upon unmounting the fs, the kernel sends a DESTROY to
> >> the daemon and waits for answer. That is, unmount(2) won't complete
> >> until the fs says to the kernel "OK, I'm done".
> >>
[...]
> > Hmm, I don't know much of this, but isn't the Linux problem related to
> > flushing its own block device cache? In FreeBSD it doesn't exist (i.e.
> > ublio is only user-space), so I wonder if just unmounting before
> > shutdown solves the issue. I mean, does the kernel still keep
> > information after a FUSE filesystem is unmounted?
> >
> > Please correct me if I'm wrong.
> >
> > At least the currently discussed trick only works because it waits a few
> > seconds after unmounting to let it flush the cache (but I think it's a
> > common fact that filesystems get registered/unregistered with a small
> > delay, and may not be related to that).
> 
> The point in synch umount is that you don't need to wait for an ad hoc
> amount of time in order to have the various caches flushed / media
> sync'd -- it enables the filesystem daemon itself to notify the umount
> procedure that it's done and the world can go on.
> 
> The exact nature of caches (userspace / in-kernel) doesn't really make a
> difference from this POV. (Implementing the appropriate synchronization
> mechanisms is up to the fs daemon.)
> 

I see, thanks for the clarification.

> >>  - Some "got hung in unmount" issues are to be sorted out (these
> >>    appeared on Linux, and they might or might not appear on FreeBSD).
> >>
> >
> > Never seen this, but also never unmounted at shutdown before. I have a
> > patch for it (see thread). Then we could easily see if it get stalled
> > at shutdown (or when manually stopping the rc.d script).
> 
> Of course you've never seen this! -- these have appeared as consequences
> of the synchronous umount (ie., the DESTROY message) which is not yet
> implemented on FreeBSD.
> 

That's logical. I missed the point.

> The actual question is whether it is worth to implement it. For me it
> seems "yes", but I don't know the ins and outs of the FreeBSD
> init/shutdown system, that's why I'd like to hear the opinion of people
> like you about this before I go and code it.
> 

I'm not in the kernel side, but I think it's the correct thing to do.
The kernel syncer does the same with other filesystems, so...

> Whether hangs occur or not if fuse4bsd does sync umount is not that
> important. I mean, first I would code a basic implementation of DESTROY
> (that's pretty simple to do!) and we'd see how well that works and if we
> see problems I try to tune the implementation. That's just business as
> usual.
> 

For what you said, we won't know if there are hangs until we have an
implementation of DESTROY. So this will be attended later as you said.

> The next issue is more important...
> 
> >>  - Security issue: with synch unmount, any user who can mount (w/ synch
> >>    unmount), is capable of making the unmount stuck (which is easy to
> >>    fix when the system is up -- just kill the fs daemon -- but can
> >>    make the shutdown process hopelessly stuck). So we'd have to
> >>    decide who/when shall be able to do mounts for which the unmount is
> >>    synchronous. (The current criteria for this on Linux -- ie.,
> >>    is the fuseblk fs variant being used? -- is N/A to FreeBSD for
> >>    reasons which are OT here. However, Miklos decided to
> >>    change this so that sych unmount will be tied to the "allow_other"
> >>    option, which is tied to root privileges, and does make sense
> >>    on FreeBSD, too. I'd be happy to hear more suitable criteria.
> >>
> >
> > This would depend on the previous point.
> 
> It's more important to specify a suitable security policy -- who/when
> should be capable of mounting an fs in a way so that the umount will
> be synchronous? (Short term for this: "mounting with synch umount").
> 
> I think it's quite a "standalone" question, it depends on nothing else.

<quote>
- Some "got hung in unmount" issues are to be sorted out (these
   appeared on Linux, and they might or might not appear on FreeBSD).
</quote>

IIRC you are saying that any user could make umount hang. And you said
this is an unintended behavior caused by the implementation, which
appeared on Linux and we don't know if it will happen on FreeBSD.

Otherwise the daemon would synchronize the fs and let umount return
normally, and this wouldn't happen, right?

If this always happens then what is the difference between happening on
a root/non-root mount, as it will hang anyways?

If I missed the point again please correct me, and clarify the following:
Does the hang (point 2)/umount stuck (point 3) issues consist of the
same (I assumed so)? If not, please point out the differences.

> If a FUSE fs is mounted with synch umount its daemon can block the umount
> command/syscall, and therefore it can probably block the whole shutdown
> sequence (killing the process or umounting with -f might help, but these
> probably won't happen during the normal shutdown course).
> 
> A possible compromise is letting only the superuser to mount with synch
> umount. That would mean only superuser mounted ntfs fs-es will be
> cleanly unmounted during shutdown (I mean, without resorting to hacks in
> the shutdown scripts). ("Tying synch umount to 'allow_other'", as
> mentioned above, is practically the same choice.) 
> 
> This of course can be refined, eg. make it configurable with a sysctl,
> etc.
> 
> Either case, it's a design issue and not just an implementation detail
> so it would be clever to try to make up our mind about this.
> 
> Csaba

Best Regards,
Ale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20071217/6a42b3d0/signature.pgp