From owner-freebsd-fs Sun Jul 9 14:30:44 2000 Delivered-To: freebsd-fs@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EB9237B67A; Sun, 9 Jul 2000 14:30:35 -0700 (PDT) (envelope-from john@baldwin.cx) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id OAA16140; Sun, 9 Jul 2000 14:30:34 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id OAA00514; Sun, 9 Jul 2000 14:31:18 -0700 (PDT) (envelope-from john) Message-Id: <200007092131.OAA00514@john.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 09 Jul 2000 14:31:17 -0700 (PDT) From: John Baldwin To: hackers@FreeBSD.org Subject: Lovely FFS panic on 4.x-stable Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org IdlePTD 3407872 initial pcb at 2c07e0 panicstr: ffs_clusteralloc: map mismatch panic messages: --- panic: ffs_clusteralloc: map mismatch #0 boot (howto=256) at ../../kern/kern_shutdown.c:302 302 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:302 #1 0xc01492d1 in panic (fmt=0xc02692c0 "ffs_clusteralloc: map mismatch") at ../../kern/kern_shutdown.c:552 #2 0xc01e0e05 in ffs_clusteralloc (ip=0xc0cc8600, cg=30, bpref=983048, len=4) at ../../ufs/ffs/ffs_alloc.c:1190 #3 0xc01e0143 in ffs_hashalloc (ip=0xc0cc8600, cg=30, pref=983048, size=4, allocator=0xc01e0be0 ) at ../../ufs/ffs/ffs_alloc.c:768 #4 0xc01dfb07 in ffs_reallocblks (ap=0xc66e7de4) at ../../ufs/ffs/ffs_alloc.c:442 #5 0xc016f10e in cluster_write (bp=0xc1d1d318, filesize=32768, seqcount=4) at vnode_if.h:1056 #6 0xc01eb596 in ffs_write (ap=0xc66e7e90) at ../../ufs/ufs/ufs_readwrite.c:500 #7 0xc01798c8 in vn_write (fp=0xc0ca7e80, uio=0xc66e7edc, cred=0xc0c56a80, flags=0, p=0xc668c400) at vnode_if.h:363 #8 0xc015637a in dofilewrite (p=0xc668c400, fp=0xc0ca7e80, fd=3, buf=0xbfbef118, nbyte=43774, offset=-1, flags=0) at ../../sys/file.h:159 #9 0xc015627f in write (p=0xc668c400, uap=0xc66e7f80) at ../../kern/sys_generic.c:298 #10 0xc023e1d1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1078005480, tf_esi = 3, tf_ebp = 0, tf_isp = -965836844, tf_ebx = 43774, tf_edx = -1077938511, tf_ecx = 6, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = 671993592, tf_cs = 31, tf_eflags = 659, tf_esp = -1078005516, tf_ss = 47}) at ../../i386/i386/trap.c:1126 (kgdb) up 2 #2 0xc01e0e05 in ffs_clusteralloc (ip=0xc0cc8600, cg=30, bpref=983048, len=4) at ../../ufs/ffs/ffs_alloc.c:1190 1190 panic("ffs_clusteralloc: map mismatch"); (kgdb) list 1185 * Allocate the cluster that we have found. 1186 */ 1187 blksfree = cg_blksfree(cgp); 1188 for (i = 1; i <= len; i++) 1189 if (!ffs_isblock(fs, blksfree, got - run + i)) 1190 panic("ffs_clusteralloc: map mismatch"); 1191 bno = cg * fs->fs_fpg + blkstofrags(fs, got - run + 1); 1192 if (dtog(fs, bno) != cg) 1193 panic("ffs_clusteralloc: allocated out of group"); 1194 len = blkstofrags(fs, len); (kgdb) p blksfree $1 = (u_int8_t *) 0xc20314e0 "ÿ" (kgdb) p *blksfree $2 = 255 'ÿ' (kgdb) p got $3 = 2163 (kgdb) p run $4 = 4 (kgdb) p fs $5 = (struct fs *) 0xc0907800 (kgdb) p *fs $6 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 16, fs_cblkno = 24, fs_iblkno = 32, fs_dblkno = 1016, fs_cgoffset = 2048, fs_cgmask = -1, fs_time = 963175776, fs_size = 1585344, fs_dsize = 1536327, fs_ncg = 49, fs_bsize = 8192, fs_fsize = 1024, fs_frag = 8, fs_minfree = 8, fs_rotdelay = 0, fs_rps = 60, fs_bmask = -8192, fs_fmask = -1024, fs_bshift = 13, fs_fshift = 10, fs_maxcontig = 15, fs_maxbpg = 2048, fs_fragshift = 3, fs_fsbtodb = 1, fs_sbsize = 2048, fs_csmask = -512, fs_csshift = 9, fs_nindir = 2048, fs_inopb = 64, fs_nspf = 2, fs_optim = 0, fs_npsect = 4096, fs_interleave = 1, fs_trackskew = 0, fs_id = {915932514, 1106181948}, fs_csaddr = 1016, fs_cssize = 1024, fs_cgsize = 6144, fs_ntrak = 1, fs_nsect = 4096, fs_spc = 4096, fs_ncyl = 775, fs_cpg = 16, fs_ipg = 7872, fs_fpg = 32768, fs_cstotal = {cs_ndir = 3274, cs_nbfree = 68238, cs_nifree = 330794, cs_nffree = 29696}, fs_fmod = 0 '\000', fs_clean = 0 '\000', fs_ronly = 0 '\000', fs_flags = 2 '\002', fs_fsmnt = "/v", '\000' , fs_cgrotor = 27, fs_csp = {0xc0907000, 0x0 }, fs_maxcluster = 0xc0907400, fs_cpc = 0, fs_opostbl = {{0, 0, 0, 0, 0, 0, 0, 0} }, fs_sparecon = {0 }, fs_contigsumsize = 15, fs_maxsymlinklen = 60, fs_inodefmt = 2, fs_maxfilesize = 8796093022207, fs_qbmask = 8191, fs_qfmask = 1023, fs_state = 0, fs_postblformat = 1, fs_nrpos = 1, fs_postbloff = 0, fs_rotbloff = 0, fs_magic = 72020, fs_space = ""} (kgdb) p cgp->cg_magic $7 = 590421 (which == CG_MAGIC) (kgdb) p cgp->cg_freeoff $8 = 1248 (kgdb) p ((u_int8_t *)(cgp) + (cgp)->cg_freeoff) $9 = (u_int8_t *) 0xc20314e0 "ÿ" (kgdb) p *cgp $12 = {cg_firstfield = 0, cg_magic = 590421, cg_time = 963175776, cg_cgx = 30, cg_ncyl = 16, cg_niblk = 7872, cg_ndblk = 32768, cg_cs = {cs_ndir = 35, cs_nbfree = 1739, cs_nifree = 6581, cs_nffree = 1523}, cg_rotor = 15920, cg_frotor = 15920, cg_irotor = 910, cg_frsum = {0, 29, 2, 2, 57, 95, 59, 61}, cg_btotoff = 168, cg_boff = 232, cg_iusedoff = 264, cg_freeoff = 1248, cg_nextfreeoff = 5916, cg_clustersumoff = 5340, cg_clusteroff = 5404, cg_nclusterblks = 4096, cg_sparecon = { 0 }, cg_space = "\001"} I'm using softupdates on all my filesystems except for /, but the only filesystem with errors when I rebooted was /v, which does run softupdates: /dev/ad2s1e on /v (ufs, local, soft-updates, writes: sync 3 async 788, reads: sync 1768 async 110) > uname -a FreeBSD john.baldwin.cx 4.0-STABLE FreeBSD 4.0-STABLE #13: Sat Jun 17 00:58:47 PDT 2000 john@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386 Kernel and vmcore available if more info is needed. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 9 14:51:38 2000 Delivered-To: freebsd-fs@freebsd.org Received: from server.baldwin.cx (server.geekhouse.net [64.81.6.52]) by hub.freebsd.org (Postfix) with ESMTP id 9369E37B9E6; Sun, 9 Jul 2000 14:51:32 -0700 (PDT) (envelope-from john@baldwin.cx) Received: from john.baldwin.cx (root@john.baldwin.cx [192.168.1.18]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id OAA16246; Sun, 9 Jul 2000 14:51:31 -0700 (PDT) (envelope-from john@baldwin.cx) Received: (from john@localhost) by john.baldwin.cx (8.9.3/8.9.3) id OAA00568; Sun, 9 Jul 2000 14:52:17 -0700 (PDT) (envelope-from john) Message-Id: <200007092152.OAA00568@john.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200007092131.OAA00514@john.baldwin.cx> Date: Sun, 09 Jul 2000 14:52:17 -0700 (PDT) From: John Baldwin To: hackers@FreeBSD.ORG Subject: RE: Lovely FFS panic on 4.x-stable Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 09-Jul-00 John Baldwin wrote: > IdlePTD 3407872 > initial pcb at 2c07e0 > panicstr: ffs_clusteralloc: map mismatch > panic messages: > --- > panic: ffs_clusteralloc: map mismatch >#0 boot (howto=256) at ../../kern/kern_shutdown.c:302 > 302 dumppcb.pcb_cr3 = rcr3(); Some more info related to ffs_isblock(): (kgdb) p got - run + i $2 = 2160 (kgdb) p i $3 = 1 (kgdb) p len $4 = 4 (kgdb) p fs->fs_frag $5 = 8 (kgdb) p (unsigned char *)blksfree[got - run + i] $7 = (unsigned char *) 0x3fffff0f
From ffs_subr.c: int ffs_isblock(fs, cp, h) struct fs *fs; unsigned char *cp; ufs_daddr_t h; { unsigned char mask; switch ((int)fs->fs_frag) { case 8: return (cp[h] == 0xff); ... } -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 10 16:30:34 2000 Delivered-To: freebsd-fs@freebsd.org Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by hub.freebsd.org (Postfix) with ESMTP id 9E45C37B6B6 for ; Mon, 10 Jul 2000 16:30:31 -0700 (PDT) (envelope-from dima@cs.ubc.ca) Received: from cascade.cs.ubc.ca (dima@cascade.cs.ubc.ca [142.103.7.7]) by pedigree.cs.ubc.ca (8.8.8/8.6.9) with ESMTP id QAA12206 for ; Mon, 10 Jul 2000 16:30:31 -0700 (PDT) From: Dmitry Brodsky Received: (dima@localhost) by cascade.cs.ubc.ca (8.9.1/8.6.12) id QAA06084 for freebsd-fs@freebsd.org; Mon, 10 Jul 2000 16:30:29 -0700 (PDT) Message-Id: <200007102330.QAA06084@cascade.cs.ubc.ca> Subject: Meta-Data & stackable FS To: freebsd-fs@freebsd.org Date: Mon, 10 Jul 2000 16:30:29 -0700 (PDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am in the process of creating a stackable fs by using the nullfs as a template. One thing I am having a hard time figuring out is a good way to instantiate additional meta-data with each file. Is that possible? What is the best way of going about doing that? Thanks ttyl Dima -- Dima Brodsky dima@cs.ubc.ca http://www.cs.ubc.ca/~dima 201-2366 Main Mall (604) 822-6179 (Office) Department of Computer Science (604) 822-2895 (DSG Lab) University of British Columbia, Canada (604) 822-5485 (FAX) Computers are like Old Testament gods; lots of rules and no mercy. (Joseph Campbell) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 10 19:27:42 2000 Delivered-To: freebsd-fs@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id 5B8CC37BA9F for ; Mon, 10 Jul 2000 19:27:38 -0700 (PDT) (envelope-from clefevre%no-spam@citeweb.net) Received: (qmail 12978012 invoked from network); 11 Jul 2000 02:27:36 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 11 Jul 2000 02:27:36 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id EAA01297; Tue, 11 Jul 2000 04:27:35 +0200 (CEST) (envelope-from clefevre%no-spam@citeweb.net) Posted-Date: Tue, 11 Jul 2000 04:27:35 +0200 (CEST) To: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: APM and SCSI : suspend Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre Date: 11 Jul 2000 04:27:34 +0200 Message-ID: <8zv9s8o9.fsf@pc166.gits.fr> Lines: 22 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org why it's not possible to suspend SCSI drives like the ATA/IDE ones ? I'm not talking about camcontrol suspend feature. if you have a mounted filesystem, and access a file onto that filesystem while the drive is suspended in this manner, the system gives up. and it is not so good (at all :) to do the same thing if you have some swap space onto that drive, crash... also, I experienced suspended SCSI drives under windows, then warm boot. the boot loader is not able to wake up the drives. so it complains about drive not found and you have to power off/on your machine to wake up the drives. is that feature, suspend/wake up of SCSI drives, programmed in the future ? PS : maybe -arch should be in this thread ? Cyrille. -- home:mailto:clefevre%no-spam@citeweb.net Supprimer "%no-spam" pour me repondre. work:mailto:Cyrille.Lefevre%no-spam@edf.fr Remove "%no-spam" to answer me back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 11 0:44:45 2000 Delivered-To: freebsd-fs@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 43C6A37B941 for ; Tue, 11 Jul 2000 00:44:39 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id AAA36519; Tue, 11 Jul 2000 00:49:23 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Tue, 11 Jul 2000 00:49:22 -0700 (PDT) From: Kelly Yancey To: Dmitry Brodsky Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS In-Reply-To: <200007102330.QAA06084@cascade.cs.ubc.ca> 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 Mon, 10 Jul 2000, Dmitry Brodsky wrote: > Hi, > > I am in the process of creating a stackable fs by using the nullfs as > a template. One thing I am having a hard time figuring out is a good > way to instantiate additional meta-data with each file. Is that > possible? What is the best way of going about doing that? > Use the v_data pointer on your vnodes to point to your local meta-data. Now, if you need this meta-data to be persistent, that's another matter entirely. In that case, you'll probably want to look at umapfs or the quota code for reference. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 11 10:48:43 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 3D8C437BB64 for ; Tue, 11 Jul 2000 10:48:36 -0700 (PDT) (envelope-from robert@fledge.watson.org) 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 NAA36931; Tue, 11 Jul 2000 13:48:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 11 Jul 2000 13:48:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Dmitry Brodsky Cc: freebsd-fs@freebsd.org Subject: Re: Meta-Data & stackable FS In-Reply-To: <200007102330.QAA06084@cascade.cs.ubc.ca> 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 Mon, 10 Jul 2000, Dmitry Brodsky wrote: > I am in the process of creating a stackable fs by using the nullfs as > a template. One thing I am having a hard time figuring out is a good > way to instantiate additional meta-data with each file. Is that > possible? What is the best way of going about doing that? If this is non-persistent meta-data, you can store it off of the vnode in your layer via v_data. However, if it's persistent, you'll need to store it elsewhere, and have a way to map the persistent data back onto the vnodes in future instantiations. For some stacked file systems I've looked at, persistent storage of layering data is done via a transformation on the underlying vnode. In others, namespace escapes are used to provide storage. Both of these techniques have substantial limitations for per-file attribute data (such as ACLs). In the TrustedBSD framework, we've introduced two additional VOP's to get and set extended attributes on files, and support exists in UFS/FFS to back extended attributes. Stacked file systems sitting on top of UFS can store meta-data for a vnode under the layer in EA's off of that vnode. This addresses maintaining a correspondence between the meta-data and nodes, as the namespace quirks of UNIX (hard links, et al) and page/block alignment memory mapping requirements make the other methods at best uncomfortable. One thing to keep in mind with stacked file systems and the UFS attribute mechanism is that locking is a substantial concern: as not all locks can be acquired in advance in the current framework, it's easy to get into deadlock situations. There are also a couple of bugs in the EA support in 5.0, including some refcount issues on the vnodes. Kirk has simple fixes for that, and may already have committed them. In essence, vrele's are missing from some of the syscall wrappers, resulting in vnode leaking. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 11 13:29:20 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 21A8137B8BA for ; Tue, 11 Jul 2000 13:29:13 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 WAA15117; Tue, 11 Jul 2000 22:29:11 +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 WAA02153; Tue, 11 Jul 2000 22:29:11 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Tue, 11 Jul 2000 22:29:11 +0200 (CEST) From: Marius Bendiksen To: Dmitry Brodsky Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS In-Reply-To: <200007102330.QAA06084@cascade.cs.ubc.ca> 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 > I am in the process of creating a stackable fs by using the nullfs as > a template. One thing I am having a hard time figuring out is a good > way to instantiate additional meta-data with each file. Is that > possible? What is the best way of going about doing that? This is a very large part of the point of the new extended attribute mechanisms. These will hopefully cange soon; I'm having talks with R Watson over this. In the meantime, you'll want to use the current IF for it. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 11 13:33:35 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 DDDAD37B899 for ; Tue, 11 Jul 2000 13:33:31 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 WAA15557; Tue, 11 Jul 2000 22:33:29 +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 WAA02170; Tue, 11 Jul 2000 22:33:29 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Tue, 11 Jul 2000 22:33:29 +0200 (CEST) From: Marius Bendiksen To: Kelly Yancey Cc: Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 > Use the v_data pointer on your vnodes to point to your local meta-data. Now, > if you need this meta-data to be persistent, that's another matter > entirely. In that case, you'll probably want to look at umapfs or the quota > code for reference. Absolutely not! Persistent metadata should be stuck in the EAs. We have a mechanism for this, now, so let's not start reinventing the wheel. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 11 23:58:21 2000 Delivered-To: freebsd-fs@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 8B32037BC48 for ; Tue, 11 Jul 2000 23:58:18 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id AAA40151; Wed, 12 Jul 2000 00:03:23 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Wed, 12 Jul 2000 00:03:23 -0700 (PDT) From: Kelly Yancey To: Marius Bendiksen Cc: Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 On Tue, 11 Jul 2000, Marius Bendiksen wrote: > > Use the v_data pointer on your vnodes to point to your local meta-data. Now, > > if you need this meta-data to be persistent, that's another matter > > entirely. In that case, you'll probably want to look at umapfs or the quota > > code for reference. > > Absolutely not! > > Persistent metadata should be stuck in the EAs. We have a mechanism for > this, now, so let's not start reinventing the wheel. > So long as you only stack over FFS. As much as I like the idea of extended attributes, stacked file systems should be able to stack over any other filesystem. Unless I'm mistaken, NFS doesn't support EA's, not to mention any of the misc. filesystems. I don't even know where one would begin trying to add EA support to say, procfs. But the man page touches on this, and other valid converns: As there are a plethora of file systems with differing extended attributes, availability and functionality of these functions may be limited, and they should be used with awareness of the underlying semantics of the supporting file system. Authorization schemes for extended attribute data may also vary by file system, as well as maximum attribute size, and whether or not any or specific new attributes may be defined. How could you possibly build a stackable filesystem using EA's when there are so many unknowns except for the degenerate case of "you can stack this filesystem over FFS, or you can't stack it anywhere". And that doesn't even touch the fact that even with FFS, other filesystems can trample on EA's required by your filesystem. The ideas behind EA's are noble, but I can't see using EA's in practice. :( Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 12 7:15:20 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 5B85637BCC0 for ; Wed, 12 Jul 2000 07:15:16 -0700 (PDT) (envelope-from robert@fledge.watson.org) 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 KAA50724; Wed, 12 Jul 2000 10:14:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 12 Jul 2000 10:14:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kelly Yancey Cc: Marius Bendiksen , Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 On Wed, 12 Jul 2000, Kelly Yancey wrote: > So long as you only stack over FFS. As much as I like the idea of > extended attributes, stacked file systems should be able to stack over > any other filesystem. Unless I'm mistaken, NFS doesn't support EA's, not > to mention any of the misc. filesystems. I don't even know where one > would begin trying to add EA support to say, procfs. On the other hand, it's not clear that this stacking over arbitrary file systems is possible due to differences between file systems in the first place -- as nice as VFS may be, in its current incarnation it doesn't address cache coherency and event issues, numerous different semantics, etc. A growing number of file systems will be supporting EAs, currently including UFS/FFS, XFS, HPFS, and patches are available for ext2fs, although I don't believe they have been ported to FreeBSD. It would be relatively easy, although perhaps not all that useful, to add EA support to procfs, given that there are no persistence requirements beyond the lifetime of the in-kernel process structure. And with a file system like procfs, there is currently no machinery for procfs to notify layers above it of changes in its structure, if stacking were the mechanism of choice. > But the man page touches on this, and other valid converns: > > As there are a plethora of file systems with differing extended > attributes, availability and functionality of these functions may be > limited, and they should be used with awareness of the underlying > semantics of the supporting file system. Authorization schemes for > extended attribute data may also vary by file system, as well as > maximum attribute size, and whether or not any or specific new > attributes may be defined. > > How could you possibly build a stackable filesystem using EA's when there > are so many unknowns except for the degenerate case of "you can stack this > filesystem over FFS, or you can't stack it anywhere". > > And that doesn't even touch the fact that even with FFS, other filesystems > can trample on EA's required by your filesystem. The ideas behind EA's are > noble, but I can't see using EA's in practice. :( I think the real-world answer, and the reason I opted to implement EAs, is that stacking is not a feasible solution for exactly the same reasons: the infrastructure is (at best) flakey, the semantics are poorly defined, key functionality is missing for cache coherency and event handling (especially if you stack over NFS or other weak-consistency file systems), and without some sort of transactional (using the term loosely) event agregation across layers, it's not even clear that the result can be reliable in failure situations. I don't see any of that being fixed soon. EAs have relatively well-defined semantics, although some fs-specific limitations with well-defined failure modes, and are supported by a wide (and increasing) variety of file systems. In any case, assuming that a working and sufficiently strong stacking environment exists (FiST satisfies a number of these requirements, I believe), the chances are you'd add the service (say, ACLs) by layering EA's on top of FFS, and then a service on top of EA+FFS, in which case you'd be relying on vnode operations introduced by the EA layer, and presumably they would strongly resemble the EA VOP's already present, and probably should even be the same VOPs :-). In which case EA+FFS is indistinguishable from FFS w/EAs. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 12 7:32: 6 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 D762537BE62 for ; Wed, 12 Jul 2000 07:32:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) 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 KAA50891; Wed, 12 Jul 2000 10:31:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 12 Jul 2000 10:31:45 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kelly Yancey Cc: Marius Bendiksen , Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 On Wed, 12 Jul 2000, Robert Watson wrote: > In any case, assuming that a working and sufficiently strong stacking > environment exists (FiST satisfies a number of these requirements, I > believe), the chances are you'd add the service (say, ACLs) by layering > EA's on top of FFS, and then a service on top of EA+FFS, in which case > you'd be relying on vnode operations introduced by the EA layer, and > presumably they would strongly resemble the EA VOP's already present, and > probably should even be the same VOPs :-). In which case EA+FFS is > indistinguishable from FFS w/EAs. BTW, I think there's a decent argument that even if you had fully-functional stacking, having the base file store provide EA services is highly desirable, as it allows layers to impose new semantics and meta-data without needing to deal with the namespace and storage issues, and it simplifies the update/consistency problem substantially. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 12 8:28:46 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 5379437BED9 for ; Wed, 12 Jul 2000 08:28:38 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 RAA67019; Wed, 12 Jul 2000 17:28:35 +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 RAA06395; Wed, 12 Jul 2000 17:28:35 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 12 Jul 2000 17:28:35 +0200 (CEST) From: Marius Bendiksen To: Kelly Yancey Cc: Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 long as you only stack over FFS. As much as I like the idea of extended > attributes, stacked file systems should be able to stack over any other > filesystem. Absolutely not. A stacked layer to provide EAs should be added, and all future layers should assume that EA capability is present. This way, we keep things nice and tidy. What on Earth would be the point of adding a new feature like EAs if it is only going to remain unused? > Unless I'm mistaken, NFS doesn't support EA's, not to mention any > of the misc. filesystems. I don't even know where one would begin trying to > add EA support to say, procfs. Procfs isn't persistent in the first place. And, as to NFS, that would be resolved by the use of a stacked layer to actually *provide* EAs. > But the man page touches on this, and other valid converns: [snip] > How could you possibly build a stackable filesystem using EA's when there > are so many unknowns except for the degenerate case of "you can stack this > filesystem over FFS, or you can't stack it anywhere". By adding a stacked layer which translates the semantics of an underlying filesystem, or adds it, if it is not present, you resolve this issue. Further, EA support is entering into many of the new filesystems appearing, including old ones like ext2fs, ffs, xfs, jfs, and hpfs. > And that doesn't even touch the fact that even with FFS, other filesystems > can trample on EA's required by your filesystem. The ideas behind EA's are > noble, but I can't see using EA's in practice. :( This has to do with the authentication mechanism provided. If you make the suser() call always return 0, then you will have any user capable of doing evil things to your filesystem. Same thing here. You need authentication. Robert is already using EAs to add ACL support. Mariyus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 12 8:36:53 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 12E3637C003; Wed, 12 Jul 2000 08:36:49 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 RAA67960; Wed, 12 Jul 2000 17:36:47 +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 RAA06417; Wed, 12 Jul 2000 17:36:47 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Wed, 12 Jul 2000 17:36:47 +0200 (CEST) From: Marius Bendiksen To: Robert Watson Cc: Kelly Yancey , Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 > BTW, I think there's a decent argument that even if you had > fully-functional stacking, having the base file store provide EA services > is highly desirable, as it allows layers to impose new semantics and > meta-data without needing to deal with the namespace and storage issues, > and it simplifies the update/consistency problem substantially. I agree. The main point with EAs is to allow future expansion without going through the usual process of figuring out which already over-abused corner of the FS you can kludge a feature into *this* time. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 12 23:10:43 2000 Delivered-To: freebsd-fs@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 6450837B7E6; Wed, 12 Jul 2000 23:10:40 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id XAA43334; Wed, 12 Jul 2000 23:16:58 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Wed, 12 Jul 2000 23:16:57 -0700 (PDT) From: Kelly Yancey To: Robert Watson Cc: Marius Bendiksen , Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 On Wed, 12 Jul 2000, Robert Watson wrote: > BTW, I think there's a decent argument that even if you had > fully-functional stacking, having the base file store provide EA services > is highly desirable, as it allows layers to impose new semantics and > meta-data without needing to deal with the namespace and storage issues, > and it simplifies the update/consistency problem substantially. > Fair enough. File system implementors just need to remember to check, at mount, that the underlying filesystem does indeed support EAs. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jul 13 17:20:26 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 3020037B901; Thu, 13 Jul 2000 17:20:23 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 CAA24355; Fri, 14 Jul 2000 02:20:21 +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 CAA15411; Fri, 14 Jul 2000 02:20:21 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Fri, 14 Jul 2000 02:20:21 +0200 (CEST) From: Marius Bendiksen To: Kelly Yancey Cc: Robert Watson , Dmitry Brodsky , freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS 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 > Fair enough. File system implementors just need to remember to check, at > mount, that the underlying filesystem does indeed support EAs. EOPNOTSUPP. Anyway, if someone fixes stacking, we should have no problem with stacking EAs on top of anything, which would make requiring EAs for normal operation entirely okay. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 14 15:24: 1 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 2D3ED37BF60 for ; Fri, 14 Jul 2000 15:23:53 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 AAA35674; Sat, 15 Jul 2000 00:23:50 +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 AAA21048; Sat, 15 Jul 2000 00:23:50 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Sat, 15 Jul 2000 00:23:50 +0200 (CEST) From: Marius Bendiksen To: Duane Wessels Cc: freebsd-fs@FreeBSD.ORG Subject: [kern/19479] Re: vnode/inode starvation 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 As noone seems to have touched the PR, you might want to try the following patch: --- ffs_vfsops.c.orig Sat Jul 15 00:24:10 2000 +++ ffs_vfsops.c Sat Jul 15 00:24:43 2000 @@ -1038,9 +1038,9 @@ /* Allocate a new vnode/inode. */ error = getnewvnode(VT_UFS, mp, ffs_vnodeop_p, &vp); if (error) { if (ffs_inode_hash_lock < 0) - wakeup(&ffs_inode_hash_lock); + wakeup_one(&ffs_inode_hash_lock); ffs_inode_hash_lock = 0; *vpp = NULL; FREE(ip, ump->um_malloctype); return (error); @@ -1067,9 +1067,9 @@ */ ufs_ihashins(ip); if (ffs_inode_hash_lock < 0) - wakeup(&ffs_inode_hash_lock); + wakeup_one(&ffs_inode_hash_lock); ffs_inode_hash_lock = 0; /* Read in the disk contents for the inode, copy into the inode. */ error = bread(ump->um_devvp, fsbtodb(fs, ino_to_fsba(fs, ino)), --eof-- It's also available from my homepage at http://home.eunet.no/~mbendiks/patches/ffs-fix2.patch --- Marius Bendiksen On Mon, 26 Jun 2000, Duane Wessels wrote: > Hi, > > I have an application -- a caching proxy called Squid. When benchmarking > Squid on FreeBSD-3.5, I'm seeing very high vnode (inode?) usage. After running > for a few hours under peak load, all of the kernel virtual memory (?) > is consumed by vnodes: > > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > 256 file desc, devbuf, temp, subproc, vnodes, ifaddr, routetbl, FFS node > FFS node343147 85787K 85787K 85787K 742322 1 0 256 > > At this point, any process that wants a new vnode is blocked. Top > shows many processes in 'ffsvgt' state, and one process in 'FFS no' > state. > > I'm using the RELENG_3 branch, sucked down on June 20: > FreeBSD mr-garrison.measurement-factory.com 3.5-STABLE FreeBSD 3.5-STABLE #4: Tue Jun 20 14:15:04 MDT 2000 > root@mr-garrison.measurement-factory.com:/usr/src/sys/compile/SQUID i386 > > > I don't know a whole lot about kernel code and these sorts of low-level > filesystem details. But it seems to me this is really strange. I don't > unerstand why vnodes aren't being reused or freed. > > Does vnode reclaimation sort of rely on processes not living very > long? In my case I have six squid processes that never die, each of > which can touch 500,000 or more disk files. > > Ideas, references, explanations welcome... > > Duane W. > > > > 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 Sat Jul 15 6:32:35 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id A019C37B731 for ; Sat, 15 Jul 2000 06:32:31 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id PAA27698; Sat, 15 Jul 2000 15:39:19 +0200 (CEST) (envelope-from adrian) Date: Sat, 15 Jul 2000 15:39:19 +0200 From: Adrian Chadd To: Marius Bendiksen Cc: Duane Wessels , freebsd-fs@FreeBSD.ORG Subject: Re: [kern/19479] Re: vnode/inode starvation Message-ID: <20000715153918.B22865@ywing.creative.net.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbendiks@eunet.no on Sat, Jul 15, 2000 at 12:23:50AM +0200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jul 15, 2000, Marius Bendiksen wrote: > As noone seems to have touched the PR, you might want to try the following > patch: > > --- ffs_vfsops.c.orig Sat Jul 15 00:24:10 2000 > +++ ffs_vfsops.c Sat Jul 15 00:24:43 2000 > @@ -1038,9 +1038,9 @@ > /* Allocate a new vnode/inode. */ > error = getnewvnode(VT_UFS, mp, ffs_vnodeop_p, &vp); > if (error) { > if (ffs_inode_hash_lock < 0) > - wakeup(&ffs_inode_hash_lock); > + wakeup_one(&ffs_inode_hash_lock); > ffs_inode_hash_lock = 0; > *vpp = NULL; > FREE(ip, ump->um_malloctype); > return (error); > @@ -1067,9 +1067,9 @@ > */ > ufs_ihashins(ip); > > if (ffs_inode_hash_lock < 0) > - wakeup(&ffs_inode_hash_lock); > + wakeup_one(&ffs_inode_hash_lock); > ffs_inode_hash_lock = 0; > > /* Read in the disk contents for the inode, copy into the inode. */ > error = bread(ump->um_devvp, fsbtodb(fs, ino_to_fsba(fs, ino)), > --eof-- > > It's also available from my homepage at > http://home.eunet.no/~mbendiks/patches/ffs-fix2.patch Hrm, if I remember right, you said this is fixed in 4.0, right? The problem Duane was seeing felt more like something not properly releasing vnodes, causing them to pile up rather than being recycled. I haven't got any comments on the above patch except that if you have a lot of busy filesystems which constantly create/delete inodes then it should speed things up a little .. Adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 15 7: 5:29 2000 Delivered-To: freebsd-fs@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id CD50B37BCCD for ; Sat, 15 Jul 2000 07:05:25 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id QAA27814; Sat, 15 Jul 2000 16:12:30 +0200 (CEST) (envelope-from adrian) Date: Sat, 15 Jul 2000 16:12:30 +0200 From: Adrian Chadd To: Duane Wessels Cc: Marius Bendiksen , freebsd-fs@FreeBSD.ORG Subject: Re: [kern/19479] Re: vnode/inode starvation Message-ID: <20000715161229.C22865@ywing.creative.net.au> References: <20000715153918.B22865@ywing.creative.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000715153918.B22865@ywing.creative.net.au>; from adrian@FreeBSD.ORG on Sat, Jul 15, 2000 at 03:39:19PM +0200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jul 15, 2000, Adrian Chadd wrote: > > Hrm, if I remember right, you said this is fixed in 4.0, right? > The problem Duane was seeing felt more like something not properly > releasing vnodes, causing them to pile up rather than being recycled. > I haven't got any comments on the above patch except that if you have > a lot of busy filesystems which constantly create/delete inodes then > it should speed things up a little .. In true Adrian Style(tm), "you said" refers to Duane, not Marius. :-) Adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 15 10:51:23 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 1F82F37C730; Sat, 15 Jul 2000 10:51:19 -0700 (PDT) (envelope-from mbendiks@eunet.no) 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 TAA63947; Sat, 15 Jul 2000 19:51: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 TAA26068; Sat, 15 Jul 2000 19:51:17 +0200 (CEST) (envelope-from mbendiks@eunet.no) X-Authentication-Warning: login-1.eunet.no: mbendiks owned process doing -bs Date: Sat, 15 Jul 2000 19:51:17 +0200 (CEST) From: Marius Bendiksen To: Adrian Chadd Cc: Duane Wessels , freebsd-fs@FreeBSD.ORG Subject: Re: [kern/19479] Re: vnode/inode starvation In-Reply-To: <20000715153918.B22865@ywing.creative.net.au> 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 > Hrm, if I remember right, you said this is fixed in 4.0, right? The PR is at least still open and untouched. > The problem Duane was seeing felt more like something not properly > releasing vnodes, causing them to pile up rather than being recycled. I know. This was merely a long shot at trying to avoid having to do a more complex analysis of the problem, based on the fact that the "ffsvgt" state is used to denote waiting for the lock to resolve. > I haven't got any comments on the above patch except that if you have > a lot of busy filesystems which constantly create/delete inodes then > it should speed things up a little .. *nod*. As well as not waking up swapped-out processes. Marius To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message