On Tue, 20 Jul 2004, Peter Jeremy wrote: > It's difficult to see how a sanely written RAID utility could totally > screw up an array in a short time - a 'build' utility presumably > writes known data to the array but logically it would do so > sequentially. The only thing I can think of is that the controller > had a significant amount of cached data - which has been wiped, rather > than written back to the disk.
This is one case where I'd like to see a "Are you sure (y/n)?" prompt. In the future, I'm sticking with the adaptec BIOS to do a drive replace/rebuild. Adaptec's raidutil is just a bit too easy to shoot yourself in the foot with. I have a call in to adaptec about this, they are having a hard time telling me just what the "build" (not "rebuild") command does, but they are fairly certain that it writes it's config at the end of the disk, then zeros it from the outside in. > If you haven't run newfs and have the correct disklabel, the disk > should be in a reasonably sane state. Have you tried running something > like ports/sysutils/scan_ffs over the disk (or your copy of it)? I don't have the actual disk; we're very short on any sort of spare hardware so we had to newfs the partition in question and start over. I grabbed the dd "image" before that. An fsck on the problem partition ran for 12 hours and I don't know how far along it was. I looked at scan_ffs just now, and it looks like it works on the whole disk trying to find the label. Since I only have one partition, there's no label. > Have you tried dumping vn0c? I could try that, but I'd have to find myself another 26GB of space somewhere. Thanks! Charles > -- > Peter Jeremy > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
