From owner-freebsd-current Mon May 31 23:17: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id DFC56155F3 for ; Mon, 31 May 1999 23:16:59 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 21150 invoked by uid 1001); 1 Jun 1999 06:16:53 -0000 To: Ustimenko Semen Cc: current@freebsd.org Subject: Re: FS Driver writing tactic References: From: Ville-Pertti Keinonen Date: 01 Jun 1999 09:14:49 +0300 In-Reply-To: Ustimenko Semen's message of "1 Jun 1999 00:50:28 +0300" Message-ID: <864skse9ba.fsf@not.demophon.com> Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ustimenko Semen writes: > Is this a good tactic to write working VOP_BMAP and > VOP_STRATEGY handlers, and implement VOP_READ and VOP_WRITE > via bread and bwrite of own vnodes? Considering that that's how the primary filesystem layers (ufs/ffs) do it, it should be fair to assume that it's at least a reasonable way of doing things. If you *don't* do it that way...the alternative (unless you want to bypass the cache) is to bread/bwrite the underlying device from VOP_READ/VOP_WRITE, which avoids a layer of indirection when the cache doesn't get hit (not very useful). The problem is, you're not going to be able to associate cached data with vm_objects usefully because you're buffers are associated with the underlying (device) vnode rather than the file vnode. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message