From owner-freebsd-fs@FreeBSD.ORG Sun Jun 10 23:11:29 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 7101A16A400 for ; Sun, 10 Jun 2007 23:11:29 +0000 (UTC) (envelope-from lists.freebsd@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id 1680F13C447 for ; Sun, 10 Jun 2007 23:11:28 +0000 (UTC) (envelope-from lists.freebsd@gmail.com) Received: by qb-out-0506.google.com with SMTP id b14so2228699qbc for ; Sun, 10 Jun 2007 16:11:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=NmhEoo/mQSqO8YM4n4csvKmfilezZpEAz/NypKz5GTjlE7FhV/aBUE/d7nlaxR5xBp6ilaE5AY1BEPt9gGA2mIXCejTX+1/kOKYfaVwo6a6kB95c+tQuzn8i6D1sPLme7JleTD9D2H3LNLg+kYmKD6OaPxMxyawK1TQFROelAuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=cpnJFHy8+DdgfuRYUFpuqgnMbsSk3wTuR+/VM+OFju8ZY0nwnlmOAAidsyhnvaWDtcuyoL0hmPZ4QwiFDzkXBmLdDZfV+mcJ+PiL3VGKG5WL4msYbNDJr0YV/eWlGwlA5nVrFvC2R/YqkeiHxnC9W4jXpCoOlNYf83ZI085QIsQ= Received: by 10.143.162.8 with SMTP id p8mr252764wfo.1181517087516; Sun, 10 Jun 2007 16:11:27 -0700 (PDT) Received: by 10.143.155.17 with HTTP; Sun, 10 Jun 2007 16:11:27 -0700 (PDT) Message-ID: <99c92b5f0706101611w3cb84a1fo7ac03940afac3782@mail.gmail.com> Date: Mon, 11 Jun 2007 01:11:27 +0200 From: "Richard Noorlandt" To: freebsd-fs@freebsd.org In-Reply-To: <20070609020208.GA38821@keira.kiwi-computer.com> MIME-Version: 1.0 References: <99c92b5f0706070804p42da0881kfc866b192be60ed5@mail.gmail.com> <20070607164116.GA95991@keira.kiwi-computer.com> <99c92b5f0706081530t454ed9cfp4f95b9afd19e7ed5@mail.gmail.com> <20070609020208.GA38821@keira.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: tunefs question 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: Sun, 10 Jun 2007 23:11:29 -0000 2007/6/9, Rick C. Petty : > > On Sat, Jun 09, 2007 at 12:30:04AM +0200, Richard Noorlandt wrote: > > Large filesystems don't seem to be very well > > supported at the moment. > > Where do you arrive at this conclusion? UFS2 supports large filesystems > very well. The only known problems have to do with snapshots and full > filesystems, and these affect large filesystems as well as small. It seems true that UFS itself supports large filesystems quite well. What I actually meant here is the fact that may other parts of the system don't support it very well. In particular, using growfs poses a bit of a problem. At the moment one can easily create and operate a large filesystem. But once you want to grow it, boot from it (ok, true... why would someone want that?) or perhaps want to do something non-standard with it, you'll tend to run into trouble. Though I have the idea that this is the case in most current operating systems and/or programs. > I hope (and believe) ZFS will settle this. It > > Then you are mistaken. ZFS has large memory requirements, and as you grow > the filesystem you require more memory. UFS has a small memory > footprint... it only requires memory for one cylinder group (superblock > plus free bitmaps), plus all indirect blocks, in addition to the > referenced > blocks for each file open. This might be true, but when you use ZFS on a dedicated fileserver this is less of an issue. Though I haven't really looked into the ZFS details yet. Using it on FreeBSD in its current state is no option for me anyway. I also don't see ZFS as a replacement for UFS, but in certain situations I think they could complement eachother quite well. It's all about picking the right filesystem for the task at hand, and I'm happy that ZFS adds something completely different to choose from. This is not meant to critical to ZFS.. each file system has its own perks > and problems. UFS has been tested and used for much longer, at least with > the default newfs parameters. Also, it's called fast file system for a > reason. A name doesn't define characteristics. The name Fast Filesystem was given to it years ago, and things change. Though the fact that it was never replaced could be an indication that it must be a solid performer. > And when you change the number of inodes at filesystem creation, what > effect > > will it have when you run growfs later on? Will it expand the filesystem > > with an equal inode density, or is it expanded with the default density? > > growfs currently doesn't look at inode density. If you run growfs on a > filesystem without modifying the size, it will allocate extra metadata > blocks and could end up failing if the filesystem is nearly full. growfs > wasn't developed at the same time as newfs, and the authors decided to > ignore inode density as an option. IMO, this is a bug. Although the > density is not stored as a parameter in the superblock, it is trivial to > compute. Someday I'll probably get around to sending them a patch. That's bad news, since I was planning to use growfs in the future. From various growfs related discussions I started to wonder if there is any coordinated effort to completely revise it. All I see is a bunch of not very well tested patches, making growfs a very risky tool to use. It would be great if it was to be completely fixed and debugged, especially because it is part of the base system. Too bad that I don't have time to delve into it myself. I guess I'll refrain from tweaking the filesystem that has to grow in the future. Too bad for the wasted space, but at the moment I think there are too many issues involved. For all the other filesystems, your inode advice is of great help. Best regards, Richard