Date: Tue, 10 Jun 1997 03:15:16 -0400 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: current@FreeBSD.ORG Subject: Re: overclocking Message-ID: <18340.865926916@orion.webspan.net> In-Reply-To: Your message of "Mon, 09 Jun 1997 23:13:23 PDT." <10342.865923203@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ CC: trimmed ] "Jordan K. Hubbard" wrote in message ID <10342.865923203@time.cdrom.com>: > Most importantly, I'd like to be able to migrate off and dismount a > drive from a ccd or add one dynamically, automagically resizing the > filesystem on it in either case, before I could ever consider it close > to mission critical safe. Question: How do you plan to dynamically resize a UFS filesystem? I think it'd take a LOT of work, as you'd have to ensure that your filesystem had all the data (i.e. inode blocks, cylinder groups, etc) associated with each file, on the same drive as the file, and that the file would basically have to fit on the drive (this is assuming you don't want to write a new filesystem). What is more reasonable (IMHO) is doing what a LOT of people running news servers do, and run RAID 0+1, and making the case when one of the drives in the stripe fails more resilient. This way, if a drive fails in one of the stripes, CCD will fall over to the other stipe in the mirror and ignore the failed one. If you lose two drives, one from each stripe, in quick succession, you are still screwed. What is means is you didn't replace the first drive and rebuild the other stripe fast enough :) Actually, we need to be able to rebuild a mirror on the fly to, IMHO. Hot swap external chassis allow you to replace a drive quickly, and without much (if any) notice to the OS, especially if it is leaving that chain alone because of failure. Then being forced to unmount the (working) stripe to do the dd over to the one that failed seems stupid. I know for a fact that NT allows you to access a mirror while it's being built, and I don't see any reason why FreeBSD can't do the same :-) > As it stands now, you simply decrease your file system's > fault-tolerance by a factor of the number of drives you have, and > that sucks. I've already lost the ccd fs at current.freebsd.org > once due to a drive crash, and it sure would be nice indeed to be > able to: a) tell ccd to stop using a drive, b) tell ccd to migrate > from a drive, if enough free space on other drives exists, and c) > adopt a new drive. That assumes the kernel has enough state in order to totally migrate off the dead drive. I'd be very surprised if that were true. I'd think the data, if not the metadata, would be sure to be gone. Thats why you have RAID5 (which CCD doesn't do yet) which allows such rebuilds. (BTW, is beast back? You never showed me the audit stuff :-) ) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18340.865926916>