From owner-freebsd-current Sun Mar 1 16:15:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01329 for freebsd-current-outgoing; Sun, 1 Mar 1998 16:15:10 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01322 for ; Sun, 1 Mar 1998 16:15:01 -0800 (PST) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id DAA24192; Mon, 2 Mar 1998 03:10:42 +0300 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.8/8.8.7) with ESMTP id DAA01416; Mon, 2 Mar 1998 03:18:37 +0300 (MSK) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199803020018.DAA01416@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Terry Lambert cc: FreeBSD-current@FreeBSD.ORG Subject: Re: VM: Process hangs sleeping on vmpfw In-reply-to: Your message of "Sun, 01 Mar 1998 22:30:49 GMT." <199803012230.PAA26918@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Mar 1998 03:18:37 +0300 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > 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. > > > > 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. Stacking layers supposed to use generic bypass routine, like this: { &vop_default_desc, (vop_t *) null_bypass }, This is the whole point of stacking layers --- they can bypass any operation that they don't need to handle specifically. If you disagree with the above statement, you can anyway put vop_stdgetpages and vop_stdputpages to each local media filesystem's vnops table, instead of cut&paste the trivial implementation (I repeat it 3rd time, since I didn't seen an answer to it). Also, stacking layers will not use the default anyway, if they are going to work. So I wouldn't count them as vote against getpages/putpages in the default ops table. If they cannot use a generic bypass, no one warning will save them from lot of troubles. > > Ideally, there will be *no* default ops. This was the point of > John's comments about simplification in the vnode_pager code. The comment is there for years.... I will wait until it actually happens. [...] > > > 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 Obvious, but doesn't true. NFS implement VOP_BMAP 8-). > > > to take it slow... Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message