Date: Sun, 22 May 2005 00:45:05 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@DeepCore.dk> To: Joe Rhett <jrhett@meer.net> Cc: freebsd-stable@freebsd.org Subject: Re: drive failure during rebuild causes page fault Message-ID: <59083C62-0D00-4042-A9E9-4FC39AE4B538@DeepCore.dk> In-Reply-To: <20050520231050.GA86907@meer.net> References: <20041213054159.GC78120@meer.net> <20041212215841.X83257@carver.gumbysoft.com> <20041213060549.GE78120@meer.net> <20041213102333.V92964@carver.gumbysoft.com> <20041213192119.GB4781@meer.net> <20041213183336.T97507@carver.gumbysoft.com> <41BE8F2D.8000407@DeepCore.dk> <20041215005359.GK27283@meer.net> <20050519002015.GA25329@meer.net> <F1F4AB07-A2C3-4EC9-8D4E-BDE0AF4BA409@DeepCore.dk> <20050520231050.GA86907@meer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/05/2005, at 1:10, Joe Rhett wrote: > > On Thu, May 19, 2005 at 08:21:13AM +0200, S=F8ren Schmidt wrote: > >> On 19/05/2005, at 2.20, Joe Rhett wrote: >> >> >>> Soren, I've just retested all of this with 5.4-REL and most of the >>> problems >>> listed here are solved. The only problems appear to be related to >>> these >>> ghost arrays that appear when it finds a drive that was taken =20 >>> offline >>> earlier. For example, pull a drive and then reboot the system. >>> >> >> This depends heavily on the metadata format used, some of them simply >> doesn't have the info to avoid this and some just ignores the =20 >> problem. >> > .. .. > >> You need to overwrite the metadata (se above) which are located in >> different places again depending on metadata format. >> > > So where is it located with the sil3114 controler? > (same as 3112, but with 4 ports...) Depends on what BIOS you have on there, several exists for the SiI =20 chips, -current or mkIII would tell you which. Just null out the last =20= 63 sectors on the disks and you should be fine since all possible =20 formats are in that range... > Is there anything I can do with userland utilities? > >> ATA mkIII is exactly about getting ata-raid rewritten from the old >> cruft that originally was written before even ATA-ng was done, so yes >> I'd expect it to behave better but not necessarily solve all your >> problems as some of them might be "features" of the metadata >> > > So what do I need to know to determine the problem? The metadata format for one, thats the most important factor for =20 getting this to work, but some of them has no generation or anything =20 so its hard if not impossible to avoid this problem. - S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59083C62-0D00-4042-A9E9-4FC39AE4B538>