Date: Sat, 26 Jun 2004 06:01:10 +0200 From: "Daniel Eriksson" <daniel_k_eriksson@telia.com> To: "'Benjamin P. Keating'" <bkeating@gmail.com>, <freebsd-questions@freebsd.org> Subject: RE: fsck'ing a Vinum RAID5 volume (and a stale drive) Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAqqgjgXD/1kSNFsy0Utn3AwEAAAAA@telia.com> In-Reply-To: <1d54d54404062518474bbb3494@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin P. Keating wrote: > Is > this approach correct? does this do anything productive or just forces > the state label to change and do nothing to the drives? I don't feel > confident that it did anything and Im having a VERY hard time finding > documentation on this. Let me give you an example of a valid setstate use case: One of my servers has a LOT of discs. For some reason I suffer from interrupt storms during device probing (started after I added a second Highpoint RocketRAID 454 to the machine). These storms sometime prevent = the ata code from detecting all the discs. If this happens to be a disc that = is part of a RAID-0 array, then when vinum starts up it detects that one of = the discs have disappeared and (correctly) marks the array as crashed. There = is no "proper" way to recover from a crashed RAID-0 array - your data is normally lost forever. However, in this specific case I _know_ that = nothing has been written to the discs, so once I get the missing disc back = online I can use setstate to change the array status from crashed to up, = confident that no data has actually been lost. There are a few other use cases for setstate, but they are all (?) = outside of the normal procedures for using and maintaining RAID arrays. /Daniel Eriksson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAqqgjgXD/1kSNFsy0Utn3AwEAAAAA>