In addition to being able to lock the fs via vfs_write_suspend and
vfs_write_resume (I'm not currently viewing the original post, sorry),
there's also the issue of how you want to do it.  What do you do with
fds open for writing?  Do you vclose() them [is that right?], do you
return EROFS, do you sleep, do you return EINTR...?

Also, at what level do you want to prohibit the write:  Data or Metadata?

If you have a data-only lock, then write(), link(), unlink(), mkdir(),
rmdir() and symlink() will block/fail; if you have a full (data +
metadata) lock, then in addition to the above, chmod() and chown() will
block/fail; ostensibly, if you want to be REAL anal about it and include
the possibility of st_?time being modified, then read() and readlink()
must also block/fail, or the st_atimes must be somehow queued or lost by
the wayside.  Metadata writes are still writes, whether incurred
explicitly via chmod() or chown() or implicitly by read().

I'm not asking about an implementation choice, but a run-time choice:
If you can lock the fs from userland (which I'm assuming we'll be able
to do since the procedure is nigh useless otherwise), you may wish to
permit metadata updates while blocking data updates (the comparison
of this to Solaris' lockfs(1) is indeed appropriate; indeed, lockfs
has quite a few locking options we may wish to look into).

				--*greywolf;
--
NetBSD: May the Source be with you.