Date: Sun, 1 Mar 1998 22:30:49 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dima@tejblum.dnttm.rssi.ru (Dmitrij Tejblum) Cc: tlambert@primenet.com, FreeBSD-current@FreeBSD.ORG Subject: Re: VM: Process hangs sleeping on vmpfw Message-ID: <199803012230.PAA26918@usr08.primenet.com> In-Reply-To: <199803011032.NAA02269@tejblum.dnttm.rssi.ru> from "Dmitrij Tejblum" at Mar 1, 98 01:32:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Second, why don't put the operations to default_vnodeop_entries? It is > > > used exactly by local media filesystems. Stacking layers use bypass > > > routines instead (unionfs is an exception). So, filesystems even would > > > not notice this change, until they really want their own implementation > > > of getpages/putpages > > > > > > What is wrong in the above? > > > > Unionfs. Specifically, the point is that the unionfs implementation > > should fan out to the correct underlying implementation. This means > > it shouldn't go into the default. > > But you must write correct getpages/putpages for unionfs in any case. > Or, better, make a bypass routine for unionfs, to avoid similar > problems with future new vnode operations :-). Until this happens, I would prefer that the unionfs not silently pretend that there is no problem with the way it works, lulling innocent users into a false sense of security. > > > I can send a patch for you... It is indeed pretty easy... > > > > See above for the patch. It's the identification problem and the > > stacking problem that I wanted to handle on a case-by-case basis. > > I don't see why default ops doesn't solve stacking problems. Because they provide a default operation for every FS, even FS's you want to use the bypass instead. The reasoning here is that once stacking starts working reliably, there is going to be an explosion in FS stack developement. I am personally intenting to implement a UMSDOS stacking layer that is compatible with Udo Walter's UMSDOSFS in Linux (if __LINUX_ is there, it will use it). I am also very interested in doing a stacking layer for quotas, so that they work in all FS's, not just FFS. And of course, a split stacking layer similar to the Heidemann Thesis network proxy layer, except that it will proxy to user space so I can compile/source-debug/recompile/... FS code in user space. Because of this expected explosion, the number of FS's using the bypass vs. the FS's using the default ops will be much smaller. Ideally, there will be *no* default ops. This was the point of John's comments about simplification in the vnode_pager code. > > As I said, it's possible to make this change go transparent (#2, > > above); I would actually prefer an implementation that does *not* > > define the generic code as default ops, so if it has to go > > transparent, it should go transparent that way, not the default > > ops way, so at least there are warning messages emitted. > > If you want list of all filesystems to fix them you can do 'ls /sys', > 'ls /sys/gnu', and 'ls /sys/miscfs' and exclude some non-filesystem > directories. Also, if you really don't want the generic code be a > default ops, you can make it non-default ops and insert the ops to each > vnode table that require it. Local media FS's, and FS's that mimic local media FS's (of which thre is one, NFS) are the only FS's impacted. The list is: ffs, ext2fs, lfs (which is no longer there), msdosfs, cd9660 (get only), and NFS (which presents some strong problems, none of which are caused by the change, and only cares about putpages, which mostly needs to be written from scratch, given the current state of NFS). Where it does not impact are: mfs, deadfs, devfs, fdesc, fifofs, kernfs, nullfs, portal, procfs, sockfs, specfs, umapfs, and union. Tallies: FS's that have get/put: 2 FS's that are defunct: 1 (stacking FS's not included) 2 pro putpages (msdosfs/NFS) 2 pro getpages (msdosfs/cd9660) -- FS's that are "pro defaultops": 3 (bypass subtotal) FS's that are "pro bypass": 3 FS's that don't care: 10 -- 19 (total) The vote is 5:3 against defaultops, with 10 abstentions (11 if you count "Chicago votes" ;-)). Out of 19 FS's, we have 2 that still need putpages, and NFS arguably can not use the existing putpages, since client writes will fail anyway, and 2 that still need getpages. I think we should just make the 4 stub functions, on an as-needed basis. At the very least, we now have some very interesting FS demographics by what has and hasn't triggered the warning. > > You should also follow the NFS case in vnode_pager_generic_getpages > > and look at all the other vp->v_mount references. Look what the > > change means to VOP_BMAP, specifically with regard to the assumptions > > comment in vnode_pager_generic_getpages and vnode_pager_input_smlfs's > > being called -- with the same assumptions but without the test. It's > > pretty obvious that the VOP_BMAP return test is equal to the NFS > > test. This code is at the heart of a lot of problems, and I'd like > > to take it slow... > > TBH, I dont understand why the generic_getpages mention NFS at all. NFS > has its own getpages. ;-). I wondered if that would be caught by anyone or not... I don't think anyone else did a find/grep on getpages/putpages. 8-). > Dima > > Here is my patch against -current as of yesterday. The problem with this is that it recomplicates the world for FS's that want to use the bypass, and only provides a fix that we already know how to provide, in a better way. If we have to modify the same number of FS's in both cases (3), and we have to play with either (4) or (6) ops, I vote for playing with (4). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803012230.PAA26918>