From owner-freebsd-fs@FreeBSD.ORG Tue Feb 13 05:58:10 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA27216A401 for ; Tue, 13 Feb 2007 05:58:09 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: from web58601.mail.re3.yahoo.com (web58601.mail.re3.yahoo.com [68.142.236.199]) by mx1.freebsd.org (Postfix) with SMTP id 70E2D13C4AA for ; Tue, 13 Feb 2007 05:58:07 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: (qmail 55406 invoked by uid 60001); 13 Feb 2007 05:58:06 -0000 Message-ID: <20070213055806.55404.qmail@web58601.mail.re3.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PhKGbwkFY0Px/s8odWv2DYWHxh1ZXYOWPuUmBNHxgSjVes/CeQm9nNVboJFSLzrzwKTw53vMoWyCX/tI0TAelZLOgAq3ah6L3nLV4/9boW/nLZ3pzTcAUL/mRFlsuZAjFAGvisXHZQjM8f70eLkfitOUJO+BC6SnPaDhs4VctyA=; X-YMail-OSG: Vr6Z8v8VM1lbVo187usqdqvexbHqiG5V_aIC8TU4S7CqsX2mAIXEWa9MiSFK5UWFS3eHXDMwek7G.NMsngFs1FE6Yh.hdtj6zKaQR7il4nU228X.n2JTcA-- Received: from [71.136.255.127] by web58601.mail.re3.yahoo.com via HTTP; Mon, 12 Feb 2007 21:58:06 PST Date: Mon, 12 Feb 2007 21:58:06 -0800 (PST) From: Arone Silimantia To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: olli@lurza.secnetix.de Subject: Re: comments on newfs raw disk ? Safe ? (7 terabyte array) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2007 05:58:10 -0000 Oliver, On Mon, 12 Feb 2007, Oliver Fromme wrote: > > > You'll probably want to reduce the inode density (i.e. > > > increase the bytes-per-inode ratio). With the default > > > value, an fsck will be a royal pain, no matter whether you > > > use background fsck (with snapshots) or not. It might even > > > not work at all if you don't have a huge amount of RAM. > > > > Well, I have 4 GB of physical RAM, and 4 GB of swap - so does that > > total of 8 GB satisfy the "1 GB per TB" requirement, or do I really > > need >5.5 GB of actual swap space (in addition to the physical) ? > > That "1 GB per TB" requirement is just a rule of thumb. > I don't know hoe accurate it is. Also note that it is > desirable to avoid having fsck use swap, because it will > be even slower then. A lot slower. Ok, understood. But regardless of performance, fsck will use BOTH physical and swap, so as far as fsck is concerned, I have 8 GB of memory ? > # newfs -i 65536 > > That will leave room for about 15 million inodes per TB, > which is plenty for your needs. > > By the way, reducing the inode density like that will also > give your more space for actual file data. In UFS2, every > inode takes 256 bytes. Reducing the bytes-per-inode ratio > from 4 KB to 64 KB will give you additional 60 GB of space. > _And_ it will reduce the memory and time requirements of > fsck. Thank you - this is great advice. > > Well, I don't mind a 24 hour fsck, and I would like to remove > > complexity and not be so on the bleeding edge with things. Since I > > am only using 5mil inodes per TB anyway, that ends up being 25-30 > > million inodes in the 5 TB drive which I think could fsck in a day > > so. > > I suggest you test it before putting it into production, > i.e. populate the file system with the expected number of > files, then run fsck. Well, here is what I am assuming, and I would like to get some confirmation on these two points: - The time it takes to fsck is not a function of how many inodes are initialized from newfs, but how many you are _actually using_. - But the amount of memory the fsck takes is a function of how many inodes exist, regardless of how many you are actually using. Are these two interpretations correct ? > > I just need to know if my 4+4 GB of memory is enough, and if this > > option in loader.conf: > > > > kern.maxdsiz="2048000000" > > That will limit the process size to 2 GB. You might need > to set it higher if fsck needs more than that. (I assume > you're running FreeBSD/amd64, or otherwise you'll run into > process size limitations anyway.) Well ... no, I am using normal x86 FreeBSD on an Intel based system. I have 4 GB of physical ram, and 4 GB of swap. So I am tempted to just make that number 4096000000 and be done with it ... if fsck doesn't need that much memory, there is no harm to the system in simply having an inflated limit like that, is there ? I guess if I want to be safe and guard against a rogue, runaway, memory eating process, I could ratchet it up to (physical_ram - 256 megs). Which brings me to my last question: I understand why it's not useful to try to compute fsck _times_ - there are so many factors from disk speed to array speed to stripe size to population, etc. - who knows how long it will take. BUT, why isn't it possible to compute fsck _memory needs_ ? If I have a filesystem of A size with X inodes init'd, and Y inodes used, shouldn't I be able to compute how much memory fsck will need ? Thanks again. --------------------------------- No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started.