Re: kern/45179: NetBSD disklabel does not support devices larger 2 TByte

[Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>]

Hi, again ...

Now I've played a little bit around with gpt and dkctl ....

First impression: complicate, not intentive and very fault intensive


OK. by adding a GPT label to the "raw" disk (e.g. sd6) the avaliable 
size shrinks.
Bad - because a migration of existing setups is impossible ....
But for new setups that is OK.

I now can setup two "scsi" disks - in real two SATA disks on two mfi 
controlers - and setup a RAID1 device of them.
(To get better fault security you should not setup two disks on the same 
HW-controler as a RAID1 device ... If the controler gets into trouble 
you loose the filesystem.)
I can do this again with other pairs of disks.
remark: now I've already used 2 * number of raiddevices dk(4) devices ...
Next I need to setup a GPT label on all created raid devices.
remark: additional number of raiddevices dk(4) nodes used

Then I create a RAID0 device of the dk(4) devices build in the previous 
step.
I need another dk(4) device node for the main partition on that device then.

OK setting up this all by hand works fine.
newfs is still running ...

But what about autoconfigure code?

I've send a patch (a long time ago for 4.x (PR39784) in 2008) for the 
autoconfig stuff of raidframe that enables raidframe of setup layered 
deviced (used in the setup here) during autoconfig.
At least in 5.1 it is still not in, but otherwise no change to setup 
layered devices in autoconfig in a relyable manner.

But does the autoconfig code setup the correct dk(4) devices after each 
raidframe configuration?
A reboot ends up in a desaster !


The wedge on sd6 has now type NetBSD UFS/UFS2 ???
It was setup as RAID before and was reported as RAIDframe wedge.
So the raid device based on this partition has not been setup, resulting 
in RAID0 setup of the layered device to fail too, because the components 
has not been setup correctly.

Any Idea what might have happend to the wedge information?

best regards

W. Stukenbrock

But neverless the endless number of intermediate df(4) devices just for 
building the raid abstractions is a pain!



Wolfgang Stukenbrock wrote:

> The following reply was made to PR kern/45179; it has been noted by GNATS.
>
> From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
> netbsd-bugs%NetBSD.org@localhost,
>         Wolfgang.Stukenbrock%nagler-company.com@localhost
> Subject: Re: kern/45179: NetBSD disklabel does not support devices larger 2 
> TByte
> Date: Wed, 27 Jul 2011 14:21:36 +0200
>
>  Hi,
>  
>  OK. If it is possible to boot from that, it would be fine for my current 
>  needs.
>  The Windows-problem does not hurt me - at least for the systems where I 
>  need this.
>  
>  Is it planned to extend the boot code to boot from a RAID1 setup in gpt 
>  in the near future?
>  
>  At the moment I think this PR can be closed as soon as the bootsupport 
>  for raid1 partitions is added to gpt.
>  I need this in 5.x as soon as possible for new "productive" systems, but 
>  I can do the integration from current into "my" 5.x-version by myself if 
>  it is inserted only for 6.x or later. Accedently I've no time to figure 
>  out all required changes myself
>  
>  best regards
>  
>  W. Stukenbrock
>  
>  Martin Husemann wrote:
>  
>  > The following reply was made to PR kern/45179; it has been noted by GNATS.
>  > 
>  > From: Martin Husemann <martin%duskware.de@localhost>
>  > To: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
>  > Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%NetBSD.org@localhost,
>  >   gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
>  > Subject: Re: kern/45179: NetBSD disklabel does not support devices larger 2 
> TByte
>  > Date: Wed, 27 Jul 2011 12:12:06 +0200
>  > 
>  >  On Wed, Jul 27, 2011 at 11:57:14AM +0200, Wolfgang Stukenbrock wrote:
>  >  > This means, gpt(8) is not usable on (at least) i386 and amd64 
>  >  > architectures for root disks!
>  >  
>  >  No, that is not true. I recently booted a amd64 machine from a gpt labeld
>  >  disk. Firmware in all "recent" machines does handle it just fine.
>  >  
>  >  Martin
>  >  
>  > 
>  > 
>  > 
>  
>  
>  -- 
>  
>  
>  Dr. Nagler & Company GmbH
>  Hauptstraße 9
>  92253 Schnaittenbach
>  
>  Tel. +49 9622/71 97-42
>  Fax +49 9622/71 97-50
>  
>  Wolfgang.Stukenbrock%nagler-company.com@localhost
>  http://www.nagler-company.com
>  
>  
>  Hauptsitz: Schnaittenbach
>  Handelregister: Amberg HRB
>  Gerichtsstand: Amberg
>  Steuernummer: 201/118/51825
>  USt.-ID-Nummer: DE 273143997
>  Geschäftsführer: Dr. Martin Nagler, Dr. Dr. Karl-Kuno Kunze
>  
>  


--


Dr. Nagler & Company GmbH
Hauptstraße 9
92253 Schnaittenbach

Tel. +49 9622/71 97-42
Fax +49 9622/71 97-50

Wolfgang.Stukenbrock%nagler-company.com@localhost
http://www.nagler-company.com


Hauptsitz: Schnaittenbach
Handelregister: Amberg HRB
Gerichtsstand: Amberg
Steuernummer: 201/118/51825
USt.-ID-Nummer: DE 273143997
Geschäftsführer: Dr. Martin Nagler, Dr. Dr. Karl-Kuno Kunze