Re: CVS commit: src/sys

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On Feb 6, 2014, at 4:45 PM, Taylor R Campbell 
<campbell+netbsd-source-changes-d%mumble.net@localhost> wrote:

>   Date: Thu, 6 Feb 2014 10:57:13 +0000
>   From: "Juergen Hannken-Illjes" <hannken%netbsd.org@localhost>
> 
>   Move fstrans_start()/fstrans_done() into genfs_insane_rename() to protect
>   the complete rename operation like we do for all other vnode operations.
> 
> I've always been a little fuzzy on the rules for using fstrans.  When
> I wrote genfs_rename, I was under the (probably incorrect) impression
> that it was there to block writers gracefully so that the file system
> could be put into a consistent state for a snapshot.
> 
> Could you explain what the rules for using fstrans_{start,done} are,
> and how they relate to vnode locks, lock order, and I/O operations?
> The fstrans(9) man page is a little terse.

The fstrans interface is just a helper for vfs_suspend(9):

     vfs_suspend(mp, nowait)
              Request a mounted file system to suspend all operations.  All
              new operations to the file system are stopped.  After all
              operations in progress have completed, the file system is synced
              to disk and the function returns.

That means most vnode operations look like:

        fs_op(void *v)
        {
                fstrans_start(mp, FSTRANS_SHARED);
                ...
                fstrans_done(mp);
                return error;
        }

Exceptions are VOP_GETPAGES()/VOP_PUTPAGES() as they run with
v_interlock held and therefore cant sleep and operations going down
to specfs for example.  Here we have the problem that the specfs
operation may take forever -- reading from a tty for example.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)