From owner-freebsd-fs Tue Sep 5 4: 2:33 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id CCFB337B423; Tue, 5 Sep 2000 04:02:25 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 3166F28AAD; Tue, 5 Sep 2000 18:02:19 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 1B1D7288C7; Tue, 5 Sep 2000 18:02:19 +0700 (ALMST) Date: Tue, 5 Sep 2000 18:02:19 +0700 (ALMST) From: Boris Popov To: freebsd-fs@freebsd.org Cc: dillon@freebsd.org, semenu@freebsd.org, tegge@freebsd.org Subject: CFR: nullfs, vm_objects and locks... (patch) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Last few days I've spent trying make nullfs really functional and stable. There are many issues with the current nullfs code, but below I'll try to outline the most annoying ones. The first one, is an inability to handle mmap() operation. This comes from the VM/vnode_pager design where each vm_object associated with a single vnode and vise versa. Looking at the problem in general one may note, that stackable filesystems may have either separated vm_object per layer or don't have it at all. Since nullfs essentially maps its vnodes to underlying filesystem, it is reasonable to map all operations to underlying vnode. The above goal can be reached in two ways (at least): 1. Create a special vm pager (call it null_pager) which will map all operations to underlying vm_object. 2. Give each filesystem control over vm_object handling (eg, creating/destroying and access). I've played with both variants and later seems to be more simple to implement. To do this we need three additional VOPs: VOP_CREATEVOBJECT(struct vnode *vp); VOP_DESTROYVOBJECT(struct vnode *vp); VOP_GETVOBJECT(struct vnode *vp, struct vm_object **obj); First operation lets filesystem to create its own vm object, second destroy it and third - return the reference to the real vm_object. The rest of VFS/BIO/VM code should be adapted to not access v_object field directly, but use VOP_GETVOBJECT() call. In this way each layer can easily achieve cache coherency without any additional code. For example nullfs just returns reference to underlying vm_object and the rest of the code flows as usually. It is important that the above way gives full coherency no matter which layer modified data. The second big issue for vnode-based stacks of filesystems is a vnode state synchronization and tightly related problem - vnode locking. This is really weird problem but NetBSD guys seems to solve locking part of it. So I'll just explain their way because it works and works fine. At this moment vnode locking mechanism looks not quite good due to the lack of unification. nullfs requires strict synchronization of locking states across all layers, so each underlying filesystem should provide access to vnode locking structure and have ability to share it. Currently, each filesystem can either allocate its own lock structure or let VFS allocate one. This makes inconsistency with vnode.v_vnlock handling. The simple solution for it is to integrate lock structure into vnode and making vnode.v_vnlock initially point to it. Any filesystem above can pickup the pointer and assign it to v_vnlock field in its own vnode structure. If underlying filesystem doesn't provide any lock structure then bad times are coming and each layer can maintain its own lock state. As I said before, proper locking of vnodes is also tightly related and requires VFS changes to provide necessary information. This information is very important in the VOP_LOOKUP() functions because here all sorts of deadlocks can occur. This is done via new flag (PDIRUNLOCK) in the namei structure which should be carefully maintained by underlying filesystem when it locks or unlocks parent vnode. I've adapted both VFS and UFS code to handle it looking at how NetBSD done this task. Ok, I think it is enough for introduction and here is a link to the patch against recent -CURRENT: http://www.butya.kz/~bp/n9sys.diff With this patch I was able to do a 'make -j4 world' on top of the nullfs mounts as well as some mmap() related tests. Comments are welcome. P.S. Two hours ago Sheldon Hearn told me that Tor Egge and Semen Ustimenko worked together on the nullfs problem, but since discussion were private I didn't know anything about it and probably stepped on their to toes with my recent cleanup commit :( -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 5:49:42 2000 Delivered-To: freebsd-fs@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0552D37B422; Tue, 5 Sep 2000 05:49:39 -0700 (PDT) Received: from newsguy.com (p17-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.82]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id VAA26709; Tue, 5 Sep 2000 21:49:27 +0900 (JST) Message-ID: <39B4EBBB.9C7A5CAB@newsguy.com> Date: Tue, 05 Sep 2000 21:48:59 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR MIME-Version: 1.0 To: Boris Popov Cc: freebsd-fs@FreeBSD.ORG, dillon@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris Popov wrote: > > The simple solution for it is to integrate lock structure into > vnode and making vnode.v_vnlock initially point to it. Any filesystem > above can pickup the pointer and assign it to v_vnlock field in its own > vnode structure. If underlying filesystem doesn't provide any lock > structure then bad times are coming and each layer can maintain its own > lock state. How can it handle fs multiplexing? Ie, a single underlying layer with multiple non-stacked layers above? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@white.bunnies.bsdconspiracy.net OK, so the solar flares are my fault.. I am sorry, ok?!?! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 6:53:17 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id F171737B424 for ; Tue, 5 Sep 2000 06:53:11 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id JAA97845; Tue, 5 Sep 2000 09:52:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Sep 2000 09:52:58 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Charlie & Cc: freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). In-Reply-To: <20000905151543.A151@pavilion.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Sep 2000, Charlie & wrote: > Hi Robert, > > I'm having kernel panics in the vop_getacl area. Any ideas? > > Joe > > vop_panic[vop_getacl] > panic: Filesystem goof > (remainder of panic message below, for those curious) I'm a bit puzzled by this. On my 4.1-STABLE box, it appears to correctly return EOPNOTSUPP in the simplist invocation: > cat > tmp.c #include #include int main(int argc, char *argv[]) { acl_t acl; int error; acl = acl_get_file("/bin/sh", ACL_TYPE_ACCESS); if (error) perror("acl_get_file"); } > gcc -o tmp tmp.c -lposix1e > ./tmp acl_get_file: Operation not supported Which is the correct behavior, as none of the base file systems currently defines ACL functionality. The same should occur for acl_check_file() and acl_set_file(). I haven't tried this on 5.0-CURRENT recently, but vop_panic() should only be invoked when there is an attempt to call slot 0 of the VOP table for the file system. Slot 1, the default slot, should return EOPNOTSUPP. It looks like you attempted to invoke acl_get_file() much as above. Are you using any file system modules, and what file system was the target of acl_get_file() in? Could it be the case that your modules are out of sync with your kernel? (Not that I'd hope this was the result, but...) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services > syncing disks... 59 59 11 2 1 > done > Uptime: 6m50s > > dumping to dev ad0s2b, offset 630912 > dump ata0: resetting devices .. done > 191 failed, reason: aborted from console > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > Copyright (c) 1992-2000 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #11: Tue Sep 5 12:45:45 BST 2000 > joe@genius.systems.pavilion.net:/usr/obj/usr/src/sys/GENIUS > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 397896116 Hz > CPU: Pentium II/Pentium II Xeon/Celeron (397.90-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x66d Stepping = 13 > Features=0x183f9ff > real memory = 201261056 (196544K bytes) > avail memory = 189722624 (185276K bytes) > Preloaded elf kernel "kernel" at 0xc0573000. > Pentium Pro MTRR support enabled > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: at 7.2 irq 9 > pci0: at 7.3 > pci0: at 8.0 irq 9 > pcm0: mem 0xfec00000-0xfecfffff,0xfe000000-0xfe3fffff irq 9 at device 8.1 on pci0 > pci0: at 9.0 irq 9 > pcic-pci0: at device 10.0 on pci0 > pcic-pci1: at device 10.1 on pci0 > acpi0: on motherboard > acpi0: at 0xb2 irq 9 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model GlidePoint, device ID 0 > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > pcic0: at port 0x3e0 iomem 0xd0000 irq 10 on isa0 > pcic0: management irq 10 > pccard0: on pcic0 > pccard1: on pcic0 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1: configured irq 3 not in bitmap of probed irqs 0 > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/8 bytes threshold > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > BRIDGE 990810, have 7 interfaces > pccard: card inserted, slot 1 > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 19077MB [38760/16/63] at ata0-master using UDMA33 > acd0: DVD-ROM at ata1-master using UDMA33 > Mounting root from ufs:/dev/ad0s2a > WARNING: / was not properly dismounted > pid 115 (savecore), uid 0: exited on signal 10 (core dumped) > xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 3 slot 1 on pccard1 > xe0: Xircom CE3, bonding version 0x45, 100Mbps capable > xe0: DingoID = 0, RevisionID = 0, VendorID = 0 > xe0: Ethernet address 00:80:c7:f5:24:e0 > BRIDGE 990810, have 8 interfaces > -- index 8 type 6 phy 0 addrl 6 addr 00.80.c7.f5.24.e0 > xe0: watchdog timeout; resetting card > vop_panic[vop_getacl] > panic: Filesystem goof > panic: from debugger > Uptime: 14m53s > > dumping to dev ad0s2b, offset 630912 > dump ata0: resetting devices .. done > 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > --- > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > 461 dumppcb.pcb_cr3 = rcr3(); > (kgdb) bt > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > #1 0xc017ce0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:302 > #2 0xc017d1b1 in panic (fmt=0xc0265f94 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:550 > #3 0xc0131dbd in db_panic (addr=-1071373264, have_addr=0, count=-1, > modif=0xcca77b9c "") at /usr/src/sys/ddb/db_command.c:433 > #4 0xc0131d5d in db_command (last_cmdp=0xc02988f0, cmd_table=0xc0298750, > aux_cmd_tablep=0xc02d8128) at /usr/src/sys/ddb/db_command.c:333 > #5 0xc0131e22 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > #6 0xc0133fdf in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 > #7 0xc02421d2 in kdb_trap (type=3, code=0, regs=0xcca77ca4) > at /usr/src/sys/i386/i386/db_interface.c:158 > #8 0xc024dbb8 in trap (frame={tf_fs = -1072234480, tf_es = -900136944, > tf_ds = -861470704, tf_edi = -861438236, tf_esi = 256, > tf_ebp = -861438740, tf_isp = -861438768, tf_ebx = -1071170537, > tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, > tf_eip = -1071373264, tf_cs = 8, tf_eflags = 582, tf_esp = -1071067969, > tf_ss = -1071186621}) at /usr/src/sys/i386/i386/trap.c:569 > #9 0xc0242430 in Debugger (msg=0xc026fd43 "panic") at machine/cpufunc.h:64 > #10 0xc017d1a8 in panic (fmt=0xc0273c17 "Filesystem goof") > at /usr/src/sys/kern/kern_shutdown.c:548 > #11 0xc01a9653 in vop_panic (ap=0xcca77d24) > at /usr/src/sys/kern/vfs_default.c:142 > #12 0xc016f377 in vacl_get_acl (p=0xcca69920, vp=0xcbb3da40, type=1, > ---Type to continue, or q to quit--- > aclp=0x81bd800) at vnode_if.h:1247 > #13 0xc016f52c in __acl_get_file (p=0xcca69920, uap=0xcca77f80) > at /usr/src/sys/kern/kern_acl.c:155 > #14 0xc024e511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > tf_edi = 1, tf_esi = 136042496, tf_ebp = -1077947632, > tf_isp = -861437996, tf_ebx = 673380380, tf_edx = 0, tf_ecx = 0, > tf_eax = 347, tf_trapno = 7, tf_err = 2, tf_eip = 673616088, tf_cs = 31, > tf_eflags = 659, tf_esp = -1077947676, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1150 > #15 0xc0242b15 in Xint0x80_syscall () > #16 0x80af7c7 in ?? () > #17 0x8077805 in ?? () > #18 0x8064275 in ?? () > #19 0x806d1f5 in ?? () > #20 0x8069041 in ?? () > #21 0x8067c63 in ?? () > #22 0x809e8b3 in ?? () > #23 0x809b0a5 in ?? () > #24 0x8082cee in ?? () > #25 0x804f345 in ?? () > (kgdb) l\11   \11   #11 > Function "" not defined. > (kgdb) l   l /usr/src/sys/kern/vfs_degfaul     faui;lt    lt.c:142 > 137 int > 138 vop_panic(struct vop_generic_args *ap) > 139 { > 140 > 141 printf("vop_panic[%s]\n", ap->a_desc->vdesc_name); > 142 panic("Filesystem goof"); > 143 return (0); > 144 } > 145 > 146 /* > (kgdb) quit > # exit > > Script done on Tue Sep 5 15:12:48 2000 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 7:11:20 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id AD20B37B43E; Tue, 5 Sep 2000 07:11:14 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id E885228AAD; Tue, 5 Sep 2000 21:11:11 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id D521D288C7; Tue, 5 Sep 2000 21:11:11 +0700 (ALMST) Date: Tue, 5 Sep 2000 21:11:11 +0700 (ALMST) From: Boris Popov To: "Daniel C. Sobral" Cc: freebsd-fs@FreeBSD.ORG, dillon@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) In-Reply-To: <39B4EBBB.9C7A5CAB@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Sep 2000, Daniel C. Sobral wrote: > > The simple solution for it is to integrate lock structure into > > vnode and making vnode.v_vnlock initially point to it. Any filesystem > > above can pickup the pointer and assign it to v_vnlock field in its own > > vnode structure. If underlying filesystem doesn't provide any lock > > structure then bad times are coming and each layer can maintain its own > > lock state. > > How can it handle fs multiplexing? Ie, a single underlying layer with > multiple non-stacked layers above? Just like in the stacking case: access to vnode on the underlying filesystem should be serialized which is done by proper(shared) locking. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 7:43:16 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E118F37B424; Tue, 5 Sep 2000 07:43:06 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id KAA98355; Tue, 5 Sep 2000 10:43:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Sep 2000 10:43:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Charlie & Cc: freebsd-fs@FreeBSD.org, peter@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm. Sheldon Hearn also seems to be able to reproduce this on -CURRENT, but the ACL code hasn't changed from -STABLE. This leads me to suspect that perhaps it's a change in the vnode interface generating code in vnode_if.pl, possibly the difference between the sh version and the .pl version. vop_getacl is an unusual case in vfs_default.c. Most VOP's have explicit defaults defined in an array in vfs_default, mapping them to a particular error response. vop_getacl (and other VOP's like it) fall back on the default array's default (slot 0, vop_eopnotsupp). In -STABLE, this happens correctly, but in -CURRENT it appears to be broken, instead invoking slot 1, vop_panic() (which should never be called). I've CC'd Peter, because the commit logs seem to suggest that the building of vnode_if.[ch] are currently his baby. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services On Tue, 5 Sep 2000, Robert Watson wrote: > > On Tue, 5 Sep 2000, Charlie & wrote: > > > Hi Robert, > > > > I'm having kernel panics in the vop_getacl area. Any ideas? > > > > Joe > > > > vop_panic[vop_getacl] > > panic: Filesystem goof > > > (remainder of panic message below, for those curious) > > I'm a bit puzzled by this. On my 4.1-STABLE box, it appears to correctly > return EOPNOTSUPP in the simplist invocation: > > > cat > tmp.c > #include > #include > > int > main(int argc, char *argv[]) > { > acl_t acl; > int error; > > acl = acl_get_file("/bin/sh", ACL_TYPE_ACCESS); > if (error) > perror("acl_get_file"); > } > > > gcc -o tmp tmp.c -lposix1e > > ./tmp > acl_get_file: Operation not supported > > Which is the correct behavior, as none of the base file systems currently > defines ACL functionality. The same should occur for acl_check_file() and > acl_set_file(). I haven't tried this on 5.0-CURRENT recently, but > vop_panic() should only be invoked when there is an attempt to call slot 0 > of the VOP table for the file system. Slot 1, the default slot, should > return EOPNOTSUPP. > > It looks like you attempted to invoke acl_get_file() much as above. Are > you using any file system modules, and what file system was the target of > acl_get_file() in? Could it be the case that your modules are out of > sync with your kernel? (Not that I'd hope this was the result, but...) > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > syncing disks... 59 59 11 2 1 > > done > > Uptime: 6m50s > > > > dumping to dev ad0s2b, offset 630912 > > dump ata0: resetting devices .. done > > 191 failed, reason: aborted from console > > Automatic reboot in 15 seconds - press a key on the console to abort > > Rebooting... > > Copyright (c) 1992-2000 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.0-CURRENT #11: Tue Sep 5 12:45:45 BST 2000 > > joe@genius.systems.pavilion.net:/usr/obj/usr/src/sys/GENIUS > > Timecounter "i8254" frequency 1193182 Hz > > Timecounter "TSC" frequency 397896116 Hz > > CPU: Pentium II/Pentium II Xeon/Celeron (397.90-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0x66d Stepping = 13 > > Features=0x183f9ff > > real memory = 201261056 (196544K bytes) > > avail memory = 189722624 (185276K bytes) > > Preloaded elf kernel "kernel" at 0xc0573000. > > Pentium Pro MTRR support enabled > > npx0: on motherboard > > npx0: INT 16 interface > > pcib0: on motherboard > > pci0: on pcib0 > > isab0: at device 7.0 on pci0 > > isa0: on isab0 > > atapci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 > > ata0: at 0x1f0 irq 14 on atapci0 > > ata1: at 0x170 irq 15 on atapci0 > > pci0: at 7.2 irq 9 > > pci0: at 7.3 > > pci0: at 8.0 irq 9 > > pcm0: mem 0xfec00000-0xfecfffff,0xfe000000-0xfe3fffff irq 9 at device 8.1 on pci0 > > pci0: at 9.0 irq 9 > > pcic-pci0: at device 10.0 on pci0 > > pcic-pci1: at device 10.1 on pci0 > > acpi0: on motherboard > > acpi0: at 0xb2 irq 9 > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > atkbdc0: at port 0x60,0x64 on isa0 > > atkbd0: flags 0x1 irq 1 on atkbdc0 > > kbd0 at atkbd0 > > psm0: irq 12 on atkbdc0 > > psm0: model GlidePoint, device ID 0 > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > pcic0: at port 0x3e0 iomem 0xd0000 irq 10 on isa0 > > pcic0: management irq 10 > > pccard0: on pcic0 > > pccard1: on pcic0 > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > sio0: type 16550A > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > ppc0: at port 0x378-0x37f irq 7 on isa0 > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > ppc0: FIFO with 16/16/8 bytes threshold > > plip0: on ppbus0 > > lpt0: on ppbus0 > > lpt0: Interrupt-driven port > > ppi0: on ppbus0 > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > BRIDGE 990810, have 7 interfaces > > pccard: card inserted, slot 1 > > ata1-slave: ata_command: timeout waiting for intr > > ata1-slave: identify failed > > ad0: 19077MB [38760/16/63] at ata0-master using UDMA33 > > acd0: DVD-ROM at ata1-master using UDMA33 > > Mounting root from ufs:/dev/ad0s2a > > WARNING: / was not properly dismounted > > pid 115 (savecore), uid 0: exited on signal 10 (core dumped) > > xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 3 slot 1 on pccard1 > > xe0: Xircom CE3, bonding version 0x45, 100Mbps capable > > xe0: DingoID = 0, RevisionID = 0, VendorID = 0 > > xe0: Ethernet address 00:80:c7:f5:24:e0 > > BRIDGE 990810, have 8 interfaces > > -- index 8 type 6 phy 0 addrl 6 addr 00.80.c7.f5.24.e0 > > xe0: watchdog timeout; resetting card > > vop_panic[vop_getacl] > > panic: Filesystem goof > > panic: from debugger > > Uptime: 14m53s > > > > dumping to dev ad0s2b, offset 630912 > > dump ata0: resetting devices .. done > > 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > > --- > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > 461 dumppcb.pcb_cr3 = rcr3(); > > (kgdb) bt > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > #1 0xc017ce0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:302 > > #2 0xc017d1b1 in panic (fmt=0xc0265f94 "from debugger") > > at /usr/src/sys/kern/kern_shutdown.c:550 > > #3 0xc0131dbd in db_panic (addr=-1071373264, have_addr=0, count=-1, > > modif=0xcca77b9c "") at /usr/src/sys/ddb/db_command.c:433 > > #4 0xc0131d5d in db_command (last_cmdp=0xc02988f0, cmd_table=0xc0298750, > > aux_cmd_tablep=0xc02d8128) at /usr/src/sys/ddb/db_command.c:333 > > #5 0xc0131e22 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > > #6 0xc0133fdf in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 > > #7 0xc02421d2 in kdb_trap (type=3, code=0, regs=0xcca77ca4) > > at /usr/src/sys/i386/i386/db_interface.c:158 > > #8 0xc024dbb8 in trap (frame={tf_fs = -1072234480, tf_es = -900136944, > > tf_ds = -861470704, tf_edi = -861438236, tf_esi = 256, > > tf_ebp = -861438740, tf_isp = -861438768, tf_ebx = -1071170537, > > tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, > > tf_eip = -1071373264, tf_cs = 8, tf_eflags = 582, tf_esp = -1071067969, > > tf_ss = -1071186621}) at /usr/src/sys/i386/i386/trap.c:569 > > #9 0xc0242430 in Debugger (msg=0xc026fd43 "panic") at machine/cpufunc.h:64 > > #10 0xc017d1a8 in panic (fmt=0xc0273c17 "Filesystem goof") > > at /usr/src/sys/kern/kern_shutdown.c:548 > > #11 0xc01a9653 in vop_panic (ap=0xcca77d24) > > at /usr/src/sys/kern/vfs_default.c:142 > > #12 0xc016f377 in vacl_get_acl (p=0xcca69920, vp=0xcbb3da40, type=1, > > ---Type to continue, or q to quit--- > > aclp=0x81bd800) at vnode_if.h:1247 > > #13 0xc016f52c in __acl_get_file (p=0xcca69920, uap=0xcca77f80) > > at /usr/src/sys/kern/kern_acl.c:155 > > #14 0xc024e511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > > tf_edi = 1, tf_esi = 136042496, tf_ebp = -1077947632, > > tf_isp = -861437996, tf_ebx = 673380380, tf_edx = 0, tf_ecx = 0, > > tf_eax = 347, tf_trapno = 7, tf_err = 2, tf_eip = 673616088, tf_cs = 31, > > tf_eflags = 659, tf_esp = -1077947676, tf_ss = 47}) > > at /usr/src/sys/i386/i386/trap.c:1150 > > #15 0xc0242b15 in Xint0x80_syscall () > > #16 0x80af7c7 in ?? () > > #17 0x8077805 in ?? () > > #18 0x8064275 in ?? () > > #19 0x806d1f5 in ?? () > > #20 0x8069041 in ?? () > > #21 0x8067c63 in ?? () > > #22 0x809e8b3 in ?? () > > #23 0x809b0a5 in ?? () > > #24 0x8082cee in ?? () > > #25 0x804f345 in ?? () > > (kgdb) l\11   \11   #11 > > Function "" not defined. > > (kgdb) l   l /usr/src/sys/kern/vfs_degfaul     faui;lt    lt.c:142 > > 137 int > > 138 vop_panic(struct vop_generic_args *ap) > > 139 { > > 140 > > 141 printf("vop_panic[%s]\n", ap->a_desc->vdesc_name); > > 142 panic("Filesystem goof"); > > 143 return (0); > > 144 } > > 145 > > 146 /* > > (kgdb) quit > > # exit > > > > Script done on Tue Sep 5 15:12:48 2000 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 8:23:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0916037B42C; Tue, 5 Sep 2000 08:23:41 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA00743; Tue, 5 Sep 2000 11:23:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 5 Sep 2000 11:23:39 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: peter@FreeBSD.org, Charlie & Cc: freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, after even more code reading and debugging -- it appears that somewhere in {vnode.h,vnode_if.h->vnode_if.pl,vfs_init.c), the default operation is indeed being set to vop_panic() (0?) instead of vop_eopnotsupp() (1) as suggested in the vfs_defaults.c source. I'm a bit confused by the vnode_if.pl source code, but I suspect that somewhere, a set of 0's should be 1's. So if someone who understands this could take a look, it would be much appreciated. In the mean time, to reproduce on -CURRENT, simply make a call to acl_get_file(), pointing at a file in UFS. A simple program to do this is included in one of the quotes below. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services On Tue, 5 Sep 2000, Robert Watson wrote: > > Hmm. Sheldon Hearn also seems to be able to reproduce this on -CURRENT, > but the ACL code hasn't changed from -STABLE. This leads me to suspect > that perhaps it's a change in the vnode interface generating code in > vnode_if.pl, possibly the difference between the sh version and the .pl > version. > > vop_getacl is an unusual case in vfs_default.c. Most VOP's have explicit > defaults defined in an array in vfs_default, mapping them to a particular > error response. vop_getacl (and other VOP's like it) fall back on the > default array's default (slot 0, vop_eopnotsupp). In -STABLE, this > happens correctly, but in -CURRENT it appears to be broken, instead > invoking slot 1, vop_panic() (which should never be called). > > I've CC'd Peter, because the commit logs seem to suggest that the building > of vnode_if.[ch] are currently his baby. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > On Tue, 5 Sep 2000, Robert Watson wrote: > > > > > On Tue, 5 Sep 2000, Charlie & wrote: > > > > > Hi Robert, > > > > > > I'm having kernel panics in the vop_getacl area. Any ideas? > > > > > > Joe > > > > > > vop_panic[vop_getacl] > > > panic: Filesystem goof > > > > > (remainder of panic message below, for those curious) > > > > I'm a bit puzzled by this. On my 4.1-STABLE box, it appears to correctly > > return EOPNOTSUPP in the simplist invocation: > > > > > cat > tmp.c > > #include > > #include > > > > int > > main(int argc, char *argv[]) > > { > > acl_t acl; > > int error; > > > > acl = acl_get_file("/bin/sh", ACL_TYPE_ACCESS); > > if (error) > > perror("acl_get_file"); > > } > > > > > gcc -o tmp tmp.c -lposix1e > > > ./tmp > > acl_get_file: Operation not supported > > > > Which is the correct behavior, as none of the base file systems currently > > defines ACL functionality. The same should occur for acl_check_file() and > > acl_set_file(). I haven't tried this on 5.0-CURRENT recently, but > > vop_panic() should only be invoked when there is an attempt to call slot 0 > > of the VOP table for the file system. Slot 1, the default slot, should > > return EOPNOTSUPP. > > > > It looks like you attempted to invoke acl_get_file() much as above. Are > > you using any file system modules, and what file system was the target of > > acl_get_file() in? Could it be the case that your modules are out of > > sync with your kernel? (Not that I'd hope this was the result, but...) > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > > syncing disks... 59 59 11 2 1 > > > done > > > Uptime: 6m50s > > > > > > dumping to dev ad0s2b, offset 630912 > > > dump ata0: resetting devices .. done > > > 191 failed, reason: aborted from console > > > Automatic reboot in 15 seconds - press a key on the console to abort > > > Rebooting... > > > Copyright (c) 1992-2000 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD 5.0-CURRENT #11: Tue Sep 5 12:45:45 BST 2000 > > > joe@genius.systems.pavilion.net:/usr/obj/usr/src/sys/GENIUS > > > Timecounter "i8254" frequency 1193182 Hz > > > Timecounter "TSC" frequency 397896116 Hz > > > CPU: Pentium II/Pentium II Xeon/Celeron (397.90-MHz 686-class CPU) > > > Origin = "GenuineIntel" Id = 0x66d Stepping = 13 > > > Features=0x183f9ff > > > real memory = 201261056 (196544K bytes) > > > avail memory = 189722624 (185276K bytes) > > > Preloaded elf kernel "kernel" at 0xc0573000. > > > Pentium Pro MTRR support enabled > > > npx0: on motherboard > > > npx0: INT 16 interface > > > pcib0: on motherboard > > > pci0: on pcib0 > > > isab0: at device 7.0 on pci0 > > > isa0: on isab0 > > > atapci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 > > > ata0: at 0x1f0 irq 14 on atapci0 > > > ata1: at 0x170 irq 15 on atapci0 > > > pci0: at 7.2 irq 9 > > > pci0: at 7.3 > > > pci0: at 8.0 irq 9 > > > pcm0: mem 0xfec00000-0xfecfffff,0xfe000000-0xfe3fffff irq 9 at device 8.1 on pci0 > > > pci0: at 9.0 irq 9 > > > pcic-pci0: at device 10.0 on pci0 > > > pcic-pci1: at device 10.1 on pci0 > > > acpi0: on motherboard > > > acpi0: at 0xb2 irq 9 > > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > > > fdc0: FIFO enabled, 8 bytes threshold > > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > > atkbdc0: at port 0x60,0x64 on isa0 > > > atkbd0: flags 0x1 irq 1 on atkbdc0 > > > kbd0 at atkbd0 > > > psm0: irq 12 on atkbdc0 > > > psm0: model GlidePoint, device ID 0 > > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > > sc0: at flags 0x100 on isa0 > > > sc0: VGA <16 virtual consoles, flags=0x300> > > > pcic0: at port 0x3e0 iomem 0xd0000 irq 10 on isa0 > > > pcic0: management irq 10 > > > pccard0: on pcic0 > > > pccard1: on pcic0 > > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > > sio0: type 16550A > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > ppc0: at port 0x378-0x37f irq 7 on isa0 > > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > > ppc0: FIFO with 16/16/8 bytes threshold > > > plip0: on ppbus0 > > > lpt0: on ppbus0 > > > lpt0: Interrupt-driven port > > > ppi0: on ppbus0 > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > BRIDGE 990810, have 7 interfaces > > > pccard: card inserted, slot 1 > > > ata1-slave: ata_command: timeout waiting for intr > > > ata1-slave: identify failed > > > ad0: 19077MB [38760/16/63] at ata0-master using UDMA33 > > > acd0: DVD-ROM at ata1-master using UDMA33 > > > Mounting root from ufs:/dev/ad0s2a > > > WARNING: / was not properly dismounted > > > pid 115 (savecore), uid 0: exited on signal 10 (core dumped) > > > xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 3 slot 1 on pccard1 > > > xe0: Xircom CE3, bonding version 0x45, 100Mbps capable > > > xe0: DingoID = 0, RevisionID = 0, VendorID = 0 > > > xe0: Ethernet address 00:80:c7:f5:24:e0 > > > BRIDGE 990810, have 8 interfaces > > > -- index 8 type 6 phy 0 addrl 6 addr 00.80.c7.f5.24.e0 > > > xe0: watchdog timeout; resetting card > > > vop_panic[vop_getacl] > > > panic: Filesystem goof > > > panic: from debugger > > > Uptime: 14m53s > > > > > > dumping to dev ad0s2b, offset 630912 > > > dump ata0: resetting devices .. done > > > 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > > > --- > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > > 461 dumppcb.pcb_cr3 = rcr3(); > > > (kgdb) bt > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > > #1 0xc017ce0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:302 > > > #2 0xc017d1b1 in panic (fmt=0xc0265f94 "from debugger") > > > at /usr/src/sys/kern/kern_shutdown.c:550 > > > #3 0xc0131dbd in db_panic (addr=-1071373264, have_addr=0, count=-1, > > > modif=0xcca77b9c "") at /usr/src/sys/ddb/db_command.c:433 > > > #4 0xc0131d5d in db_command (last_cmdp=0xc02988f0, cmd_table=0xc0298750, > > > aux_cmd_tablep=0xc02d8128) at /usr/src/sys/ddb/db_command.c:333 > > > #5 0xc0131e22 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 > > > #6 0xc0133fdf in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71 > > > #7 0xc02421d2 in kdb_trap (type=3, code=0, regs=0xcca77ca4) > > > at /usr/src/sys/i386/i386/db_interface.c:158 > > > #8 0xc024dbb8 in trap (frame={tf_fs = -1072234480, tf_es = -900136944, > > > tf_ds = -861470704, tf_edi = -861438236, tf_esi = 256, > > > tf_ebp = -861438740, tf_isp = -861438768, tf_ebx = -1071170537, > > > tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, > > > tf_eip = -1071373264, tf_cs = 8, tf_eflags = 582, tf_esp = -1071067969, > > > tf_ss = -1071186621}) at /usr/src/sys/i386/i386/trap.c:569 > > > #9 0xc0242430 in Debugger (msg=0xc026fd43 "panic") at machine/cpufunc.h:64 > > > #10 0xc017d1a8 in panic (fmt=0xc0273c17 "Filesystem goof") > > > at /usr/src/sys/kern/kern_shutdown.c:548 > > > #11 0xc01a9653 in vop_panic (ap=0xcca77d24) > > > at /usr/src/sys/kern/vfs_default.c:142 > > > #12 0xc016f377 in vacl_get_acl (p=0xcca69920, vp=0xcbb3da40, type=1, > > > ---Type to continue, or q to quit--- > > > aclp=0x81bd800) at vnode_if.h:1247 > > > #13 0xc016f52c in __acl_get_file (p=0xcca69920, uap=0xcca77f80) > > > at /usr/src/sys/kern/kern_acl.c:155 > > > #14 0xc024e511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > > > tf_edi = 1, tf_esi = 136042496, tf_ebp = -1077947632, > > > tf_isp = -861437996, tf_ebx = 673380380, tf_edx = 0, tf_ecx = 0, > > > tf_eax = 347, tf_trapno = 7, tf_err = 2, tf_eip = 673616088, tf_cs = 31, > > > tf_eflags = 659, tf_esp = -1077947676, tf_ss = 47}) > > > at /usr/src/sys/i386/i386/trap.c:1150 > > > #15 0xc0242b15 in Xint0x80_syscall () > > > #16 0x80af7c7 in ?? () > > > #17 0x8077805 in ?? () > > > #18 0x8064275 in ?? () > > > #19 0x806d1f5 in ?? () > > > #20 0x8069041 in ?? () > > > #21 0x8067c63 in ?? () > > > #22 0x809e8b3 in ?? () > > > #23 0x809b0a5 in ?? () > > > #24 0x8082cee in ?? () > > > #25 0x804f345 in ?? () > > > (kgdb) l\11   \11   #11 > > > Function "" not defined. > > > (kgdb) l   l /usr/src/sys/kern/vfs_degfaul     faui;lt    lt.c:142 > > > 137 int > > > 138 vop_panic(struct vop_generic_args *ap) > > > 139 { > > > 140 > > > 141 printf("vop_panic[%s]\n", ap->a_desc->vdesc_name); > > > 142 panic("Filesystem goof"); > > > 143 return (0); > > > 144 } > > > 145 > > > 146 /* > > > (kgdb) quit > > > # exit > > > > > > Script done on Tue Sep 5 15:12:48 2000 > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-fs" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 12:42:49 2000 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (backplane-inc.SanFranciscosfd.cw.net [206.24.214.242]) by hub.freebsd.org (Postfix) with ESMTP id 045FB37B422; Tue, 5 Sep 2000 12:42:47 -0700 (PDT) Received: (from dillon@localhost) by earth.backplane.com (8.9.3/8.9.3) id MAA76219; Tue, 5 Sep 2000 12:42:19 -0700 (PDT) (envelope-from dillon) Date: Tue, 5 Sep 2000 12:42:19 -0700 (PDT) From: Matt Dillon Message-Id: <200009051942.MAA76219@earth.backplane.com> To: Boris Popov Cc: "Daniel C. Sobral" , freebsd-fs@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) References: Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I agree with all of Boris's points in regards to the two major changes: Adding VOP's to access the VM object, and integrating the vnode lock into the vnode directly. There is one issue which needs to be resolved, and that is with NFS. It is not safe to lock vnodes related to NFS, which is why the NFS VOP locking routines always force shared locks. This problem would have to be resolved. About a year ago I attempted to make NullFs work with mmap(). I did it by overloading one VM object on top of another... essentially creating two vnode-backed VM objects. I was never able to get this to work properly because a huge amount of kernel code assumes that a VM object of type OBJT_VNODE is always a leaf. Boris's way of doing the stacking should be much more stable and considerably easier to maintain. Boris's patches look good, though I didn't go over them with a fine-toothed comb. I'm amazed at how clean the nullfs changes are with the new infrastructure there to support it. This patch involves architectural changes so I think either DG or Kirk have to sign off on it (maybe more Kirk then DG for this since it is filesystem related). I think Kirk will agree with it assuming the NFS issue can be dealt with. -Matt :On Tue, 5 Sep 2000, Daniel C. Sobral wrote: : :> > The simple solution for it is to integrate lock structure into :> > vnode and making vnode.v_vnlock initially point to it. Any filesystem :> > above can pickup the pointer and assign it to v_vnlock field in its own :> > vnode structure. If underlying filesystem doesn't provide any lock :> > structure then bad times are coming and each layer can maintain its own :> > lock state. :> :> How can it handle fs multiplexing? Ie, a single underlying layer with :> multiple non-stacked layers above? : : Just like in the stacking case: access to vnode on the underlying :filesystem should be serialized which is done by proper(shared) locking. : :-- :Boris Popov :http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 15: 1: 7 2000 Delivered-To: freebsd-fs@freebsd.org Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186]) by hub.freebsd.org (Postfix) with ESMTP id 273DC37B422; Tue, 5 Sep 2000 15:00:57 -0700 (PDT) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.11.0/8.9.3) with ESMTP id e85M0pG47083; Tue, 5 Sep 2000 15:00:51 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200009052200.e85M0pG47083@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Robert Watson Cc: Charlie & , freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). In-Reply-To: Date: Tue, 05 Sep 2000 15:00:51 -0700 From: Peter Wemm Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Basically a VOP_xxx() only exists somewhere when a filesystem instantiates it somewhere in its vnode op table. A vop vector is initialized by implementing it in a filesystem somewhere. ffs_vnops has: #ifdef FFS_EXTATTR { &vop_getextattr_desc, (vop_t *) ufs_vop_getextattr }, { &vop_setextattr_desc, (vop_t *) ufs_vop_setextattr }, #endif As far as vnode_if is concerned, it looks like somebody is calling a VOP that doesn't exist or is corrupt - it has never been instantiated anywhere. Perhaps the vop_panic sanity checking stuff is overly agressive and should only be activated if there is no vop_default for a filesystem layer. (I estimate the Terry activation probability at around 99.97% in this thread) Robert Watson wrote: > > So, after even more code reading and debugging -- it appears that > somewhere in {vnode.h,vnode_if.h->vnode_if.pl,vfs_init.c), the default > operation is indeed being set to vop_panic() (0?) instead of > vop_eopnotsupp() (1) as suggested in the vfs_defaults.c source. I'm a bit > confused by the vnode_if.pl source code, but I suspect that somewhere, a > set of 0's should be 1's. > > So if someone who understands this could take a look, it would be much > appreciated. In the mean time, to reproduce on -CURRENT, simply make a > call to acl_get_file(), pointing at a file in UFS. A simple program to do > this is included in one of the quotes below. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > On Tue, 5 Sep 2000, Robert Watson wrote: > > > > > Hmm. Sheldon Hearn also seems to be able to reproduce this on -CURRENT, > > but the ACL code hasn't changed from -STABLE. This leads me to suspect > > that perhaps it's a change in the vnode interface generating code in > > vnode_if.pl, possibly the difference between the sh version and the .pl > > version. > > > > vop_getacl is an unusual case in vfs_default.c. Most VOP's have explicit > > defaults defined in an array in vfs_default, mapping them to a particular > > error response. vop_getacl (and other VOP's like it) fall back on the > > default array's default (slot 0, vop_eopnotsupp). In -STABLE, this > > happens correctly, but in -CURRENT it appears to be broken, instead > > invoking slot 1, vop_panic() (which should never be called). > > > > I've CC'd Peter, because the commit logs seem to suggest that the building > > of vnode_if.[ch] are currently his baby. > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > On Tue, 5 Sep 2000, Robert Watson wrote: > > > > > > > > On Tue, 5 Sep 2000, Charlie & wrote: > > > > > > > Hi Robert, > > > > > > > > I'm having kernel panics in the vop_getacl area. Any ideas? > > > > > > > > Joe > > > > > > > > vop_panic[vop_getacl] > > > > panic: Filesystem goof > > > > > > > (remainder of panic message below, for those curious) > > > > > > I'm a bit puzzled by this. On my 4.1-STABLE box, it appears to correctly > > > return EOPNOTSUPP in the simplist invocation: > > > > > > > cat > tmp.c > > > #include > > > #include > > > > > > int > > > main(int argc, char *argv[]) > > > { > > > acl_t acl; > > > int error; > > > > > > acl = acl_get_file("/bin/sh", ACL_TYPE_ACCESS); > > > if (error) > > > perror("acl_get_file"); > > > } > > > > > > > gcc -o tmp tmp.c -lposix1e > > > > ./tmp > > > acl_get_file: Operation not supported > > > > > > Which is the correct behavior, as none of the base file systems currently > > > defines ACL functionality. The same should occur for acl_check_file() an d > > > acl_set_file(). I haven't tried this on 5.0-CURRENT recently, but > > > vop_panic() should only be invoked when there is an attempt to call slot 0 > > > of the VOP table for the file system. Slot 1, the default slot, should > > > return EOPNOTSUPP. > > > > > > It looks like you attempted to invoke acl_get_file() much as above. Are > > > you using any file system modules, and what file system was the target of > > > acl_get_file() in? Could it be the case that your modules are out of > > > sync with your kernel? (Not that I'd hope this was the result, but...) > > > > > > Robert N M Watson > > > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > > TIS Labs at Network Associates, Safeport Network Services > > > > > > > syncing disks... 59 59 11 2 1 > > > > done > > > > Uptime: 6m50s > > > > > > > > dumping to dev ad0s2b, offset 630912 > > > > dump ata0: resetting devices .. done > > > > 191 failed, reason: aborted from console > > > > Automatic reboot in 15 seconds - press a key on the console to abort > > > > Rebooting... > > > > Copyright (c) 1992-2000 The FreeBSD Project. > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199 4 > > > > The Regents of the University of California. All rights reserve d. > > > > FreeBSD 5.0-CURRENT #11: Tue Sep 5 12:45:45 BST 2000 > > > > joe@genius.systems.pavilion.net:/usr/obj/usr/src/sys/GENIUS > > > > Timecounter "i8254" frequency 1193182 Hz > > > > Timecounter "TSC" frequency 397896116 Hz > > > > CPU: Pentium II/Pentium II Xeon/Celeron (397.90-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x66d Stepping = 13 > > > > Features=0x183f9ff > > > > real memory = 201261056 (196544K bytes) > > > > avail memory = 189722624 (185276K bytes) > > > > Preloaded elf kernel "kernel" at 0xc0573000. > > > > Pentium Pro MTRR support enabled > > > > npx0: on motherboard > > > > npx0: INT 16 interface > > > > pcib0: on motherboard > > > > pci0: on pcib0 > > > > isab0: at device 7.0 on pci0 > > > > isa0: on isab0 > > > > atapci0: port 0xfcd0-0xfcdf at device 7. 1 on pci0 > > > > ata0: at 0x1f0 irq 14 on atapci0 > > > > ata1: at 0x170 irq 15 on atapci0 > > > > pci0: at 7.2 irq 9 > > > > pci0: at 7.3 > > > > pci0: at 8.0 irq 9 > > > > pcm0: mem 0xfec00000-0xfecfffff,0xfe000000-0xfe3fffff irq 9 at device 8.1 on pci0 > > > > pci0: at 9.0 irq 9 > > > > pcic-pci0: at device 10.0 on pci0 > > > > pcic-pci1: at device 10.1 on pci0 > > > > acpi0: on motherboard > > > > acpi0: at 0xb2 irq 9 > > > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on is a0 > > > > fdc0: FIFO enabled, 8 bytes threshold > > > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > > > atkbdc0: at port 0x60,0x64 on isa0 > > > > atkbd0: flags 0x1 irq 1 on atkbdc0 > > > > kbd0 at atkbd0 > > > > psm0: irq 12 on atkbdc0 > > > > psm0: model GlidePoint, device ID 0 > > > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is a0 > > > > sc0: at flags 0x100 on isa0 > > > > sc0: VGA <16 virtual consoles, flags=0x300> > > > > pcic0: at port 0x3e0 iomem 0xd0000 irq 10 on isa0 > > > > pcic0: management irq 10 > > > > pccard0: on pcic0 > > > > pccard1: on pcic0 > > > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > > > sio0: type 16550A > > > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > > > ppc0: at port 0x378-0x37f irq 7 on isa0 > > > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > > > ppc0: FIFO with 16/16/8 bytes threshold > > > > plip0: on ppbus0 > > > > lpt0: on ppbus0 > > > > lpt0: Interrupt-driven port > > > > ppi0: on ppbus0 > > > > unknown: can't assign resources > > > > unknown: can't assign resources > > > > unknown: can't assign resources > > > > unknown: can't assign resources > > > > unknown: can't assign resources > > > > BRIDGE 990810, have 7 interfaces > > > > pccard: card inserted, slot 1 > > > > ata1-slave: ata_command: timeout waiting for intr > > > > ata1-slave: identify failed > > > > ad0: 19077MB [38760/16/63] at ata0-master using UDMA33 > > > > acd0: DVD-ROM at ata1-master using UDMA33 > > > > Mounting root from ufs:/dev/ad0s2a > > > > WARNING: / was not properly dismounted > > > > pid 115 (savecore), uid 0: exited on signal 10 (core dumped) > > > > xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 3 slot 1 on pccard1 > > > > xe0: Xircom CE3, bonding version 0x45, 100Mbps capable > > > > xe0: DingoID = 0, RevisionID = 0, VendorID = 0 > > > > xe0: Ethernet address 00:80:c7:f5:24:e0 > > > > BRIDGE 990810, have 8 interfaces > > > > -- index 8 type 6 phy 0 addrl 6 addr 00.80.c7.f5.24.e0 > > > > xe0: watchdog timeout; resetting card > > > > vop_panic[vop_getacl] > > > > panic: Filesystem goof > > > > panic: from debugger > > > > Uptime: 14m53s > > > > > > > > dumping to dev ad0s2b, offset 630912 > > > > dump ata0: resetting devices .. done > > > > 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 15 5 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 1 36 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > > > > --- > > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > > > 461 dumppcb.pcb_cr3 = rcr3(); > > > > (kgdb) bt > > > > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:461 > > > > #1 0xc017ce0f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c :302 > > > > #2 0xc017d1b1 in panic (fmt=0xc0265f94 "from debugger") > > > > at /usr/src/sys/kern/kern_shutdown.c:550 > > > > #3 0xc0131dbd in db_panic (addr=-1071373264, have_addr=0, count=-1, > > > > modif=0xcca77b9c "") at /usr/src/sys/ddb/db_command.c:433 > > > > #4 0xc0131d5d in db_command (last_cmdp=0xc02988f0, cmd_table=0xc029875 0, > > > > aux_cmd_tablep=0xc02d8128) at /usr/src/sys/ddb/db_command.c:333 > > > > #5 0xc0131e22 in db_command_loop () at /usr/src/sys/ddb/db_command.c:4 55 > > > > #6 0xc0133fdf in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap. c:71 > > > > #7 0xc02421d2 in kdb_trap (type=3, code=0, regs=0xcca77ca4) > > > > at /usr/src/sys/i386/i386/db_interface.c:158 > > > > #8 0xc024dbb8 in trap (frame={tf_fs = -1072234480, tf_es = -900136944, > > > > tf_ds = -861470704, tf_edi = -861438236, tf_esi = 256, > > > > tf_ebp = -861438740, tf_isp = -861438768, tf_ebx = -1071170537, > > > > tf_edx = 0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, > > > > tf_eip = -1071373264, tf_cs = 8, tf_eflags = 582, tf_esp = -10710 67969, > > > > tf_ss = -1071186621}) at /usr/src/sys/i386/i386/trap.c:569 > > > > #9 0xc0242430 in Debugger (msg=0xc026fd43 "panic") at machine/cpufunc. h:64 > > > > #10 0xc017d1a8 in panic (fmt=0xc0273c17 "Filesystem goof") > > > > at /usr/src/sys/kern/kern_shutdown.c:548 > > > > #11 0xc01a9653 in vop_panic (ap=0xcca77d24) > > > > at /usr/src/sys/kern/vfs_default.c:142 > > > > #12 0xc016f377 in vacl_get_acl (p=0xcca69920, vp=0xcbb3da40, type=1, > > > > ---Type to continue, or q to quit--- > > > > aclp=0x81bd800) at vnode_if.h:1247 > > > > #13 0xc016f52c in __acl_get_file (p=0xcca69920, uap=0xcca77f80) > > > > at /usr/src/sys/kern/kern_acl.c:155 > > > > #14 0xc024e511 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, > > > > tf_edi = 1, tf_esi = 136042496, tf_ebp = -1077947632, > > > > tf_isp = -861437996, tf_ebx = 673380380, tf_edx = 0, tf_ecx = 0, > > > > tf_eax = 347, tf_trapno = 7, tf_err = 2, tf_eip = 673616088, tf_c s = 31, > > > > tf_eflags = 659, tf_esp = -1077947676, tf_ss = 47}) > > > > at /usr/src/sys/i386/i386/trap.c:1150 > > > > #15 0xc0242b15 in Xint0x80_syscall () > > > > #16 0x80af7c7 in ?? () > > > > #17 0x8077805 in ?? () > > > > #18 0x8064275 in ?? () > > > > #19 0x806d1f5 in ?? () > > > > #20 0x8069041 in ?? () > > > > #21 0x8067c63 in ?? () > > > > #22 0x809e8b3 in ?? () > > > > #23 0x809b0a5 in ?? () > > > > #24 0x8082cee in ?? () > > > > #25 0x804f345 in ?? () > > > > (kgdb) l\11   \11   #11 > > > > Function "" not defined. > > > > (kgdb) l   l /usr/src/sys/kern/vfs_degfaul     faui;lt    lt.c:142 > > > > 137 int > > > > 138 vop_panic(struct vop_generic_args *ap) > > > > 139 { > > > > 140 > > > > 141 printf("vop_panic[%s]\n", ap->a_desc->vdesc_name); > > > > 142 panic("Filesystem goof"); > > > > 143 return (0); > > > > 144 } > > > > 145 > > > > 146 /* > > > > (kgdb) quit > > > > # exit > > > > > > > > Script done on Tue Sep 5 15:12:48 2000 > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-fs" in the body of the message > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-fs" in the body of the message > > > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 19:53: 1 2000 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id B286237B422; Tue, 5 Sep 2000 19:52:56 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id B9FD828C77; Wed, 6 Sep 2000 09:52:51 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id A497928AAD; Wed, 6 Sep 2000 09:52:51 +0700 (ALMST) Date: Wed, 6 Sep 2000 09:52:51 +0700 (ALMST) From: Boris Popov To: Matt Dillon Cc: "Daniel C. Sobral" , freebsd-fs@FreeBSD.ORG, semenu@FreeBSD.ORG, tegge@FreeBSD.ORG Subject: Re: CFR: nullfs, vm_objects and locks... (patch) In-Reply-To: <200009051942.MAA76219@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Sep 2000, Matt Dillon wrote: > I agree with all of Boris's points in regards to the two major changes: > Adding VOP's to access the VM object, and integrating the vnode lock > into the vnode directly. > > There is one issue which needs to be resolved, and that is with NFS. It > is not safe to lock vnodes related to NFS, which is why the NFS VOP locking > routines always force shared locks. This problem would have to be > resolved. I think that vop_sharedlock() is compatible with proposed changes and only nfs_lookup() needs to be tweaked in order to maintain PDIRUNLOCK flag. Nevertheless, I'll test nfs case this weekend. > Boris's patches look good, though I didn't go over them with a fine-toothed > comb. I'm amazed at how clean the nullfs changes are with the new > infrastructure there to support it. I'm would very appreciate if someone who familiar with BIO/VM layer review all VOP_GETVOBJECT() invocations in the vfs_bio/vm_mmap code. > This patch involves architectural changes so I think either DG or Kirk > have to sign off on it (maybe more Kirk then DG for this since it is > filesystem related). I think Kirk will agree with it assuming the NFS > issue can be dealt with. Ok, I'll forward them a copy of original message. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Sep 5 20: 1: 4 2000 Delivered-To: freebsd-fs@freebsd.org Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 984B237B43E for ; Tue, 5 Sep 2000 20:01:01 -0700 (PDT) Received: from chimp (chimp [192.168.0.2]) by cage.simianscience.com (8.11.0/8.9.3) with ESMTP id e8630vV30763; Tue, 5 Sep 2000 23:00:57 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <4.2.2.20000905224117.032376f8@mail.sentex.net> X-Sender: mdtancsa@mail.sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Sep 2000 22:55:47 -0400 To: freebsd-fs@freebsd.org From: Mike Tancsa Subject: optimal directory creation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I really dont know much about UFS, but from the little I understand, issues such as amount of files in a directory affect performance and from what someone told me, the order of directory creation. To make a new pop3 server a little more efficient, I implemented a 2 level hashed tree. But, what I am not sure of is if the initial creation of the directories are important. e.g. should I create (assuming for this case, usernames are only [a-z][a-z]*. Should I create the directories in the order 1) /var/mail/a /var/mail/a/a /var/mail/a/b . . . /var/mail/z/z or 2) /var/mail/a /var/mail/b . . /var/mail/z then /var/mail/a/b /var/mail/a/c . . /var/mail/z/z 3) create /var/mail/s /var/mail/s/o /var/mail/t /var/mail/t/a . . . /var/mail/j/z assuming that I had the most popular usernames starting with so, then ta with the least popular jz ? Thoughts/comments ? I was going to try some simple benchmarks to see if there were any obvious differences, but the theory behind it would be great to know. Thanks, ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Network Administration, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 6 3:10:11 2000 Delivered-To: freebsd-fs@freebsd.org Received: from genius.systems.pavilion.net (genius.systems.pavilion.net [212.74.1.100]) by hub.freebsd.org (Postfix) with ESMTP id 4DDD437B42C; Wed, 6 Sep 2000 03:10:07 -0700 (PDT) Received: by genius.systems.pavilion.net (Postfix, from userid 100) id 75BAD9B40; Wed, 6 Sep 2000 11:10:06 +0100 (BST) Date: Wed, 6 Sep 2000 11:10:06 +0100 From: Josef Karthauser To: Robert Watson Cc: Charlie & , freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). Message-ID: <20000906111006.C1081@pavilion.net> References: <20000905151543.A151@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.org on Tue, Sep 05, 2000 at 09:52:58AM -0400 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, Lees House, 21-23 Dyke Road, Brighton, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 05, 2000 at 09:52:58AM -0400, Robert Watson wrote: > > It looks like you attempted to invoke acl_get_file() much as above. Are > you using any file system modules, and what file system was the target of > acl_get_file() in? Could it be the case that your modules are out of > sync with your kernel? (Not that I'd hope this was the result, but...) > I've located why I've started getting the problem. It co-incided with the install of the vim-6.0h port; I've gone back to vim-5.7, and that's cured (avoided) the problem. Looking at the source vim-6.0 does indeed do an acl_X when saving: acl = acl_get_file("foo", ACL_TYPE_DEFAULT); Joe > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Sep 6 5:15:42 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 80E2937B43E; Wed, 6 Sep 2000 05:15:37 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA14142; Wed, 6 Sep 2000 08:15:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 6 Sep 2000 08:15:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: peter@FreeBSD.org Cc: Charlie & , Josef Karthauser , freebsd-fs@FreeBSD.org Subject: Re: Kernel panics (filesystem goof). In-Reply-To: <20000906111006.C1081@pavilion.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter, This looks like a good rationale for supporting vnops that aren't provided by any file system. It seems to make sense to me, what with pluggable file systems (you might only have cd9660 in some environemtns, for example) that vnops without implementations should get correctly passed to vop_eopnotsupp() and ot vop_panic(). Could you go ahead and make that change? Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services On Wed, 6 Sep 2000, Josef Karthauser wrote: > On Tue, Sep 05, 2000 at 09:52:58AM -0400, Robert Watson wrote: > > > > It looks like you attempted to invoke acl_get_file() much as above. Are > > you using any file system modules, and what file system was the target of > > acl_get_file() in? Could it be the case that your modules are out of > > sync with your kernel? (Not that I'd hope this was the result, but...) > > > > I've located why I've started getting the problem. It co-incided with > the install of the vim-6.0h port; I've gone back to vim-5.7, and that's > cured (avoided) the problem. Looking at the source vim-6.0 does indeed > do an acl_X when saving: > > acl = acl_get_file("foo", ACL_TYPE_DEFAULT); > > Joe > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > -- > Josef Karthauser FreeBSD: How many times have you booted today? > Technical Manager Viagra for your server (http://www.uk.freebsd.org) > Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 7 18: 3: 7 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id 4D7C137B424 for ; Thu, 7 Sep 2000 18:03:05 -0700 (PDT) Received: from localhost (stein@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) with ESMTP id e88134x04024 for ; Thu, 7 Sep 2000 21:03:04 -0400 (EDT) Date: Thu, 7 Sep 2000 21:03:04 -0400 (EDT) From: Christopher Stein X-Sender: stein@wally To: freebsd-fs@freebsd.org Subject: splbio() in buf_daemon() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am checking out the bufdaemon code in kern/vfs_bio.c One of the first thing the bufdaemon does is splbio() then promptly enters into a for (;;) loop, potentially waiting in kproc_suspend_loop(). Where does it lower the cpu interrupt level so block I/O interrupts will be received and the system can function?? thnx -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Sep 7 18:11:14 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 506AC37B422 for ; Thu, 7 Sep 2000 18:11:10 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e881Awf20601; Fri, 8 Sep 2000 10:40:58 +0930 (CST) (envelope-from grog) Date: Fri, 8 Sep 2000 10:40:58 +0930 From: Greg Lehey To: Christopher Stein Cc: freebsd-fs@FreeBSD.ORG Subject: Re: splbio() in buf_daemon() Message-ID: <20000908104058.M83632@wantadilla.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from stein@eecs.harvard.edu on Thu, Sep 07, 2000 at 09:03:04PM -0400 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 7 September 2000 at 21:03:04 -0400, Christopher Stein wrote: > > Hello, > > I am checking out the bufdaemon code in kern/vfs_bio.c > One of the first thing the bufdaemon does is splbio() > then promptly enters into a for (;;) loop, potentially > waiting in kproc_suspend_loop(). Where does it lower > the cpu interrupt level so block I/O interrupts will be > received and the system can function?? In kproc_suspend_loop: void kproc_suspend_loop(struct proc *p) { while (SIGISMEMBER(p->p_siglist, SIGSTOP)) { wakeup((caddr_t)&p->p_siglist); tsleep((caddr_t)&p->p_siglist, PPAUSE, "kpsusp", 0); } } tsleep() saves and releases the spl(). wakeup() then sets it again. Note that this has already gone away in SMPng; spl calls are now dummies. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 8 8:17:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from wally.eecs.harvard.edu (wally.eecs.harvard.edu [140.247.60.30]) by hub.freebsd.org (Postfix) with ESMTP id 6C18A37B43F for ; Fri, 8 Sep 2000 08:17:41 -0700 (PDT) Received: from localhost (stein@localhost) by wally.eecs.harvard.edu (8.10.0/8.10.0) with ESMTP id e88FHdW19478 for ; Fri, 8 Sep 2000 11:17:40 -0400 (EDT) Date: Fri, 8 Sep 2000 11:17:39 -0400 (EDT) From: Christopher Stein X-Sender: stein@wally To: freebsd-fs@freebsd.org Subject: how mmap buffer writes handled? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Suppose a file is mmapped and the application writes into a previously clean buffer. This will not pass through the syscall interface and the OS has no way of triggering bdirty() and moving the buffer onto the dirty queue. The only way the OS has of knowing if the buf is dirty is by examining the page table hardware bits. How are buffers dirtied by mmap moved onto the dirty queue? IS this done synchronously by some kind of software intercept of the page table operations or are the buffers moved from the clean to dirty queues in the background? thnx, -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 8 23: 9: 2 2000 Delivered-To: freebsd-fs@freebsd.org Received: from mail-relay.eunet.no (mail-relay.eunet.no [193.71.71.242]) by hub.freebsd.org (Postfix) with ESMTP id 575E937B50F for ; Fri, 8 Sep 2000 23:08:59 -0700 (PDT) Received: from login-1.eunet.no (login-1.eunet.no [193.75.110.2]) by mail-relay.eunet.no (8.9.3/8.9.3/GN) with ESMTP id IAA30097; Sat, 9 Sep 2000 08:06:17 +0200 (CEST) (envelope-from mbendiks@eunet.no) Received: from localhost (mbendiks@localhost) by login-1.eunet.no (8.9.3/8.8.8) with ESMTP id IAA63401; Sat, 9 Sep 2000 08:06:17 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Sat, 9 Sep 2000 08:06:17 +0200 (CEST) From: Marius Bendiksen To: Christopher Stein Cc: freebsd-fs@FreeBSD.ORG Subject: Re: how mmap buffer writes handled? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > dirtied by mmap moved onto the dirty queue? IS this done > synchronously by some kind of software intercept of the > page table operations or are the buffers moved from the > clean to dirty queues in the background? As I recall, a periodic scan of the "modified" bits of the various page table entries will be made, and the buffers will be dirtied accordingly as the scan completes. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Sep 8 23:53: 4 2000 Delivered-To: freebsd-fs@freebsd.org Received: from aplcenMP.apl.jhu.edu (apl.jhu.edu [128.220.101.100]) by hub.freebsd.org (Postfix) with ESMTP id 6109D37B506 for ; Fri, 8 Sep 2000 23:53:03 -0700 (PDT) Received: from apl.jhu.edu (kslip48.apl.jhu.edu [128.220.108.58]) by aplcenMP.apl.jhu.edu (8.9.3+Sun/8.9.1) with ESMTP id CAA19532 for ; Sat, 9 Sep 2000 02:47:35 -0400 (EDT) Message-ID: <39B9DD78.4FFAD5CD@apl.jhu.edu> Date: Sat, 09 Sep 2000 02:49:28 -0400 From: Chuck McCrobie X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@freeBSD.ORG Subject: ODS2 File System for FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been working on read-only of OpenVMS Files-11 ODs-2 file system for FreeBSD 3.3 and 4.0. I would like to contribute this file system to the FreeBSD project. What is the best method of doing so? Also, I wish to license the file system under the BSD license found in /usr/share/examples/etc/bsd-style-copyright, but I'm concerned that some Linux kiddie will GPL the file system. What prevents this from happening? Chuck McCrobie (** MAD VAX **) mccrobi@apl.jhu.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 9 13:31:57 2000 Delivered-To: freebsd-fs@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id C6ABD37B42C for ; Sat, 9 Sep 2000 13:31:55 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id QAA67403; Sat, 9 Sep 2000 16:31:54 -0400 (EDT) Date: Sat, 9 Sep 2000 16:31:53 -0400 (EDT) From: "Matthew N. Dodd" To: Chuck McCrobie Cc: freebsd-fs@FreeBSD.ORG Subject: Re: ODS2 File System for FreeBSD In-Reply-To: <39B9DD78.4FFAD5CD@apl.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 9 Sep 2000, Chuck McCrobie wrote: > I've been working on read-only of OpenVMS Files-11 ODs-2 file system > for FreeBSD 3.3 and 4.0. I would like to contribute this file system > to the FreeBSD project. What is the best method of doing so? !!! Just what I've been looking for! First you need to get it running against -CURRENT. Then you need to find someone to commit it. I'd be willing but I'd feel much better if one of the other FS gurus took a look at it. Where can I take a look at what you've got? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Sep 9 23:47:18 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ns.altadena.net (ns.altadena.net [206.126.144.2]) by hub.freebsd.org (Postfix) with ESMTP id 6B2D837B423; Sat, 9 Sep 2000 23:47:14 -0700 (PDT) Received: (from pete@localhost) by ns.altadena.net (8.11.0/8.8.8) id e8A6l4N26872; Sat, 9 Sep 2000 23:47:04 -0700 (PDT) (envelope-from pete) From: Pete Carah Message-Id: <200009100647.e8A6l4N26872@ns.altadena.net> Subject: MSDOSFS oddity To: current@freebsd.org Date: Sat, 9 Sep 2000 23:47:04 -0700 (PDT) Cc: fs@freebsd.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Probably not many -current users use msdosfs; I use it only for the occasional floppy (extremely rare now) and the flash cards from my electronic cameras. On trying to mount one of these today, I ran into a problem (apparently in the msdosfs_vnops change of Sept 2, since a system made the previous Wed didn't have this problem) where any msdosfs system (I mount it 'ro,longnames,noauto') comes mounted with perms d--------- (so noone but root can reference it) and names translated to lower case. I've come to count on that last not happening (besides if you wanted win95 behavior it would leave the first letter capital). The perms thing is a real problem. The name translation could be too (It is for me since I sort files together with previous reads so the change will really mess things up.) (unless longnames implies uc-lc conversion; this really shouldn't happen since win95 actually supports mixed case correctly (though doesn't default to generating it). I see no new mount option to control the name conversion. Hopefully there is no new attempt at text file conversion built into the filesystem too since there is no real way to tell what is a text file or not... On trying this with 'shortnames', it still has both problems... I presume that my flashcard doesn't have a win95 directory structure present but don't really know. It only works right if the camera formats it :-) I can get around it for now but as with basename(1), gratuitous changes to long-standing behavior is vexing at best. -- Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message