From owner-freebsd-questions Mon Nov 6 9:33:28 2000 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-27-149-77.mmcable.com [24.27.149.77]) by hub.freebsd.org (Postfix) with SMTP id 3B01637B479 for ; Mon, 6 Nov 2000 09:33:26 -0800 (PST) Received: (qmail 52134 invoked by uid 100); 6 Nov 2000 17:33:25 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14854.60261.548585.645101@guru.mired.org> Date: Mon, 6 Nov 2000 11:33:25 -0600 (CST) To: Shashi Joshi Cc: questions@freebsd.org Subject: Re: filesystem question In-Reply-To: <112162380@toto.iv> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shashi Joshi types: > Hi, > What is the limit on number of files/dir/subsirs on a filesystem? Yes. Each one takes up an inode, and there are a limited number of inodes in a filesystem. You can set it when the filesystem is created if you need to. See the newfs man page. > Does creating/deleting temp files on a FS stress it too much, is bad > for it, canm cause disk errors? If they can, it's a bug. > e.g. If I have a flat file database which may result in a few thousand > files on a FS, (say 5 files per user), and will also result in creating > deleting and of course read/write of files. On the other hand, if I > install MySql or some other database, then I have only say 10-20 files > (including index files) and now the traffic passes through the database > thread. I mean instead of reading the OS files directly, the web page > will cause a DB query, which will pass file contents (data) to it. > > Which one is better/How do they compare? Unless the files are completely unrelated, use the SQL server. If there is some file written to by multiple transactions, you'll have to do the locking on it by hand, which could wind up single-threading your web application. A well-written SQL server deals with all that stuff for you, and the code is has been tested better than you're liable to want to test yours. If you use a server that supports transactions, you can make the same magic apply over an entire interaction, and back things out by simply aborting the transaction.