Subject: Re: Redoing file system suspension API
To: None <email@example.com>
From: Pavel Cahyna <firstname.lastname@example.org>
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