Re: Setting up raid correctly

[Philip Mueller <spectre2%gmx.de@localhost>]

On 25.02.2013 08:25, Martin Husemann wrote:
> On Sun, Feb 24, 2013 at 11:53:52PM +0000, Philip Mueller wrote:
> > A few time ago I used FreeBSD with gmirror and to mount destroyed raid
> > storages in other OS was no problem, cause these raid storages were
> > handled as normal storages.
> I can't parse that (and have no idea how FreeBSD handles this). I assume
> you mean things similar to what some BIOSes call "raid support", which
> would for example make on one of my machiens ld0 attach as "nvraid" and
> phyiscally being identical to wd1 and wd2.
No, it was not hard raid or such thing.
> This, however, is not how raidframe works. It is not restricted to raid 1, so
> there is no natural representations for arbitrary components.
>
> In case of lossage, you still just access it as, e.g., raid0.
>
> You can still access the components, while the raid is not configured, via
> their original device name, but you would not be able to mount or fsck them -
> unless you clearly know what you are doing [and have a good reason to do so,
> which I can't see right now].
If I read it correctly,then is the Result now, that it is not mountable 
after destroying raid. This is the only thing I want to know (but other 
people here said it is possible)
> As stated above, on NetBSD you would just use the configured raid, and it will
> work with some components missing - and do all the magic for you.
>
> However, if you would realy need to, on NetBSD you could create a "run time
> only" wedge, by looking at the gpt output, and then using dkctl to remove
> the raid wedge (this does not change the gpt), and adding a 64 blocks smaller
> one. This is a hack at extended expert level, and certainly not recommended
> procedure.
I don't know how to realize this. Can you give me an example?
> Besides, I would not trust $other_os to be compatible enough at the filesystem
> level, and in case of emergency just boot a setup/rescue CD and safe a
> backup via NFS or whatever.
> Martin