From owner-freebsd-hackers Fri Feb 27 19:18:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA02603 for freebsd-hackers-outgoing; Fri, 27 Feb 1998 19:18:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA02592; Fri, 27 Feb 1998 19:18:10 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA11752; Fri, 27 Feb 1998 20:17:46 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd011745; Fri Feb 27 20:17:43 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id UAA25486; Fri, 27 Feb 1998 20:17:37 -0700 (MST) From: Terry Lambert Message-Id: <199802280317.UAA25486@usr06.primenet.com> Subject: Re: SCSI Bus redundancy... To: asami@FreeBSD.ORG (Satoshi Asami) Date: Sat, 28 Feb 1998 03:17:37 +0000 (GMT) Cc: shimon@simon-shapiro.org, grog@lemis.com, hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, wilko@yedi.iaf.nl In-Reply-To: <199802280105.RAA18825@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 27, 98 05:05:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think it's about time people stop answering the question "can I > increase the size of an array?" with anything else than "not until we > have a filesystem to support it." We're just confusing people. FFS can support increased size through the addition of cylinder groups. There are (minor) fragmentation issues with doing this, but they can be addressed seperately (most easily with a backup/restore). The code to bump the number of cylinder groups up is trivial. You can't bump the number of cylinder groups down without writing a defragmenter that includes code to allow biasing reallocation against the area you want to remove. There isn't currently any kind of defragmenter because you don't get fragmentation unless you go out of your way to overfill the disk and/or you start adding cylinder groups. 8-). The code to deal with removing an intermediate piece (instead of taking it off the end) is also trivial, assuming it has been defragged out of. You set some limit M on the number of elements you can agregate together into a virtual device, and steal log2(M) bits off the top of the 64 bit block address space. This will reduce the maximum size an FS can be, but nobody has written an HSM for FreeBSD, and hooked up the largest tape robot there is to it, so it's not an issue. 8-). When a block request comes in, you split the bits into "element identifier" and "block on element". This is a pretty trivial change to *_balloc(), and it won't affect any existing FS's, unless M gets set insanely large. Removing the *first* piece is a harder problem because of the definitional value for inode #2 (historical note: FS roots are inode #2 because inode #1 used to be the bad block list, and can't be used because there are archivers that know this and won't archive inode #1). This requires that you change the location of the root of the FS to a different inode number. This is actually not terribly difficult; you can do it by allocating a "root inode" field in the superblock. The problem here is that superblock changes like new/deleted fields are non-trivial because of the installed base conversion problem and the tools problems they cause (ie: newfs would have to know about it, fsck would have to know about it, you'd have to change every copy of the superblock on disk so mount wouldn't go ballistic, etc. -- it's an upgrade nightmare). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message