From owner-freebsd-fs@FreeBSD.ORG Mon Sep 29 11:06:50 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 568CD1065698 for ; Mon, 29 Sep 2008 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 45E748FC14 for ; Mon, 29 Sep 2008 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8TB6oP2040788 for ; Mon, 29 Sep 2008 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m8TB6nSL040784 for freebsd-fs@FreeBSD.org; Mon, 29 Sep 2008 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Sep 2008 11:06:49 GMT Message-Id: <200809291106.m8TB6nSL040784@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 19 problems total. From owner-freebsd-fs@FreeBSD.ORG Tue Sep 30 02:56:46 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABFF106568D for ; Tue, 30 Sep 2008 02:56:46 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA098FC23 for ; Tue, 30 Sep 2008 02:56:46 +0000 (UTC) (envelope-from lhmwzy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2232910rvf.43 for ; Mon, 29 Sep 2008 19:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=IudCnDeIx0sq97MJPQiq5aWa2qkeEaoFBGpsCTw0jY8=; b=DD0COU6ZTt1LRusb5k27K68cv5JMYoEH3+Nj5me+yp7UsDgEd9XRA5vZ7gGZRAwFte X/XDVskueBVVQhMl71EWuStBk5wzPWhhOntFt4H474yZqHTMyOWouQy2ffNjiYv7d7f4 ooYNCLC1zr/tFKbwsudr5BwEBQW0Axz0iAWv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Cf0h8fl0Yt4sRGFgZaRcFl0dKYDMYdWCrNhngVEtALXKZZQKgfw5qaLViw6a32/Wwk mpGnttJvel5Wteb8/xTOaRoKyrf+XNVzVzEHGt0b2YMAZH0DKkKyaA9pQYG9cU9Z0NFQ QVZ89qp8V9XjIW221GjmD1YEkHR2BulYmXAmM= Received: by 10.140.207.2 with SMTP id e2mr3031301rvg.187.1222741646322; Mon, 29 Sep 2008 19:27:26 -0700 (PDT) Received: by 10.140.163.5 with HTTP; Mon, 29 Sep 2008 19:27:26 -0700 (PDT) Message-ID: <78fb9d960809291927n60358006w7ef845e7cb40ed93@mail.gmail.com> Date: Tue, 30 Sep 2008 10:27:26 +0800 From: lhmwzy To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2008 02:56:46 -0000 I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. Would anybody do this? I do not have the skill or I will do this.:) links: http://www.dragonflybsd.org/hammer/index.shtml From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 00:06:45 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79971106568B for ; Wed, 1 Oct 2008 00:06:45 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 360EE8FC08 for ; Wed, 1 Oct 2008 00:06:45 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id EA5465D76 for ; Wed, 1 Oct 2008 01:48:20 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IRY57csdiSzL for ; Wed, 1 Oct 2008 01:48:20 +0200 (CEST) Received: from Tom.local (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id E2D2B5D69 for ; Wed, 1 Oct 2008 01:48:19 +0200 (CEST) Message-ID: <48E2BAC2.909@bsdunix.ch> Date: Wed, 01 Oct 2008 01:48:18 +0200 From: Thomas Vogt User-Agent: Thunderbird/3.0a2 (Macintosh; 2008072822) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: filebench on freebsd? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 00:06:45 -0000 Hello Has someone ever tried to compile filebench on current (64bit)? http://sourceforge.net/projects/filebench filebench is a multithreaded file system benchmark similar to postmark (single threaded). Maybe someone can help to make it work if it's not that difficult. I can't compile it: In file included from ipc.h:33, from filebench.h:55, from misc.c:35: threadflow.h:66: error: field 'al_aiocb' has incomplete type *** Error code 1 Stop in /root/filebench-1.3.4/filebench. *** Error code 1 This is: #ifdef HAVE_AIO typedef struct aiolist { int al_type; struct aiolist *al_next; struct aiolist *al_worknext; struct aiocb64 al_aiocb; } aiolist_t; #endif Regards, Thomas From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 14:22:22 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6D9106569A for ; Wed, 1 Oct 2008 14:22:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from aeryn.cs.uoguelph.ca (aeryn.cs.uoguelph.ca [131.104.20.160]) by mx1.freebsd.org (Postfix) with ESMTP id 834B48FC13 for ; Wed, 1 Oct 2008 14:22:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by aeryn.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id m91EMHOk029195; Wed, 1 Oct 2008 10:22:17 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id m91EZlR09643; Wed, 1 Oct 2008 10:35:47 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 1 Oct 2008 10:35:47 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Thomas Vogt In-Reply-To: <48E2BAC2.909@bsdunix.ch> Message-ID: References: <48E2BAC2.909@bsdunix.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.20.161 Cc: freebsd-fs@freebsd.org Subject: Re: filebench on freebsd? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 14:22:23 -0000 On Wed, 1 Oct 2008, Thomas Vogt wrote: > Hello > > Has someone ever tried to compile filebench on current (64bit)? > http://sourceforge.net/projects/filebench > > filebench is a multithreaded file system benchmark similar to postmark > (single threaded). Maybe someone can help to make it work if it's not that > difficult. > > I can't compile it: > > In file included from ipc.h:33, > from filebench.h:55, > from misc.c:35: > threadflow.h:66: error: field 'al_aiocb' has incomplete type > *** Error code 1 Which probably means that "struct aiocb64" isn't properly defined at this point. > > Stop in /root/filebench-1.3.4/filebench. > *** Error code 1 > > This is: > #ifdef HAVE_AIO > typedef struct aiolist { > int al_type; > struct aiolist *al_next; > struct aiolist *al_worknext; > struct aiocb64 al_aiocb; > } aiolist_t; > #endif > > > Regards, > Thomas > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 19:07:32 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A4106568A; Wed, 1 Oct 2008 19:07:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id 3346A8FC13; Wed, 1 Oct 2008 19:07:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 52FAC1CD1C; Wed, 1 Oct 2008 21:07:28 +0200 (CEST) Date: Wed, 1 Oct 2008 21:07:28 +0200 From: Ed Schouten To: FreeBSD FS , FreeBSD Arch Message-ID: <20081001190728.GL16837@hoeg.nl> References: <20080912182722.GK1191@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="egxrhndXibJAPJ54" Content-Disposition: inline In-Reply-To: <20080912182722.GK1191@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jille Timmermans , Mark van Cuijk Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 19:07:32 -0000 --egxrhndXibJAPJ54 Content-Type: multipart/mixed; boundary="vTUhhhdwRI43FzeR" Content-Disposition: inline --vTUhhhdwRI43FzeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, * Ed Schouten wrote: > Yesterday I was talking with some friends of mine about the FreeBSD VFS > layer. As an exercise, Jille was trying to patch nullfs to hide .svn > directories (see hackers@), so that's how we got to the subject. >=20 > After talking about the way our vop_vector works (vop_bypass and > vop_default), we were wondering why we don't propagate all pointers in > the vop_vector to its children to save the unneeded function pointer > resolving inside the VOP_* calls. >=20 > The reason I'm sending this message, is because based on discussions I had with several people on IRC we've basically got two different opinions on this patch: - One group of people liked the idea of the patch. Some people even said the patch looks good enough to be committed. - Another group of people also liked the idea, but thought it would make no sense to commit it, because it's not like it's a bottleneck right now. It should only be committed if an increase in performance is notable. I did some tests with the patch set, by running tens of millions of fstat(), fchown(), etc. calls to see how performance was affected. It turns out on a kernel without any debugging options enabled, the performance gain is only 1-2%, which sounds pretty valid to me. It's not much, so because there are objections I've decided not to commit it. This doesn't make a lot of sense to me, because the patch is already there. It's just a matter of punching in `svn commit'. I'm attaching the latest version of the patch to this email message, so if someone else would like to pick this up: be my guest. Be sure to buy a bucket of paint before doing so. --=20 Ed Schouten WWW: http://80386.nl/ --vTUhhhdwRI43FzeR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="vnode-vop-expand.diff" Content-Transfer-Encoding: quoted-printable Index: sys/nfsclient/nfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/nfsclient/nfs_vnops.c (revision 182995) +++ sys/nfsclient/nfs_vnops.c (working copy) @@ -134,7 +134,6 @@ * Global vfs data structures for nfs */ struct vop_vector nfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D nfs_access, .vop_advlock =3D nfs_advlock, .vop_advlockasync =3D nfs_advlockasync, @@ -164,6 +163,7 @@ .vop_symlink =3D nfs_symlink, .vop_write =3D nfs_write, }; +DECLARE_VOP_VECTOR(nfs_vnodeops); =20 struct vop_vector nfs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -178,6 +178,7 @@ .vop_setattr =3D nfs_setattr, .vop_write =3D nfsfifo_write, }; +DECLARE_VOP_VECTOR(nfs_fifoops); =20 static int nfs_mknodrpc(struct vnode *dvp, struct vnode **vpp, struct componentname *cnp, struct vattr *vap); Index: sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (revision 182995) +++ sys/gnu/fs/xfs/FreeBSD/xfs_vnops.c (working copy) @@ -118,7 +118,6 @@ static vop_vptofh_t _xfs_vptofh; =20 struct vop_vector xfs_vnops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D _xfs_access, .vop_advlock =3D _xfs_advlock, .vop_bmap =3D _xfs_bmap, @@ -151,6 +150,7 @@ .vop_write =3D _xfs_write, .vop_vptofh =3D _xfs_vptofh, }; +DECLARE_VOP_VECTOR(xfs_vnops); =20 /* * FIFO's specific operations. Index: sys/gnu/fs/reiserfs/reiserfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/reiserfs/reiserfs_vnops.c (revision 182995) +++ sys/gnu/fs/reiserfs/reiserfs_vnops.c (working copy) @@ -20,8 +20,6 @@ =20 /* Global vfs data structures for ReiserFS */ struct vop_vector reiserfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D reiserfs_access, .vop_bmap =3D reiserfs_bmap, .vop_cachedlookup =3D reiserfs_lookup, @@ -37,15 +35,15 @@ .vop_strategy =3D reiserfs_strategy, .vop_vptofh =3D reiserfs_vptofh, }; +DECLARE_VOP_VECTOR(reiserfs_vnodeops); =20 struct vop_vector reiserfs_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D reiserfs_access, .vop_getattr =3D reiserfs_getattr, .vop_inactive =3D reiserfs_inactive, .vop_reclaim =3D reiserfs_reclaim, }; +DECLARE_VOP_VECTOR(reiserfs_specops); =20 /* ------------------------------------------------------------------- * vnode operations Index: sys/gnu/fs/ext2fs/ext2_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/gnu/fs/ext2fs/ext2_vnops.c (revision 182995) +++ sys/gnu/fs/ext2fs/ext2_vnops.c (working copy) @@ -116,7 +116,6 @@ =20 /* Global vfs data structures for ext2. */ struct vop_vector ext2_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D ext2_access, .vop_bmap =3D ext2_bmap, .vop_cachedlookup =3D ext2_lookup, @@ -148,9 +147,9 @@ .vop_write =3D ext2_write, .vop_vptofh =3D ext2_vptofh, }; +DECLARE_VOP_VECTOR(ext2_vnodeops); =20 struct vop_vector ext2_fifoops =3D { - .vop_default =3D &fifo_specops, .vop_access =3D ext2_access, .vop_close =3D ext2fifo_close, .vop_fsync =3D ext2_fsync, @@ -164,6 +163,7 @@ .vop_write =3D VOP_PANIC, .vop_vptofh =3D ext2_vptofh, }; +DECLARE_VOP_VECTOR(ext2_fifoops); =20 #include =20 Index: sys/ufs/ufs/ufs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/ufs/ufs/ufs_vnops.c (revision 182995) +++ sys/ufs/ufs/ufs_vnops.c (working copy) @@ -2446,7 +2446,6 @@ =20 /* Global vfs data structures for ufs. */ struct vop_vector ufs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_fsync =3D VOP_PANIC, .vop_read =3D VOP_PANIC, .vop_reallocblks =3D VOP_PANIC, @@ -2490,6 +2489,7 @@ .vop_aclcheck =3D ufs_aclcheck, #endif }; +DECLARE_VOP_VECTOR(ufs_vnodeops); =20 struct vop_vector ufs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -2518,3 +2518,4 @@ .vop_aclcheck =3D ufs_aclcheck, #endif }; +DECLARE_VOP_VECTOR(ufs_fifoops); Index: sys/ufs/ffs/ffs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/ufs/ffs/ffs_vnops.c (revision 182995) +++ sys/ufs/ffs/ffs_vnops.c (working copy) @@ -132,6 +132,7 @@ .vop_write =3D ffs_write, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_vnodeops1); =20 struct vop_vector ffs_fifoops1 =3D { .vop_default =3D &ufs_fifoops, @@ -139,6 +140,7 @@ .vop_reallocblks =3D ffs_reallocblks, /* XXX: really ??? */ .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_fifoops1); =20 /* Global vfs data structures for ufs. */ struct vop_vector ffs_vnodeops2 =3D { @@ -157,6 +159,7 @@ .vop_setextattr =3D ffs_setextattr, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_vnodeops2); =20 struct vop_vector ffs_fifoops2 =3D { .vop_default =3D &ufs_fifoops, @@ -172,6 +175,7 @@ .vop_setextattr =3D ffs_setextattr, .vop_vptofh =3D ffs_vptofh, }; +DECLARE_VOP_VECTOR(ffs_fifoops2); =20 /* * Synch an open file. Index: sys/kern/uipc_mqueue.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/uipc_mqueue.c (revision 182995) +++ sys/kern/uipc_mqueue.c (working copy) @@ -2477,7 +2477,6 @@ }; =20 static struct vop_vector mqfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D mqfs_access, .vop_cachedlookup =3D mqfs_lookup, .vop_lookup =3D vfs_cache_lookup, @@ -2495,6 +2494,7 @@ .vop_mkdir =3D VOP_EOPNOTSUPP, .vop_rmdir =3D VOP_EOPNOTSUPP }; +DECLARE_VOP_VECTOR(mqfs_vnodeops); =20 static struct vfsops mqfs_vfsops =3D { .vfs_init =3D mqfs_init, Index: sys/kern/vfs_default.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_default.c (revision 182995) +++ sys/kern/vfs_default.c (working copy) @@ -72,10 +72,7 @@ * */ =20 -struct vop_vector default_vnodeops =3D { - .vop_default =3D NULL, - .vop_bypass =3D VOP_EOPNOTSUPP, - +static struct vop_vector default_vnodeops =3D { .vop_advlock =3D vop_stdadvlock, .vop_advlockasync =3D vop_stdadvlockasync, .vop_bmap =3D vop_stdbmap, @@ -102,6 +99,50 @@ }; =20 /* + * A generic routine to inherit missing routines in vop_vectors from + * their vop_default or vop_bypass routines. This routine shall be + * called on all vop_vectors on startup, which means we can always + * assume existing routines are referenced. + */ + +void +vop_vector_init(void *arg) +{ + struct vop_vector *vop =3D arg, *dvop; + vop_bypass_t **vlist, **dvlist; + unsigned int i; + + /* + * Set vop->vop_default to &default_vnodeops to indicate that + * the vop_vector has already been processed. This saves some + * unneeded traversing of the vectors. + */ + dvop =3D vop->vop_default; + if (dvop =3D=3D &default_vnodeops) + return; + vop->vop_default =3D &default_vnodeops; + + if (dvop !=3D NULL) + vop_vector_init(dvop); + else + dvop =3D &default_vnodeops; + + vlist =3D _VOP_VECTOR_ARRAY(vop); + dvlist =3D _VOP_VECTOR_ARRAY(dvop); + + for (i =3D 0; i < _VOP_VECTOR_COUNT; i++) { + if (vlist[i] =3D=3D NULL) { + if (vop->vop_bypass !=3D NULL) + vlist[i] =3D vop->vop_bypass; + else if (dvlist[i] !=3D NULL) + vlist[i] =3D dvlist[i]; + else + vlist[i] =3D VOP_EOPNOTSUPP; + } + } +} + +/* * Series of placeholder functions for various error returns for * VOPs. */ Index: sys/kern/vfs_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_subr.c (revision 182995) +++ sys/kern/vfs_subr.c (working copy) @@ -3262,7 +3262,6 @@ static int sync_reclaim(struct vop_reclaim_args *); =20 static struct vop_vector sync_vnodeops =3D { - .vop_bypass =3D VOP_EOPNOTSUPP, .vop_close =3D sync_close, /* close */ .vop_fsync =3D sync_fsync, /* fsync */ .vop_inactive =3D sync_inactive, /* inactive */ @@ -3271,6 +3270,7 @@ .vop_unlock =3D vop_stdunlock, /* unlock */ .vop_islocked =3D vop_stdislocked, /* islocked */ }; +DECLARE_VOP_VECTOR(sync_vnodeops); =20 /* * Create a new filesystem syncer vnode for the specified mount point. Index: sys/tools/vnode_if.awk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/tools/vnode_if.awk (revision 182995) +++ sys/tools/vnode_if.awk (working copy) @@ -290,6 +290,10 @@ ctrstr =3D ctrstr ", a->a_" args[i]; ctrstr =3D ctrstr ");"; =20 + numvops++; + if (!firstvop) + firstvop =3D name; + if (pfile) { printp("\t"name"_t\t*"name";") } @@ -366,17 +370,11 @@ printc(""); printc("\tVNASSERT(a->a_gen.a_desc =3D=3D &" name "_desc, a->a_" args[0]= ","); printc("\t (\"Wrong a_desc in " name "(%p, %p)\", a->a_" args[0]", a)= );"); - printc("\twhile(vop !=3D NULL && \\"); - printc("\t vop->"name" =3D=3D NULL && vop->vop_bypass =3D=3D NULL)") - printc("\t\tvop =3D vop->vop_default;") - printc("\tVNASSERT(vop !=3D NULL, a->a_" args[0]", (\"No "name"(%p, %p)\= ", a->a_" args[0]", a));") + printc("\tVNASSERT(vop->"name" !=3D NULL, a->a_" args[0]", (\"No "name"(= %p, %p)\", a->a_" args[0]", a));") for (i =3D 0; i < numargs; ++i) add_debug_code(name, args[i], "Entry", "\t"); add_pre(name); - printc("\tif (vop->"name" !=3D NULL)") - printc("\t\trc =3D vop->"name"(a);") - printc("\telse") - printc("\t\trc =3D vop->vop_bypass(&a->a_gen);") + printc("\trc =3D vop->"name"(a);") printc(ctrstr); printc("\tif (rc =3D=3D 0) {"); for (i =3D 0; i < numargs; ++i) @@ -424,7 +422,11 @@ } =20 if (pfile) - printp("};") + printp("};\n" \ + "\n" \ + "#define\t_VOP_VECTOR_COUNT\t"numvops"\n" \ + "#define\t_VOP_VECTOR_ARRAY(vop) \\\n" \ + "\t(vop_bypass_t **)((void *)&(vop)->"firstvop")") =20 if (hfile) close(hfile); Index: sys/fs/unionfs/union_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/unionfs/union_vnops.c (revision 182995) +++ sys/fs/unionfs/union_vnops.c (working copy) @@ -2278,8 +2278,6 @@ } =20 struct vop_vector unionfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D unionfs_access, .vop_aclcheck =3D unionfs_aclcheck, .vop_advlock =3D unionfs_advlock, @@ -2326,3 +2324,4 @@ .vop_write =3D unionfs_write, .vop_vptofh =3D unionfs_vptofh, }; +DECLARE_VOP_VECTOR(unionfs_vnodeops); Index: sys/fs/deadfs/dead_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/deadfs/dead_vnops.c (revision 182995) +++ sys/fs/deadfs/dead_vnops.c (working copy) @@ -52,8 +52,6 @@ static vop_rename_t dead_rename; =20 struct vop_vector dead_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_EBADF, .vop_advlock =3D VOP_EBADF, .vop_bmap =3D dead_bmap, @@ -80,6 +78,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D dead_write, }; +DECLARE_VOP_VECTOR(dead_vnodeops); =20 /* ARGSUSED */ static int Index: sys/fs/pseudofs/pseudofs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/pseudofs/pseudofs_vnops.c (revision 182995) +++ sys/fs/pseudofs/pseudofs_vnops.c (working copy) @@ -864,8 +864,6 @@ * Vnode operations */ struct vop_vector pfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D pfs_access, .vop_cachedlookup =3D pfs_lookup, .vop_close =3D pfs_close, @@ -890,3 +888,4 @@ .vop_write =3D pfs_write, /* XXX I've probably forgotten a few that need VOP_EOPNOTSUPP */ }; +DECLARE_VOP_VECTOR(pfs_vnodeops); Index: sys/fs/tmpfs/tmpfs_fifoops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/tmpfs/tmpfs_fifoops.c (revision 182995) +++ sys/fs/tmpfs/tmpfs_fifoops.c (working copy) @@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$"); =20 #include +#include #include #include #include @@ -88,7 +89,6 @@ * vnode operations vector used for fifos stored in a tmpfs file system. */ struct vop_vector tmpfs_fifoop_entries =3D { - .vop_default =3D &fifo_specops, .vop_close =3D tmpfs_fifo_close, .vop_reclaim =3D tmpfs_reclaim, .vop_access =3D tmpfs_access, @@ -96,4 +96,4 @@ .vop_setattr =3D tmpfs_setattr, .vop_kqfilter =3D tmpfs_fifo_kqfilter, }; - +DECLARE_VOP_VECTOR(tmpfs_fifoop_entries); Index: sys/fs/tmpfs/tmpfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/tmpfs/tmpfs_vnops.c (revision 182995) +++ sys/fs/tmpfs/tmpfs_vnops.c (working copy) @@ -38,6 +38,7 @@ =20 #include #include +#include #include #include #include @@ -1443,7 +1444,6 @@ * vnode operations vector used for files stored in a tmpfs file system. */ struct vop_vector tmpfs_vnodeop_entries =3D { - .vop_default =3D &default_vnodeops, .vop_lookup =3D vfs_cache_lookup, .vop_cachedlookup =3D tmpfs_lookup, .vop_create =3D tmpfs_create, @@ -1471,4 +1471,4 @@ .vop_vptofh =3D tmpfs_vptofh, .vop_bmap =3D VOP_EOPNOTSUPP, }; - +DECLARE_VOP_VECTOR(tmpfs_vnodeop_entries); Index: sys/fs/portalfs/portal_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/portalfs/portal_vnops.c (revision 182995) +++ sys/fs/portalfs/portal_vnops.c (working copy) @@ -551,8 +551,6 @@ } =20 struct vop_vector portal_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_NULL, .vop_getattr =3D portal_getattr, .vop_lookup =3D portal_lookup, @@ -562,3 +560,4 @@ .vop_reclaim =3D portal_reclaim, .vop_setattr =3D portal_setattr, }; +DECLARE_VOP_VECTOR(portal_vnodeops); Index: sys/fs/hpfs/hpfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/hpfs/hpfs_vnops.c (revision 182995) +++ sys/fs/hpfs/hpfs_vnops.c (working copy) @@ -1230,8 +1230,6 @@ * Global vfs data structures */ struct vop_vector hpfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D hpfs_access, .vop_bmap =3D hpfs_bmap, .vop_cachedlookup =3D hpfs_lookup, @@ -1254,3 +1252,4 @@ .vop_write =3D hpfs_write, .vop_vptofh =3D hpfs_vptofh, }; +DECLARE_VOP_VECTOR(hpfs_vnodeops); Index: sys/fs/nullfs/null_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/nullfs/null_vnops.c (revision 182995) +++ sys/fs/nullfs/null_vnops.c (working copy) @@ -747,3 +747,4 @@ .vop_unlock =3D null_unlock, .vop_vptofh =3D null_vptofh, }; +DECLARE_VOP_VECTOR(null_vnodeops); Index: sys/fs/coda/coda_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/coda/coda_vnops.c (revision 182995) +++ sys/fs/coda/coda_vnops.c (working copy) @@ -110,7 +110,6 @@ * Definition of the vnode operation vector. */ struct vop_vector coda_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_cachedlookup =3D coda_lookup, /* uncached lookup */ .vop_lookup =3D vfs_cache_lookup, /* namecache lookup */ .vop_create =3D coda_create, /* create */ @@ -150,6 +149,7 @@ #endif =20 }; +DECLARE_VOP_VECTOR(coda_vnodeops); =20 static void coda_print_vattr(struct vattr *attr); =20 Index: sys/fs/devfs/devfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/devfs/devfs_vnops.c (revision 182995) +++ sys/fs/devfs/devfs_vnops.c (working copy) @@ -1432,8 +1432,6 @@ }; =20 static struct vop_vector devfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D devfs_access, .vop_getattr =3D devfs_getattr, .vop_ioctl =3D devfs_rioctl, @@ -1452,10 +1450,9 @@ #endif .vop_symlink =3D devfs_symlink, }; +DECLARE_VOP_VECTOR(devfs_vnodeops); =20 static struct vop_vector devfs_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D devfs_access, .vop_advlock =3D devfs_advlock, .vop_bmap =3D VOP_PANIC, @@ -1487,6 +1484,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D VOP_PANIC, }; +DECLARE_VOP_VECTOR(devfs_specops); =20 /* * Our calling convention to the device drivers used to be that we passed Index: sys/fs/smbfs/smbfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/smbfs/smbfs_vnops.c (revision 182995) +++ sys/fs/smbfs/smbfs_vnops.c (working copy) @@ -86,8 +86,6 @@ static vop_getextattr_t smbfs_getextattr; =20 struct vop_vector smbfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D smbfs_access, .vop_advlock =3D smbfs_advlock, .vop_close =3D smbfs_close, @@ -118,6 +116,7 @@ .vop_symlink =3D smbfs_symlink, .vop_write =3D smbfs_write, }; +DECLARE_VOP_VECTOR(smbfs_vnodeops); =20 static int smbfs_access(ap) Index: sys/fs/ntfs/ntfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/ntfs/ntfs_vnops.c (revision 182995) +++ sys/fs/ntfs/ntfs_vnops.c (working copy) @@ -756,8 +756,6 @@ * Global vfs data structures */ struct vop_vector ntfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D ntfs_access, .vop_bmap =3D ntfs_bmap, .vop_cachedlookup =3D ntfs_lookup, @@ -775,3 +773,4 @@ .vop_write =3D ntfs_write, .vop_vptofh =3D ntfs_vptofh, }; +DECLARE_VOP_VECTOR(ntfs_vnodeops); Index: sys/fs/cd9660/cd9660_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/cd9660/cd9660_vnops.c (revision 182995) +++ sys/fs/cd9660/cd9660_vnops.c (working copy) @@ -827,7 +827,6 @@ * Global vfs data structures for cd9660 */ struct vop_vector cd9660_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D cd9660_open, .vop_access =3D cd9660_access, .vop_bmap =3D cd9660_bmap, @@ -845,6 +844,7 @@ .vop_strategy =3D cd9660_strategy, .vop_vptofh =3D cd9660_vptofh, }; +DECLARE_VOP_VECTOR(cd9660_vnodeops); =20 /* * Special device vnode ops @@ -859,3 +859,4 @@ .vop_setattr =3D cd9660_setattr, .vop_vptofh =3D cd9660_vptofh, }; +DECLARE_VOP_VECTOR(cd9660_fifoops); Index: sys/fs/fifofs/fifo_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/fifofs/fifo_vnops.c (revision 182995) +++ sys/fs/fifofs/fifo_vnops.c (working copy) @@ -109,8 +109,6 @@ { 1, NULL, filt_fifodetach_notsup, filt_fifo_notsup }; =20 struct vop_vector fifo_specops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_EBADF, .vop_advlock =3D fifo_advlock, .vop_close =3D fifo_close, @@ -137,6 +135,7 @@ .vop_symlink =3D VOP_PANIC, .vop_write =3D VOP_PANIC, }; +DECLARE_VOP_VECTOR(fifo_specops); =20 struct mtx fifo_mtx; MTX_SYSINIT(fifo, &fifo_mtx, "fifo mutex", MTX_DEF); Index: sys/fs/fdescfs/fdesc_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/fdescfs/fdesc_vnops.c (revision 182995) +++ sys/fs/fdescfs/fdesc_vnops.c (working copy) @@ -72,8 +72,6 @@ static vop_setattr_t fdesc_setattr; =20 static struct vop_vector fdesc_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D VOP_NULL, .vop_getattr =3D fdesc_getattr, .vop_lookup =3D fdesc_lookup, @@ -83,6 +81,7 @@ .vop_reclaim =3D fdesc_reclaim, .vop_setattr =3D fdesc_setattr, }; +DECLARE_VOP_VECTOR(fdesc_vnodeops); =20 static void fdesc_insmntque_dtr(struct vnode *, void *); static void fdesc_remove_entry(struct fdescnode *); Index: sys/fs/nwfs/nwfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/nwfs/nwfs_vnops.c (revision 182995) +++ sys/fs/nwfs/nwfs_vnops.c (working copy) @@ -84,8 +84,6 @@ =20 /* Global vfs data structures for nwfs */ struct vop_vector nwfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D nwfs_access, .vop_close =3D nwfs_close, .vop_create =3D nwfs_create, @@ -113,6 +111,7 @@ .vop_symlink =3D nwfs_symlink, .vop_write =3D nwfs_write, }; +DECLARE_VOP_VECTOR(nwfs_vnodeops); =20 /* * nwfs_access vnode op Index: sys/fs/msdosfs/msdosfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/msdosfs/msdosfs_vnops.c (revision 182995) +++ sys/fs/msdosfs/msdosfs_vnops.c (working copy) @@ -54,6 +54,7 @@ #include #include #include +#include #include #include #include @@ -1965,8 +1966,6 @@ =20 /* Global vfs data structures for msdosfs */ struct vop_vector msdosfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D msdosfs_access, .vop_bmap =3D msdosfs_bmap, .vop_cachedlookup =3D msdosfs_lookup, @@ -1994,3 +1993,4 @@ .vop_write =3D msdosfs_write, .vop_vptofh =3D msdosfs_vptofh, }; +DECLARE_VOP_VECTOR(msdosfs_vnodeops); Index: sys/fs/udf/udf_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/fs/udf/udf_vnops.c (revision 182995) +++ sys/fs/udf/udf_vnops.c (working copy) @@ -74,8 +74,6 @@ daddr_t *sector, uint32_t *max_size); =20 static struct vop_vector udf_vnodeops =3D { - .vop_default =3D &default_vnodeops, - .vop_access =3D udf_access, .vop_bmap =3D udf_bmap, .vop_cachedlookup =3D udf_lookup, @@ -91,6 +89,7 @@ .vop_strategy =3D udf_strategy, .vop_vptofh =3D udf_vptofh, }; +DECLARE_VOP_VECTOR(udf_vnodeops); =20 MALLOC_DEFINE(M_UDFFID, "udf_fid", "UDF FileId structure"); MALLOC_DEFINE(M_UDFDS, "udf_ds", "UDF Dirstream structure"); Index: sys/nfs4client/nfs4_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/nfs4client/nfs4_vnops.c (revision 182995) +++ sys/nfs4client/nfs4_vnops.c (working copy) @@ -162,7 +162,6 @@ * Global vfs data structures for nfs */ struct vop_vector nfs4_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_access =3D nfs4_access, .vop_advlock =3D nfs4_advlock, .vop_advlockasync =3D nfs4_advlockasync, @@ -192,6 +191,7 @@ .vop_symlink =3D nfs4_symlink, .vop_write =3D nfs_write, }; +DECLARE_VOP_VECTOR(nfs4_vnodeops); =20 static int nfs4_removerpc(struct vnode *dvp, const char *name, int namelen, struct ucred *cred, struct thread *td); Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (revision 18= 2995) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c (working cop= y) @@ -3526,7 +3526,6 @@ struct vop_vector zfs_fifoops; =20 struct vop_vector zfs_vnodeops =3D { - .vop_default =3D &default_vnodeops, .vop_inactive =3D zfs_freebsd_inactive, .vop_reclaim =3D zfs_freebsd_reclaim, .vop_access =3D zfs_freebsd_access, @@ -3558,6 +3557,7 @@ .vop_bmap =3D VOP_EOPNOTSUPP, .vop_fid =3D zfs_freebsd_fid, }; +DECLARE_VOP_VECTOR(zfs_vnodeops); =20 struct vop_vector zfs_fifoops =3D { .vop_default =3D &fifo_specops, @@ -3571,3 +3571,4 @@ .vop_write =3D VOP_PANIC, .vop_fid =3D zfs_freebsd_fid, }; +DECLARE_VOP_VECTOR(zfs_fifoops); Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c (revision 1= 82995) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c (working co= py) @@ -436,7 +436,6 @@ } =20 static struct vop_vector zfsctl_ops_root =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D zfsctl_common_open, .vop_close =3D zfsctl_common_close, .vop_ioctl =3D VOP_EINVAL, @@ -448,6 +447,7 @@ .vop_reclaim =3D zfsctl_common_reclaim, .vop_fid =3D zfsctl_common_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_root); =20 static int zfsctl_snapshot_zname(vnode_t *vp, const char *name, int len, char *zname) @@ -840,7 +840,6 @@ } =20 static struct vop_vector zfsctl_ops_snapdir =3D { - .vop_default =3D &default_vnodeops, .vop_open =3D zfsctl_common_open, .vop_close =3D zfsctl_common_close, .vop_ioctl =3D VOP_EINVAL, @@ -852,6 +851,7 @@ .vop_reclaim =3D zfsctl_common_reclaim, .vop_fid =3D zfsctl_common_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_snapdir); =20 static vnode_t * zfsctl_snapshot_mknode(vnode_t *pvp, uint64_t objset) @@ -987,12 +987,12 @@ * be covered. */ static struct vop_vector zfsctl_ops_snapshot =3D { - .vop_default =3D &default_vnodeops, .vop_inactive =3D zfsctl_snapshot_inactive, .vop_reclaim =3D zfsctl_common_reclaim, .vop_getattr =3D zfsctl_snapshot_getattr, .vop_fid =3D zfsctl_snapshot_fid, }; +DECLARE_VOP_VECTOR(zfsctl_ops_snapshot); =20 int zfsctl_lookup_objset(vfs_t *vfsp, uint64_t objsetid, zfsvfs_t **zfsvfsp) Index: sys/sys/vnode.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/sys/vnode.h (revision 182995) +++ sys/sys/vnode.h (working copy) @@ -718,8 +718,11 @@ =20 extern struct vop_vector fifo_specops; extern struct vop_vector dead_vnodeops; -extern struct vop_vector default_vnodeops; =20 +void vop_vector_init(void *arg); +#define DECLARE_VOP_VECTOR(name) \ + SYSINIT(name, SI_SUB_VFS, SI_ORDER_ANY, vop_vector_init, &name) + #define VOP_PANIC ((void*)(uintptr_t)vop_panic) #define VOP_NULL ((void*)(uintptr_t)vop_null) #define VOP_EBADF ((void*)(uintptr_t)vop_ebadf) --vTUhhhdwRI43FzeR-- --egxrhndXibJAPJ54 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjjynAACgkQ52SDGA2eCwXSCwCeOQlljPRORRZ7th46uy0ZPB7N u0oAnjYVG7zx0v6S4WZxB+CXI+GgUB9x =Cd+S -----END PGP SIGNATURE----- --egxrhndXibJAPJ54-- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 19:47:00 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015331065699 for ; Wed, 1 Oct 2008 19:47:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 927118FC21 for ; Wed, 1 Oct 2008 19:46:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B80F3170E4; Wed, 1 Oct 2008 19:46:57 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id m91JktR5069187; Wed, 1 Oct 2008 19:46:55 GMT (envelope-from phk@critter.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 01 Oct 2008 21:07:28 +0200." <20081001190728.GL16837@hoeg.nl> Date: Wed, 01 Oct 2008 19:46:55 +0000 Message-ID: <69186.1222890415@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD FS , Mark van Cuijk , Jille Timmermans , FreeBSD Arch Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 19:47:00 -0000 In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >The reason I'm sending this message, is because based on discussions I >had with several people on IRC we've basically got two different >opinions on this patch: > >- One group of people liked the idea of the patch. Some people even said > the patch looks good enough to be committed. > >- Another group of people also liked the idea, but thought it would make > no sense to commit it, because it's not like it's a bottleneck right > now. It should only be committed if an increase in performance is > notable. > >I did some tests with the patch set, by running tens of millions of >fstat(), fchown(), etc. calls to see how performance was affected. It >turns out on a kernel without any debugging options enabled, the >performance gain is only 1-2%, which sounds pretty valid to me. My resistance to this patch is not quite what you describe above: By factoring the vop vectors out, you remove the ability to let default vectors pick up new functionality later. I will admit that I have no knowledge of this level of generality, dating back from Heidemans Phd. dissertation, being used for anything sensible. Furthermore, if I am not mistaken, your patch increases the kernel size. Absent a plausible performance improvement, I don't see any point of your change. And that brings me to your "1-2%" measurement quoted in IRC and above. I have earlier ranted about the difference between benchmarking and random number generators, and you may have joined the project after the latest of these. Please search the mail-archives for that topic, and then use the handy ministat(1) program, to see if you have actually show any net speed benefit. Once and if you cross that threshold, I am going to raise my next objection: Benchmarking "tens of millions of fstat(), fchown(), etc. calls" and showing a 1-2% difference is patently bogus, and certainly no reason for the change you propose. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 20:21:10 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC38106568B; Wed, 1 Oct 2008 20:21:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:3fb::211]) by mx1.freebsd.org (Postfix) with ESMTP id B5AC28FC08; Wed, 1 Oct 2008 20:21:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id DB3FA1CD1C; Wed, 1 Oct 2008 22:21:08 +0200 (CEST) Date: Wed, 1 Oct 2008 22:21:08 +0200 From: Ed Schouten To: Poul-Henning Kamp Message-ID: <20081001202108.GO16837@hoeg.nl> References: <69186.1222890415@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ccJhwVfaC+fHwTsl" Content-Disposition: inline In-Reply-To: <69186.1222890415@critter.freebsd.dk> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD FS , Mark van Cuijk , Jille Timmermans , FreeBSD Arch Subject: Re: Expanding vops in vop_vectors during startup X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 20:21:10 -0000 --ccJhwVfaC+fHwTsl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Poul-Henning, * Poul-Henning Kamp wrote: > In message <20081001190728.GL16837@hoeg.nl>, Ed Schouten writes: >=20 > >The reason I'm sending this message, is because based on discussions I > >had with several people on IRC we've basically got two different > >opinions on this patch: > > > >- One group of people liked the idea of the patch. Some people even said > > the patch looks good enough to be committed. > > > >- Another group of people also liked the idea, but thought it would make > > no sense to commit it, because it's not like it's a bottleneck right > > now. It should only be committed if an increase in performance is > > notable. > > > >I did some tests with the patch set, by running tens of millions of > >fstat(), fchown(), etc. calls to see how performance was affected. It > >turns out on a kernel without any debugging options enabled, the > >performance gain is only 1-2%, which sounds pretty valid to me. >=20 >=20 > My resistance to this patch is not quite what you describe above: >=20 > By factoring the vop vectors out, you remove the ability to let > default vectors pick up new functionality later. Could you give me an example of such functionality? You mean extending a vop_vector? That shouldn't be a problem, right? If such functionality really seems to be in conflict with this modification, it's not like we're carving things in stone here. > I will admit that I have no knowledge of this level of generality, > dating back from Heidemans Phd. dissertation, being used for anything > sensible. >=20 > Furthermore, if I am not mistaken, your patch increases the kernel > size. Even though I admit I don't have that many file system types compiled into my kernel, binary size is 2203 bytes smaller with my patch applied. If you have a whole bunch of filesystems compiled into your kernel, these numbers might be a little different. We now need an extra SYSINIT per struct vop_vector. > Absent a plausible performance improvement, I don't see any point > of your change. >=20 > And that brings me to your "1-2%" measurement quoted in IRC and > above. >=20 > I have earlier ranted about the difference between benchmarking=20 > and random number generators, and you may have joined the project > after the latest of these. >=20 > Please search the mail-archives for that topic, and then use > the handy ministat(1) program, to see if you have actually=20 > show any net speed benefit. >=20 > Once and if you cross that threshold, I am going to raise my next > objection: >=20 > Benchmarking "tens of millions of fstat(), fchown(), etc. calls" > and showing a 1-2% difference is patently bogus, and certainly > no reason for the change you propose. ministat(1) also mentions a 2% improvement with 95.0% confidence. Quite a nifty tool. Thanks for pointing me to it. About the benchmarks: the reason why I decided to test these things, was because I didn't want to measure disk I/O performance. I just wanted to see how performance was different with respect to VOP_*() calls. This means most of the cases I tested scenario's when data would already be available from cache or on pseudo-filesystems, where real disk I/O would not occur. But as I said: I am not going to commit it. End of discussion. --=20 Ed Schouten WWW: http://80386.nl/ --ccJhwVfaC+fHwTsl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkjj27QACgkQ52SDGA2eCwWqPgCfUKBUYLojYXtQdUm3/h71Z/gf lzMAnjGwVodxtPVsvJ700h73MPZ7Xylk =/2f/ -----END PGP SIGNATURE----- --ccJhwVfaC+fHwTsl-- From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 23:01:34 2008 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AAA1065686; Wed, 1 Oct 2008 23:01:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id 732718FC15; Wed, 1 Oct 2008 23:01:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CAF9119E023; Thu, 2 Oct 2008 01:01:32 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 975AE19E019; Thu, 2 Oct 2008 01:01:30 +0200 (CEST) Message-ID: <48E4016C.5000909@quip.cz> Date: Thu, 02 Oct 2008 01:02:04 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pjd@FreeBSD.org Subject: ZFS inodes issue (0 reported by df -hi) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 23:01:34 -0000 I am stresstesting ZFS filesystem on my test machine and sometimes see wrong output of df in inodes columns - reporting zero used inodes when more than 53 milions are used. Bellow is df -hi reports taken in few seconds / minutes (there are running some heavy copying tasks in the background) [other partitions was stripped for clarity] root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 362G 1.9G 99% 0 15915 0% /tank ^^^^^^ ^^^^^^ root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 362G 1.9G 99% 53382659 15757 100% /tank root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 362G 1.9G 99% 53391685 15503 100% /tank root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 363G 1.3G 100% 0 10965 0% /tank ^^^^^^ ^^^^^^ root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 363G 1.3G 100% 53591981 10817 100% /tank root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 363G 1.0G 100% 0 8267 0% /tank ^^^^^^ ^^^^^^ root@cage ~/# df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted tank 364G 363G 1.0G 100% 53672433 8245 100% /tank Next thing that I do not understand is how ZFS uses inodes? The total number of inodes (iused+ifree) grows by the time as filesystem is more and more filled. Version: FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18 06:48:16 UTC 2008 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Miroslav Lachman From owner-freebsd-fs@FreeBSD.ORG Wed Oct 1 23:08:58 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D4C31065686 for ; Wed, 1 Oct 2008 23:08:58 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id E7A618FC1E for ; Wed, 1 Oct 2008 23:08:57 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 7EEC139D55 for ; Thu, 2 Oct 2008 01:08:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixoklkCyclQ1 for ; Thu, 2 Oct 2008 01:08:56 +0200 (CEST) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id E8615391CC; Thu, 2 Oct 2008 01:08:55 +0200 (CEST) Date: Thu, 2 Oct 2008 01:08:55 +0200 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20081001230855.GA70612@keltia.freenix.fr> References: <48E4016C.5000909@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E4016C.5000909@quip.cz> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: ZFS inodes issue (0 reported by df -hi) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2008 23:08:58 -0000 According to Miroslav Lachman: > Next thing that I do not understand is how ZFS uses inodes? The total > number of inodes (iused+ifree) grows by the time as filesystem is more > and more filled. znodes in ZFS are automatically created when needed (and I assume garbage collected as well). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; i386 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 3 09:10:27 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03421065687 for ; Fri, 3 Oct 2008 09:10:27 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7C8298FC1A for ; Fri, 3 Oct 2008 09:10:27 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so257772ywe.13 for ; Fri, 03 Oct 2008 02:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=R0PxQ2qwsYmcK8RuBcMTIiom4uUCkT/UCDsQg/mbEDI=; b=uH3h2ftEpA598lg6HHdgBE3fDBB8ZQq+870n9AskibYEjQe0uAr7Y7hR1toyOVIEEI HidKQZMU4xnGAZu6bVLI+jiME90lWcWdlBzRd/rQLuJlvcSrFzmpCSHSUATKR2onSfF1 CJrvcY5oe31HBHS9Gla3MvGgdImnQPp3KgNcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=uf4DTui/QyRGDlGQ+vQ3G+W1BTS9yBmp8tk/lmqvJRvybKCwXzl/wpIvP80b87AcR/ znO4fBzMg3rKbHwNzcWh3+PSOY5hzenmUazSk+yIsMNEIIH+xfbkz9ckHqCF7MK/DiN/ UwtPGpGNyX9CVR+p3UJonwxoMqHAnK6YDM5yA= Received: by 10.100.178.7 with SMTP id a7mr872598anf.80.1223023705084; Fri, 03 Oct 2008 01:48:25 -0700 (PDT) Received: by 10.100.253.17 with HTTP; Fri, 3 Oct 2008 01:48:25 -0700 (PDT) Message-ID: <9e20d71e0810030148p30cb5f4xb8fe368dccaeb87@mail.gmail.com> Date: Fri, 3 Oct 2008 11:48:25 +0300 From: "Artis Caune" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ZFS on root with atime=off X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 09:10:27 -0000 Hi everyone, I install ZFS on root just like in Andrew ZFSOnRoot wiki page. I don't use legacy mount points. I also set "atime=off" on tank and all partitions inherit it from tank. When I reboot after install, root file system is mounted with atime option: # zfs get atime tank NAME PROPERTY VALUE SOURCE tank atime on temporary I can fix this with creating entry in fstab for root fs with noatime, but maybe there is some way how to pass options to vfs.root.mountfrom? -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From owner-freebsd-fs@FreeBSD.ORG Fri Oct 3 11:25:07 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E41B31065699 for ; Fri, 3 Oct 2008 11:25:07 +0000 (UTC) (envelope-from mboxindia@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id A23AB8FC0C for ; Fri, 3 Oct 2008 11:25:07 +0000 (UTC) (envelope-from mboxindia@gmail.com) Received: by qb-out-0506.google.com with SMTP id f30so1042346qba.35 for ; Fri, 03 Oct 2008 04:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=41CAs5YG3Y/+dGWLdvBpnNnYiwrifH3/qthiI2HjApk=; b=bnBJbyyra5alrptawZc7g6XebvsEy40DNwxyEu6+XD6OCbbV90Q9pqN8AHt+4UQrXg pS7vvatPoUp+mPp0/Ekm2thRSxoIpoZKMKIDKRCQFGUAesKPkopswrUzu3TTzYEf06SI joSCaQPOjripAVCwytHGIiWidWf7tj7ejXBVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=w/Js4i+M3mQhZcgU8cjZG8sDDEN/Ut734LqEMGD+nM1ue2v3jIvXkrV73xg/hL5Oe6 Z1AarzOlkEStPIU4uHLEg2gm6ZKwDlHSrOTyLla52wwVa1oK9fYU9fFFr+iGdrqfnvnn rvkl2lyM7PhsIb7K6oxXlPZ4sb20Zkc6RVuVc= Received: by 10.103.248.1 with SMTP id a1mr541846mus.57.1223032148351; Fri, 03 Oct 2008 04:09:08 -0700 (PDT) Received: by 10.103.141.5 with HTTP; Fri, 3 Oct 2008 04:09:07 -0700 (PDT) Message-ID: Date: Fri, 3 Oct 2008 16:39:07 +0530 From: "Srinivas Srinivas" To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: options of configuration file X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 11:25:08 -0000 Hello, May be these are beginner questions ... could you plz answer the following questions? I think "options" line and "device" line are in the configuration file, in order to support those features and devices. I see that sed script will parse that file. Could you plz let me know what will be done in this phase and how these lines will be transferred into gcc define directives(in the case of options) and inclusion of source files for compilation(in case of device). I have seen lint in some Makefiles, but dont know why it was used. Why is lint used? The "device" line adds device support to the kernel. What exactly does this mean. A more basic question is: how the devices are detected initially by the FreeBSD with the aid of hardware and bios? I think this is a broad topic. Could you plz provide a link if there is any info, you know, in the net? Thanks, Srinivas From owner-freebsd-fs@FreeBSD.ORG Fri Oct 3 11:52:13 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E82A1065692 for ; Fri, 3 Oct 2008 11:52:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3408FC1C for ; Fri, 3 Oct 2008 11:52:13 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 05167207E; Fri, 3 Oct 2008 13:32:52 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id DEA2584483; Fri, 3 Oct 2008 13:32:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Srinivas Srinivas" References: Date: Fri, 03 Oct 2008 13:32:52 +0200 In-Reply-To: (Srinivas Srinivas's message of "Fri, 3 Oct 2008 16:39:07 +0530") Message-ID: <86fxndvrq3.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: options of configuration file X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2008 11:52:13 -0000 "Srinivas Srinivas" writes: > I think "options" line and "device" line are in the configuration file, in > order to support those features and devices. I see that sed script will > parse that file. No, it's a C program: config(8). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-fs@FreeBSD.ORG Sat Oct 4 21:29:12 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F5410656A2 for ; Sat, 4 Oct 2008 21:29:12 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from mail.tnode.com (common.tnode.com [91.185.203.243]) by mx1.freebsd.org (Postfix) with ESMTP id 5F3798FC1C for ; Sat, 4 Oct 2008 21:29:10 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (mail.jail [10.1.1.10]) by mail.tnode.com (Postfix) with ESMTP id 2CA7F21FC4C2; Sat, 4 Oct 2008 23:11:44 +0200 (CEST) Received: from mail.tnode.com ([10.1.1.10]) by localhost (mail.tnode.com [10.1.1.10]) (amavisd-maia, port 10024) with ESMTP id 83043-01; Sat, 4 Oct 2008 23:11:43 +0200 (CEST) Received: from [192.168.10.12] (BSN-61-71-228.static.dsl.siol.net [86.61.71.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejc@skoberne.net) by mail.tnode.com (Postfix) with ESMTPSA id E5EE221FBFCE; Sat, 4 Oct 2008 23:11:42 +0200 (CEST) Message-ID: <48E7DC0E.1060008@skoberne.net> Date: Sat, 04 Oct 2008 23:11:42 +0200 From: Nejc Skoberne User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: Mitar , Weiss Subject: Rewinding on unionfs and Subversion X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2008 21:29:12 -0000 Hello, with my friend we tried to install Subversion in a jail on a unionfs filesystem. Unfortunately, the subversion FreeBSD port doesn't do "make check" before installing, so we spent quite some time debugging to find out it was actually a filesystem bug. 1. The bug in real world. ------------------------- When trying to make a "svn commit" or "svn import", errors similar to these show up in apache error log: [Wed Oct 01 21:04:35 2008] [error] [client 10.1.1.11] Could not MERGE resource "/svn/test2/!svn/act/e28480c9-eb8f-dd11-808c-0018fe7759ca" into "/svn/test2". [409, #0] [Wed Oct 01 21:04:35 2008] [error] [client 10.1.1.11] An error occurred while committing the transaction. [409, #2] [Wed Oct 01 21:04:35 2008] [error] [client 10.1.1.11] Can't remove '/usr/local/svn/test2/db/transactions/2-2.txn/node.0.0' [409, #2] [Wed Oct 01 21:04:35 2008] [error] [client 10.1.1.11] Can't remove file '/usr/local/svn/test2/db/transactions/2-2.txn/node.0.0': No such file or directory [409, #2] The last error is also shown up at client side (svn binary). However, all actions are succesfully accomplished, so the error shouldn't appear at all. Also, when doing "make check" after building subversion from source, would also fail with identical errors. 2. Bug location --------------- After some ktracing and tracing the function calls back to the "root", we discovered that the bug is probably present in Standard C library. We are not sure yet, where in libc exactly it is located. 3. Proof of concept code ------------------------ The following code below works fine on UFS, but fails on unionfs. The code itself was taken from subversion codebase and is rewritten not to use Apache apr library, but uses libc functions directly instead. It just shows that there are discrepancies in UFS vs. unionfs behaviour. If the bug in libc was fixed to make this example work, we believe that also subversion would work normally on unionfs. ----------------------------------------------------------------------- #include #include #include #include #include typedef struct dirent direntry; int remove_dir(char *path) { int need_rewind; if (path[0] == '\0') path = "."; DIR *dir; if ((dir = opendir(path)) == NULL) { perror("opendir"); return 1; } do { need_rewind = 0; int ret; long position; direntry entry; direntry *result; while (1) { if (readdir_r(dir, &entry, &result) != 0) { perror("readdir_r"); return 1; } if (result == NULL) { break; } printf("Working on '%s'\n", entry.d_name); printf(" entry.d_fileno is %d\n", entry.d_fileno); if ((entry.d_type == DT_DIR) && ((strcmp(entry.d_name, ".") == 0) || (strcmp(entry.d_name, "..") == 0))) { continue; } else { char fullpath[1000]; need_rewind = 1; strcpy(fullpath, path); strcat(fullpath, "/"); strcat(fullpath, entry.d_name); printf(" fullpath is '%s'\n", fullpath); if (entry.d_type == DT_DIR) { if (remove_dir(fullpath)) { return 1; } } else { if (unlink(fullpath) == -1) { perror("unlink"); return 1; } } } } if (need_rewind) { printf("Rewinding\n"); rewinddir(dir); } } while (need_rewind); if (closedir(dir) == -1) { perror("closedir"); return 1; } if (rmdir(path) == -1) { perror("rmdir"); return 1; } return 0; } int main(int argc, const char *const argv[]) { if (mkdir("test", 0755) == -1) { perror("mkdir"); return 1; } int file = -1; if ((file = open("test/file", O_WRONLY | O_CREAT | O_TRUNC, 0644)) == -1) { perror("open"); return 1; } if (close(file) == -1) { perror("close"); return 1; } if (remove_dir("test")) { printf("Test failed\n"); return 1; } else { printf("It works as it should\n"); return 0; } } ------------------------------------------------------------------------- 4. Conclusion ------------- We will also file this as PR, but I wanted to share this with this list too. Also, does anyone know who is "in charge" of unionfs implementation on FreeBSD? Who is the "leading" developer? This is not the only bug left to be fixed for unionfs to be production-ready, and we are really looking forward to cooperate with (a) commiter(s), who would be prepared to fix at least the most nasty ones. We are also preparing the list of the most annoying unionfs bugs, which still need to be fixed. This issue is of course one of them. Thanks, Nejc