NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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




Home | Main Index | Thread Index | Old Index