Date: Mon, 3 Apr 95 11:14:36 MDT From: terry@cs.weber.edu (Terry Lambert) To: peter@bonkers.taronga.com (Peter da Silva) Cc: PVinci@ix.netcom.com, hackers@FreeBSD.org Subject: Re: large filesystems/multiple disks [RAID] Message-ID: <9504031714.AA07097@cs.weber.edu> In-Reply-To: <199504020609.AAA23597@bonkers.taronga.com> from "Peter da Silva" at Apr 2, 95 00:09:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's fragile because you could for instance have four file systems > > with blocks in the same 16M area of a disk. > > Um, why would you do that? Doesn't that sort of counter the whole reason > for running file systems over multiple disks? No, it doesn't. Perhaps you mean something different that simple spanning when you say "running file systems over multiple disks" than the rest of us mean... Consider: I have a disk. I am cheap. I fill up a partition on the disk. Being cheap, I back everything off, repartition, and restore. Eventually, all partitions on the disk are full. I break down and buy another drive. I add pieces of the drive to my full partitions: o 100M to /home o 8M to swap o 70M to /usr Now there are there partitions in the same 16M area waiting for a crash: o 4M at the end of /home o 8M of swap o 4M at the start (middle) of /usr Spanning is simply a tools for easing the administrative burden; note that the 4M allocation units are *not* anonymous -- in other words, it is difficult or impossible to implement transparent migration of data to ensure the data is (eventually) stored in contiguous allocation units; further, making sure none of your partitions (groups of allocation units) span a disk boundry is tantamount to solving the traveling salesman problem. It can be done, but the migration will be slow. Second scenario: This scenario actually applies to any non-static database with a tendency to grow. I have a 3G database file. Say it is a Sybase database containing the Human Genome Project data (I happen to have one of these, and it is close to 3G, and, indeed, uses Sybase; one wonders why I spent time getting Sybase to run unde IBCS2 no longer 8-)). I had a 2G drive in early 1994, since at the time the HGP database was ~1.8G. Now it has grown, but I am on a research grant, and thus on a limited bugdet. So I can't run out and buy a 4G drive as a replacement. So I buy a 2G drive and "add" it to my HGP database partition. The new database information can now be mirrored into my copy of the database using the standard HGP database mirroring. Unfortunately, spanning this way now means that if I lose one drive or the other, I now lose my entire databse. My risk is doubled; if the drives are otherwise identical, my MTBF is exactly halved (see the nice calculation of MTBF and its meaning that was recently posted to hackers). Simple spanning in both these scenarios is a risk/convenience trade off *only*. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504031714.AA07097>