Subject: Re: Redoing file system suspension API
To: None <>
From: Pavel Cahyna <>
List: tech-kern
Date: 06/15/2006 18:07:38

thanks for looking at this. I have some comments (but I must admit not
having enough knowledge about file system internals).

- PR 32167 describes some issues with snapshots, and not all of them seem
  to be adressed. For example yamt writes there that VFS_SYNC is not enough 
  to make the filesystem consistent.

> ** The approach described here resolves these issues.  It replaces the
> "write gates" by "access file system gates".  Goal is to make every system
> call atomic with regards to file system suspension.  It will do all operations
> on a file system either before or after a suspension but will never do one part
> before and another part after the suspension.  Allowing recursion makes it
> easier to place the gates.  So the advantages are:
> - It is semantically well defined.
> - It is possible to add a DEBUG option to check it.  Every VOP called on

Every VOP? This probably does not include VOPs called from VFS_SYNC ?

>   a suspending or suspended file system is an error (there are minor
>   exceptions: syncer and part of pagedaemon).

Isn't this a contradiction? What if the syncer or the pagedaemon attempt
to write to a suspended filesystem?

> void vngate_suspend(void)
>   Suspend all gates of this thread.  Must be called before a thread may go to
>   long (interruptible) sleep.  Further vngate_(enter|leave) calls ar forbidden.

What does it mean to suspend a gate? That suspension is now temporarily