From owner-freebsd-hackers Sun Sep 5 12:59: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id CB5A814F37; Sun, 5 Sep 1999 12:58:56 -0700 (PDT) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.8.8/8.8.8) with ESMTP id GAA06680; Sun, 5 Sep 1999 06:16:12 -0700 (PDT) (envelope-from bright@wintelcom.net) Date: Sun, 5 Sep 1999 13:16:12 +0000 (GMT) From: Alfred Perlstein To: hackers@freebsd.org Cc: mckusick@freebsd.org Subject: VFS stuff agein, VOP_FSYNC and async lock notification. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been doing quite a bit of reasearch on NFS lately and some issues have come up: async locks, fsync, and a certain person returning from vacation. 1) async locks To avoid polling on locks by the userland rpc.lockd I'd like to be able to queue a lock on a file. This can also help database like systems. I'd like some suggestions to a notification method for the kernel to notify a process of locks it has gained. Perhaps even something that can lead to a generic async notification model. 2) VOP_FSYNC I noticed that there seems to be no method besideds mmap and msync to force a partial update on files. I have a proposal that addresses this. add an argument to the VOP_FSYNC call to take an offset and a length. add a syscall pfsync, and pfsyncv, pfsync would take a filehandle, offset and length to flush, and pfsyncv would take a an array somewhat like a iovec that specified regions to flush. pfsyncv would run through the array calling VOP_FSYNC on the regions. filesystems that don't support partial sync will default to a complete sync... or return EOPNOTSUPP? My inclination is to silently do a complete fsync. If I start on pfsync the only code at first will be to add the arguments to the VOP, I think I can manage getting partial syncs to work in UFS, and probably NFS, the rest will be the default. 3) someone on vacation I've been told by my sponsor and other committers to wait until Kirk McKusick gets back from vacation for a review of my VFS diffs... I've heard you're back. Kirk, can you please look at: http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.mp.diff (VFS_CHECKEXP on a mount point) and http://big.endian.org/~bright/freebsd/in_progress/vfs-fhsyscall.diff (VFS_CHECKEXP on a vnode) The diffs add fhopen, fhstat, and fhstatfs syscalls (from NetBSD). There is also some cleanup of the VFS system by pointing all unsupported VFS calls to functions in kern/sys_generic.c that seem to handle the default cases pretty well. It also splits the VFS_FHTOVP into 2 VFS operations, VFS_FHTOVP no longer does access checks, that is done in the derived VFS_CHECKEXP, VFS_FHTOVP now does only what it stands for, filehandle to vnode pointer. Any comments/critisizm you can offer? I think I'm more in favor of the first set of diffs. I'm also signed up for your second session at FreeBSDcon, I really look forward to it. See you in October. :) thanks, -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message