Date: Sat, 28 Feb 1998 03:17:37 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: asami@FreeBSD.ORG (Satoshi Asami) Cc: shimon@simon-shapiro.org, grog@lemis.com, hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, wilko@yedi.iaf.nl Subject: Re: SCSI Bus redundancy... Message-ID: <199802280317.UAA25486@usr06.primenet.com> In-Reply-To: <199802280105.RAA18825@vader.cs.berkeley.edu> from "Satoshi Asami" at Feb 27, 98 05:05:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802280317.UAA25486>