Subject: kern/32167: fss/snapshot problems
To: None <email@example.com, firstname.lastname@example.org,>
From: None <email@example.com>
Date: 11/26/2005 15:54:00
>Synopsis: fss/snapshot problems
>Arrival-Date: Sat Nov 26 15:54:00 +0000 2005
>Originator: YAMAMOTO Takashi <firstname.lastname@example.org>
>Release: NetBSD 3.99.10
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
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.
IMHO, all snapshot things should be done in filesystem itself.