From owner-freebsd-fs Mon Oct 15 9:53:33 2001 Delivered-To: freebsd-fs@freebsd.org Received: from bgmail4.impsat.net.co (bgmail4.impsat.net.co [200.31.19.6]) by hub.freebsd.org (Postfix) with ESMTP id EC72937B40C for ; Mon, 15 Oct 2001 09:53:19 -0700 (PDT) Received: from [206.114.11.102] (helo=oemcomputer) by bgmail4.impsat.net.co with smtp (Exim 3.16 #1) id 15tAFr-0003mJ-00 for freebsd-fs@freebsd.org; Mon, 15 Oct 2001 11:06:15 -0500 Reply-To: From: " Rueda" To: Subject: =?iso-8859-1?Q?M=E1s_de_15.000_Empresas_a_su_disposici=F3n?= Date: Mon, 15 Oct 2001 11:04:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mensaje enviado por rueda@elsitio.net.co Empres@s - Colombia Potente Herramienta para Mercadeo y Ventas. Encuentre los clientes que usted necesita, con un simple click en nuestra base de datos de más de 15Mil Empresas Importantes de Colombia, con más de 70.000 directivos y ejecutivos. La Base de Datos y la Aplicación le permiten localizar y calificar sus mejores prospectos, aprender más sobre sus clientes, proveedores y competidores y crear eficientes campañas de correo, teléfono, e-mail, fax y campañas de campo. La Base de Datos de Empresas (más de 15Mil) maneja los siguientes campos: Razón Social, sigla, Nit, dirección, teléfono, fax, actividad empresarial (código CIIU Rev. 3.0), número de empleados, ciudad y departamento. La Base de Datos de directivos y ejecutivos (más de 70Mil) maneja los siguientes campos: nombre, cargo, area por cargos, dirección, teléfono, fax. Estas bases de datos se encuentran relacionadas, de tal forma que la aplicación hace búsquedas simples o complejas por todos estos campos, agrupa diferentes tipos de búsquedas, prepara e imprime reportes, rótulos y cartas, hace llamadas telefónicas y envía email´s. COMO VALOR AGREGADO le damos acceso a toda la información sobre COMERCIO EXTERIOR, a través de enlaces Vía Internet a las Bases de Datos de MINCOMEX (27000 Importadores), PROEXPO (4.000 Exportadores y sus ejecutivos), Y LA COMUNIDAD ANDINA. También le facilitamos la conexión a sus propios enlaces. Solicite información adicional vía email sobre contenido de la base de datos, fuentes de la información, actualización, funciones que permite ejecutar la aplicación, versiones, precios y empresas que la estan utilizando, o enviando los siguientes datos al Fax 6178102 - 6179073 Bogotá – Colombia o llamando directamente a Florentino Rueda, gerente comercial al Cel. 033-3396180 Empresa Nit Ciudad Dirección Teléfono Fax Nombre Cargo P.D. Si este mensaje no es de su interés, considere dirigirlo a la Gerencia General y/o Mercadeo, si no desea recibir mensajes como este, por favor déjenos saberlo a rueda@elsitio.net.co para eliminar su dirección en nuestra base de datos. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 16 20:47:13 2001 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 828FA37B40C; Tue, 16 Oct 2001 20:47:07 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 8CB1914C2E; Wed, 17 Oct 2001 05:47:05 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matthew Dillon Cc: John Baldwin , fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: <200110170229.f9H2Tph84237@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 17 Oct 2001 05:47:05 +0200 In-Reply-To: <200110170229.f9H2Tph84237@apollo.backplane.com> Message-ID: Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [moving from -hackers to -fs where this *really* belongs] Matthew Dillon writes: > This would be an improvement, but not enough of an improvement. > We need to be able to discard most of the vnodes while simply > holding the mntvnode mutex, without even having to get the vnode > mutex or release the mntvnode mutex. When we find a vnode that > 'might' require some action, that's when we do the heavy-weight > mutex junk. At least in the case where it's ok to occassionally > not get it right (which is most cases). I think you're basically repeating with different words what I said in the mail you replied to. What I said can be summarized as "don't acquire or release any locks until we know the vnode is dirty". The loop checks three pieces of information to see if the vnode is dirty: - vp->v_type: this can't change while the mntvnode lock is held, because it can only change if the vnode is reclaimed and reused, and you need the mntvnode lock to reclaim a vnode. - vp->v_data: I believe the same comment applies as above; vp->v_data is only manipulated in ffs_vget() and ufs_reclaim(). The first occurs before the vnode is inserted into the list, and the second occurs after it has been removed. - ip->i_flag (where ip == vp->v_data): may possibly require the vnode lock to be held. - vp->v_dirtyblkhd: may possibly require the vnode lock to be held. Actually, I'm willing to take my chances with the latter two; unless there's a possibility that the value read will be corrupted (rather than just stale) in case of a race, it doesn't really matter. There are four possibilities: - vnode is dirty and gets synced: GOOD! - vnode is clean and doesn't get synced: GOOD! - vnode is dirty and doesn't get synced: means it was dirtied while it was being examined by ffs_sync(); the current code already allows that, and the only way to prevent it is to grab a filesystem-wide lock - I don't really see the point. - vnode is clean but gets synced anyway: means it was cleaned while it was being examined by ffs_sync(), which is already possible with the current code (one process calls sync() while another calls fsync()); see above. Somebody on IRC suggested changing ffs_sync() to traverse the synclist instead of the mountpoint's vnode list, and just comparing v_mount to mp and ignoring vnodes that aren't "ours". It would work, but gives me goosebumps for some reason. All of this only solves part of the problem, though - the ffs_sync() part - there's still something screwy with sched_sync(), but I'll need to acquite more profiling data to figure out just *what*. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Oct 16 22:32:12 2001 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 60A4F37B405; Tue, 16 Oct 2001 22:32:10 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id CC97214C2E; Wed, 17 Oct 2001 07:32:08 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matthew Dillon Cc: John Baldwin , fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: <200110170229.f9H2Tph84237@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 17 Oct 2001 07:32:08 +0200 In-Reply-To: Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dag-Erling Smorgrav writes: > Somebody on IRC suggested changing ffs_sync() to traverse the synclist > instead of the mountpoint's vnode list, and just comparing v_mount to > mp and ignoring vnodes that aren't "ours". It would work, but gives > me goosebumps for some reason. Another possibility, of course, is to have ffs_sync() simply check if the vnode is on a worklist (v_flags & VONWORKLIST != 0) but that requires acquiring the vnode interlock, so we gain nothing. > All of this only solves part of the problem, though - the ffs_sync() > part - there's still something screwy with sched_sync(), but I'll need > to acquite more profiling data to figure out just *what*. Actually, there's nothing screwy about sched_sync(), except that I overlooked the fact that it calls sync_fsync() (through VOP_FSYNC()) which calls ffs_sync(). Judging from collected stats, I'm wondering if there's really any point in calling ffs_sync() (indirectly) from sched_sync(), as it seems to rarely actually *do* much except screw up my interrupt latency. I guess it's useful as a safety net, but I don't really see how a vnode can be dirty and not on the sync list? Ditching the syncer nodes will also (finally) allow FreeBSD laptops to let their disks spin down when idle... DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 17 6:12:40 2001 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DDA7037B405; Wed, 17 Oct 2001 06:12:37 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 7683414C2E; Wed, 17 Oct 2001 15:12:35 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matthew Dillon Cc: John Baldwin , Bruce Evans , fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: <200110170229.f9H2Tph84237@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 17 Oct 2001 15:12:35 +0200 In-Reply-To: Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dag-Erling Smorgrav writes: > Actually, there's nothing screwy about sched_sync(), except that I > overlooked the fact that it calls sync_fsync() (through VOP_FSYNC()) > which calls ffs_sync(). Judging from collected stats, I'm wondering > if there's really any point in calling ffs_sync() (indirectly) from > sched_sync(), as it seems to rarely actually *do* much except screw up > my interrupt latency. I guess it's useful as a safety net, but I > don't really see how a vnode can be dirty and not on the sync list? This apparently *does* happen, but rarely enough that it might be a race condition between the syncer and the code I added to cound vnodes that ffs_sync() considered dirty but that weren't on the worklist. I thought it might happen when the file system was mounted async, but apparently it doesn't; the only case in which I'm not entirely sure that a dirty vnode is put on the worklist is when it's dirtied by a pure metadata update, but empirical tests show that doing tons of metadata updates (touch(1)ing hundreds of thousands of files) does not significantly increase the number of dirty vnodes that are not on the worklist, even on an async file system. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 17 10: 9:16 2001 Delivered-To: freebsd-fs@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7710137B407; Wed, 17 Oct 2001 10:09:12 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9HH98i97328; Wed, 17 Oct 2001 10:09:08 -0700 (PDT) (envelope-from dillon) Date: Wed, 17 Oct 2001 10:09:08 -0700 (PDT) From: Matthew Dillon Message-Id: <200110171709.f9HH98i97328@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: John Baldwin , fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: <200110170229.f9H2Tph84237@apollo.backplane.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :Another possibility, of course, is to have ffs_sync() simply check if :the vnode is on a worklist (v_flags & VONWORKLIST != 0) but that :requires acquiring the vnode interlock, so we gain nothing. : :> All of this only solves part of the problem, though - the ffs_sync() :> part - there's still something screwy with sched_sync(), but I'll need :> to acquite more profiling data to figure out just *what*. : :Actually, there's nothing screwy about sched_sync(), except that I :overlooked the fact that it calls sync_fsync() (through VOP_FSYNC()) :which calls ffs_sync(). Judging from collected stats, I'm wondering :if there's really any point in calling ffs_sync() (indirectly) from :sched_sync(), as it seems to rarely actually *do* much except screw up :my interrupt latency. I guess it's useful as a safety net, but I :don't really see how a vnode can be dirty and not on the sync list? Woa! No, you can't get rid of sync_fsync(). The syncer worklist only applies to vnodes with dirty blocks. It is not used to schedule async meta-data updates (such as atime updates), nor does the worklist deal with converting dirty VM pages to dirty buffer cache buffers (though this is usually done right off the bat, there are situations where it is not done), nor does the worklist deal with lazy quota updates. :Ditching the syncer nodes will also (finally) allow FreeBSD laptops to :let their disks spin down when idle... : :DES This can be fixed fairly easily I think, but you can't ditch the syncer vnodes. We simply have to make the filesystem be a bit smarter about syncing the superblock. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Oct 17 16: 3:30 2001 Delivered-To: freebsd-fs@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B9CFD37B409; Wed, 17 Oct 2001 16:03:26 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9HN3Hq37572; Wed, 17 Oct 2001 16:03:17 -0700 (PDT) (envelope-from dillon) Date: Wed, 17 Oct 2001 16:03:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200110172303.f9HN3Hq37572@apollo.backplane.com> To: Dag-Erling Smorgrav , Paul Saab Cc: John Baldwin , Bruce Evans , fs@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: <200110170229.f9H2Tph84237@apollo.backplane.com> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm slowly tracking down the issues with sync. There are three or four. The main problem appears to be simply due to the overhead of the locking, plus the overhead is a number of recent additions. For example, VOP_GETVOBJECT(). The core vnode scanning loop is extremely cycle-sensitive when you have hundreds of thousands of vnodes. Even just adding a subroutine call can tripple the overhead. I'm integrating a number of performance fixes for sync into my kern.maxvnodes patchset. The two are tied together, unfortunately, due to having to change the vnode list from a LIST to a TAILQ. I have made two performance fixes for sync so far, they are available in the kern.maxvnodes patch #3 (for -stable only at the moment), at: http://apollo.backplane.com/FreeBSD4/ http://apollo.backplane.com/FreeBSD4/maxvnodes-03.diff These performance fixes are to vfs_msync() and ffs_sync(). I have not made any performance fixes to qsync() yet (which only applies if quotas are turned on). If hundreds of thousands of vnodes are present 'sync' eats about 1/5 the cpu it ate before. The glitch is still there, but not as pronounced. The only way to really get rid of the glitch will be to separate the vnode list in the mount structure into two. A 'clean' and a 'dirty' list. This patch set is pretty messy already so I'm going wait on that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Oct 19 19:24: 1 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.zeran.co.jp (mail.zeran.co.jp [210.251.65.100]) by hub.freebsd.org (Postfix) with ESMTP id D6AFA37B401 for ; Fri, 19 Oct 2001 19:23:54 -0700 (PDT) Received: from html (slip-12-64-192-188.mis.prserv.net [12.64.192.188]) by mail.zeran.co.jp (8.9.1/3.7W) with SMTP id LAA02653; Sat, 20 Oct 2001 11:22:24 GMT Message-Id: <200110201122.LAA02653@mail.zeran.co.jp> From: HFDDLHIN36@yahoo.com To: galbner@madbbs.com Subject: URGENT 49 More People Needed Time:7:16:58 PM Date: Fri, 19 Oct 2001 19:16:58 Mime-Version: 1.0 Content-Type: text/html; charset="DEFAULT" Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org  EARN $1783.00 OR MORE PER WEEK! --  

This Offer Is Limited To The First 49 People Who Contact Me Today!---------
If you are tired of all the empty promises of money-making schemes, you’re in Luck! We have weeded out the scams and shams and have found the best opportunities available. You can “truly” be making $100’s, $1000’s or more in extra cash a month. How does that sound? If you liked the sound of that, then how about this? You do not have to pay one dime to find out about these true money making opportunities. Just click here and we will show you the bes “real” moneymakers available. It is absolutely 100% FREE, so visit us today, don’t miss out on a real opportunity!







CLICK HERE NOW FOR DETAILS











































___________________________________________________















Our company will never send e-mail unsolicited. You have







received this message we are personal contacts, or you have







selected to receive occasional promotional e-mails from us







from a website that we operate.















If you would like to unsubscribe your e-mail address from







our mailing list we will do this for you. Please CLICK HERE







and type in your e-mail address on the form given to you.







___________________________________________________
















To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message