>Number:         32167
>Category:       kern
>Synopsis:       fss/snapshot problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 26 15:54:00 +0000 2005
>Originator:     YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
>Release:        NetBSD 3.99.10
>Organization:

>Environment:
	
	
System: NetBSD kaeru 3.99.10 NetBSD 3.99.10 (build.kaeru.xen.nodebug) #22: Wed Nov 2 06:33:38 JST 2005 takashi@kaeru:/home/takashi/work/kernel/build.kaeru.xen.nodebug i386
Architecture: i386
Machine: i386
>Description:

	1. fss/vfs_write_suspend doesn't make filesystem state consistent.
	  it issues VFS_SYNC, but it isn't enough, of course.

	2. vn_start_write is documented as "Prepare to start a file system
	  write operation".  but what's a "file system write operation" is
	  vague.  eg. VOP_READ updates atime and sometimes writes it to disk.
	  but it doesn't seem to be covered.  OTOH, VOP_FSYNC doesn't modify
	  file contents but it seems to be covered.  mmap'ed writes and msync
	  are normally considered as "write operation" IMO, but not covered.

	3. L_COWINPROGRESS is a hack and should be removed eventually.

	4. transferlockers is a hack and should be removed eventually.

	5. mysterious terms like "upper/lower level operation" should have
	  more clear definitions.

	6. adhoc pairs of vfs_getvfs and vn_start_write in nfs server involve
	  non-trivial per-rpc cost.  probably it's better to be done in
	  nfsrv_fhtovp, where additional vfs_getvfs is not necessary.

>How-To-Repeat:
	code inspection.
>Fix:
	IMHO, all snapshot things should be done in filesystem itself.

>Unformatted: