Discussion of general kernel technical issues

Edgar Fuß | 21 Jul 2012 19:12

disklabel problems on 3TB disc

I don't know whether this is a disklabel(8) or disklabel(5) or disklabel(9) problem.

I have a 3TB disk identified by the kernel as:
2794 GB, 259471 cyl, 10 head, 2258 sec, 512 bytes/sect x 5860533168 sectors

However, disklabel(8) says:
bytes/sector: 512
sectors/track: 2258
tracks/cylinder: 10
sectors/cylinder: 22580
cylinders: 259471
total sectors: 1563887884

Trying to enter the correct number of sectors (2258*259471=5858855180)
doesn't change the value.

Trying to create a big partition fails with "value out of range"

Interesting enough:
$ bc
obase=16
5858855180-1563887884
100000000

I can't be the first one trying to create large partitions on a recent disc, can I?
What do I do? I need one large partition to create a RAID accross five such discs.

This is on a rather recent 6.0_BETA2/amd64 in case it matters.

(Continue reading)

headers

Brian Buhrow | 21 Jul 2012 20:32

Re: disklabel problems on 3TB disc

	hello. You can put a wedge on the disk or put the raid on the raw disk
itself.
-Brian

On Jul 21,  7:12pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: disklabel problems on 3TB disc
} I don't know whether this is a disklabel(8) or disklabel(5) or disklabel(9) problem.
} 
} I have a 3TB disk identified by the kernel as:
} 2794 GB, 259471 cyl, 10 head, 2258 sec, 512 bytes/sect x 5860533168 sectors
} 
} However, disklabel(8) says:
} bytes/sector: 512
} sectors/track: 2258
} tracks/cylinder: 10
} sectors/cylinder: 22580
} cylinders: 259471
} total sectors: 1563887884
} 
} Trying to enter the correct number of sectors (2258*259471=5858855180)
} doesn't change the value.
} 
} Trying to create a big partition fails with "value out of range"
} 
} Interesting enough:
} $ bc
} obase=16
} 5858855180-1563887884
} 100000000
}

(Continue reading)

headers

Mouse | 21 Jul 2012 20:53

Re: disklabel problems on 3TB disc

> hello.  You can put a wedge on the disk or put the raid on the raw
> disk itself.

Can you RAID the raw disk?  I thought you had to use partitions of type
RAID for that, which RAW_PART isn't.  Am I just confused?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

Brian Buhrow | 21 Jul 2012 21:32

Re: disklabel problems on 3TB disc

	hello.  -current has the ability to raid raw disks.  Here is the patch
for NetBSD-5, and I think -6 as well, to do the same.
-Brian

Index: rf_netbsdkintf.c
===================================================================
RCS file: /cvsroot/src/sys/dev/raidframe/rf_netbsdkintf.c,v
retrieving revision 1.295
retrieving revision 1.296
diff -u -r1.295 -r1.296
--- rf_netbsdkintf.c	5 Nov 2011 16:40:35 -0000	1.295
+++ rf_netbsdkintf.c	16 Feb 2012 06:52:03 -0000	1.296
 <at>  <at>  -2992,7 +2992,7  <at>  <at> 
 	device_t dv;
 	deviter_t di;
 	dev_t dev;
-	int bmajor, bminor, wedge;
+	int bmajor, bminor, wedge, rf_part_found;
 	int error;
 	int i;
 	RF_AutoConfig_t *ac_list;
 <at>  <at>  -3039,6 +3039,8  <at>  <at> 
 		/* need to find the device_name_to_block_device_major stuff */
 		bmajor = devsw_name2blk(device_xname(dv), NULL, 0);

+		rf_part_found = 0; /*No raid partition as yet*/
+
 		/* get a vnode for the raw partition of this disk */

 		wedge = device_is_a(dv, "dk");

(Continue reading)

headers

Brian Buhrow | 21 Jul 2012 21:38

Re: disklabel problems on 3TB disc

	hello.  Let me clarify a bit.  You could always have raid sets on raw
partitions.  What you couldn't do and what the patch does is allow you to
have autoconfiguring raid sets on the raw partition of component disks.
-Brian

headers

Edgar Fuß | 21 Jul 2012 23:59

RAID on raw partitions (was: disklabel problems on 3TB disc)

> You could always have raid sets on raw partitions.
Please allow me to be confused.
I thought I just learned from Greg Oster on May 11 (in
<20120511113355.38f88d58 <at> mickey.usask.ca>) that I couldn't have raw
partitions als RAIDframe components.

headers

Mouse | 22 Jul 2012 06:52

Re: RAID on raw partitions (was: disklabel problems on 3TB disc)

>> You could always have raid sets on raw partitions.

> I thought I just learned from Greg Oster on May 11 (in
> <20120511113355.38f88d58 <at> mickey.usask.ca>) that I couldn't have raw
> partitions als RAIDframe components.

There are two meanings of `raw' as applied to disk partitions.

There's `raw' as in the message you mention, which is (eg) /dev/rsd0a
instead of /dev/sd0a.  This is `raw' in that I/O goes more directly to
the disk.  In this sense, you cannot use raw partitions as RAIDframe
members.

And there's `raw' as in RAW_PART, which is (eg) /dev/sd0d instead of
some other /dev/sd0? (on x86; on most other ports, /dev/sd0c).  This is
`raw' in that it bypasses partitioning, allowing access to the whole
disk regardless of partitioning.  In this sense, you can use raw
partitions as RAIDframe members, provided you don't autoconfigure, or
provided you apply the patch that appeared upthread (or a suitable
porting of it if you're not using the version the patch is for).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

Edgar Fuß | 22 Jul 2012 12:58

full-disc partition (was: RAID on raw partitions)

> There are two meanings of `raw' as applied to disk partitions.
Ah, I see. Thanks.

> This is `raw' in that it bypasses partitioning
> allowing access to the whole disk regardless of partitioning.
It looks that I remember incorrectly what ws <at>  taught me back in the days
how the ``full disc'' partition works.
What I remember is that (let's assume sparc) partition ``c'' was actually
present in the disklabel and it was just by convention that one would
allocate that 0-$. The only magic I thought there was is that in case
the kernel can't find a disklabel, it would invent one having a single
``c'' partition spanning the whole disc. But then, due to the 32-bit-
limitation of the disklabel structure, it couldn't make a ``c'' partition
spanning 3TB.

Is my memory wrong? Has that been changed?

headers

Edgar Fuß | 22 Jul 2012 16:17

Re: full-disc partition

So to correct myself:

> It looks that I remember incorrectly what ws <at>  taught me back in the days
> how the ``full disc'' partition works.
I just called him on the phone and the correct answer is that the code reading
the disklabel enforces the ``full disc'' partition to be the full disc.
Also that code seems to be able to return values >2^32 although the disklabel
itself cannot store them.

headers

Edgar Fuß | 24 Jul 2012 14:37

total sector size in disklabel != the size of raid (was: full-disc partition)

> Also that code seems to be able to return values >2^32 although the disklabel 
> itself cannot store them.
Unfortunately, despite my personal Unix and NetBSD guru saying so, it seems 
not to be true.

First, using the ``full disk'' devices as RAIDframe components doesn't work, 
the component size is truncated to the modulo-2^32 size.

Second, after using wedges as components, the disklabel of the RAID set 
truncates the size modulo 2^32:

/netbsd: raid1: WARNING: raid1: total sector size in disklabel (1962654720) != the size of raid (23437491200)

Could this warning be disabled (or phrased differently) at least for the 
special case where the RAID size is larger than the disklabel size by an 
exact multiple of 2^32?
I suspect people could be needlesly upset by that warning.

headers

matthew green | 24 Jul 2012 20:13

re: total sector size in disklabel != the size of raid (was: full-disc partition)


disklabel has a 2TB limit.  that's true on all netbsd platforms.

to partition disks (real or otherwise) greater than 2TB you'll need
to use gpt(8) style partitions.

.mrg.

headers

Edgar Fuß | 24 Jul 2012 21:05

Re: total sector size in disklabel != the size of raid

> disklabel has a 2TB limit.  that's true on all netbsd platforms.
I know.

> to partition disks (real or otherwise) greater than 2TB you'll need
> to use gpt(8) style partitions.
I know.

I don't have a disklabel on the components. I do have GPTs on them.
I don't have a disklabel on the RAID set.

Nevertheless I get that warning.
Or does the warning disappear as soon as I have a GPT on the RAID 
(atm, I have neither an MBR nor a disklabel nor a GPT on it)?

headers

Edgar Fuß | 27 Jul 2012 13:39

Re: total sector size in disklabel != the size of raid

> Or does the warning disappear as soon as I have a GPT on the RAID 
> (atm, I have neither an MBR nor a disklabel nor a GPT on it)?
No, it doesn't.

I dont't know whether I have made myself sufficiently clear: What annoys me 
is that I get a warning I can't do anything about and despite having done 
everything as intended (GPTs/wedges on the RAID component and the RAID itself).

I don't like to get "oh, these are normal" type warnings.

headers

Michael van Elst | 24 Jul 2012 21:29

Re: total sector size in disklabel != the size of raid (was: full-disc partition)

ef <at> math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:

>First, using the ``full disk'' devices as RAIDframe components doesn't work, 
>the component size is truncated to the modulo-2^32 size.

That's because "full disk" is just a partition in the disklabel that
spans the full disk as much as disklabel is capable.

>Second, after using wedges as components, the disklabel of the RAID set 
>truncates the size modulo 2^32:

Again, disklabel is limited to 2^32. You need wedges here.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

headers

Mouse | 24 Jul 2012 22:20

Re: total sector size in disklabel != the size of raid (was: full-disc partition)

>> First, using the ``full disk'' devices as RAIDframe components
>> doesn't work, the component size is truncated to the modulo-2^32
>> size.
> That's because "full disk" is just a partition in the disklabel that
> spans the full disk as much as disklabel is capable.

Perhaps are far as the "get size" interface raidframe uses is
concerned.  But it's not _just_ that; see my note upthread about how
the disk drivers treat RAW_PART.  And _nothing_ can be "just a
partition in the disklabel" when there isn't any disklabel.

Note also that using RAW_PART as raidframe members, for some kinds of
RAID and some kinds of label, runs the risk of the RAID pseudo-disk's
label being mistaken for the component disk's label.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

Michael van Elst | 24 Jul 2012 22:31

Re: total sector size in disklabel != the size of raid (was: full-disc partition)

mouse <at> Rodents-Montreal.ORG (Mouse) writes:

>Perhaps are far as the "get size" interface raidframe uses is
>concerned.  But it's not _just_ that; see my note upthread about how
>the disk drivers treat RAW_PART.  And _nothing_ can be "just a
>partition in the disklabel" when there isn't any disklabel.

I'm not talking about disklabel(5) but about disklabel(9). Every disk
has one, even where there are not valid bits on the disk.

>Note also that using RAW_PART as raidframe members, for some kinds of
>RAID and some kinds of label, runs the risk of the RAID pseudo-disk's
>label being mistaken for the component disk's label.

Shouldn't happen as both have different positions.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

headers

Mouse | 22 Jul 2012 23:24

Re: full-disc partition (was: RAID on raw partitions)

>> This is `raw' in that it bypasses partitioning allowing access to
>> the whole disk regardless of partitioning.

> It looks that I remember incorrectly what ws <at>  taught me back in the
> days how the ``full disc'' partition works.

> What I remember is that (let's assume sparc) partition ``c'' was
> actually present in the disklabel and it was just by convention that
> one would allocate that 0-$.  The only magic I thought there was is
> that in case the kernel can't find a disklabel, it would invent one
> having a single ``c'' partition spanning the whole disc.

Perhaps that's how it was back in the day.  But now, looking at, for
example, sd.c, I see code that actually does bypass partitioning when
using RAW_PART.  For example,

        if (SDPART(bp->b_dev) == RAW_PART) {
                if (bounds_check_with_mediasize(bp, DEV_BSIZE,
                    sd->params.disksize512) <= 0)
                        goto done;
        } else {
                if (bounds_check_with_label(&sd->sc_dk, bp,
                    (sd->flags & (SDF_WLABEL|SDF_LABELLING)) != 0) <=
                    0)
                        goto done;
        }

(Using RAW_PART also affects various other things; for example, using
RAW_PART prevents the driver from loading the disklabel off the drive
the way it does for other partitions.)

(Continue reading)

headers

Greg Oster | 22 Jul 2012 07:02

Re: RAID on raw partitions (was: disklabel problems on 3TB disc)

On Sat, 21 Jul 2012 23:59:19 +0200
Edgar Fuß <ef <at> math.uni-bonn.de> wrote:

> > You could always have raid sets on raw partitions.
> Please allow me to be confused.
> I thought I just learned from Greg Oster on May 11 (in
> <20120511113355.38f88d58 <at> mickey.usask.ca>) that I couldn't have raw
> partitions als RAIDframe components.

The discussion there was whether you could use /dev/rwd0e or /dev/wd0e
as components.  The discussion here is whether /dev/wd0d (for
i386/amd64, for example) can be used directly and without needing a
disklabel.  That is, in the first instance we are talking the
difference between 'raw and cooked' (really, 'character and block') and
in this second instance a 'raw drive' is one that doesn't have a
disklabel (and uses the entire disk).

Hopefully that clears up the confusion a bit :)

Later...

Greg Oster

headers

Dima Veselov | 22 Jul 2012 08:39

Re: RAID on raw partitions (was: disklabel problems on 3TB disc)

Hello,

I have similar problem, recently discussed in netbsd-help.

I've read all the thread and had some experiments on 
working 6.0_BETA2/amd64 box. 

Initially task was: Make RAID1 set on 2 3TB disks. 

But I still have no luck:

wd2: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors

1) dk2 device over raid device over dk0/dk1 doesn't work. I also
beleive this setup won't autoconfig properly.

[root <at> crux ~]$ dkctl raid7 addwedge storage3 128 5860532703 4.2BSD
dk2 created successfully.
[root <at> crux ~]$ newfs -b64k -O2 /dev/rdk2 
newfs: /dev/rdk2 partition type is not `4.2BSD'

2) newfs over raid device over dk0/dk1 doesn't work either
[root <at> crux ~]$ newfs -b64k -O2 /dev/rraid7d 
/dev/rraid7d: 764436.3MB (1565565568 sectors) block size 65536

3) raid device over /dev/wd* give me 2TB RAID
[root <at> crux ~]$ gpt show raid7
       start        size  index  contents
           0           1         PMBR
           1  4294967167

(Continue reading)

headers

Edgar Fuß | 22 Jul 2012 00:03

Re: disklabel problems on 3TB disc

> or put the raid on the raw disk itself.
I'm not sure what you mean by that. If the disc is sd2, what string do I put
in the RAIDframe ``START disks'' section? You can't mean ``rsd0c'' because
a) I can't have raw partitions as RAIDframe components, can I? and
b) the kernel mis-computes rsd0c's size, doesn't it?

And how do I limit the number of sectors RAIDframe uses (so I can replace
a failed disc by a slightly smaller one)?

headers

John Nemeth | 22 Jul 2012 04:04

Re: disklabel problems on 3TB disc

On Dec 11,  6:39pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
}
} > or put the raid on the raw disk itself.
} I'm not sure what you mean by that. If the disc is sd2, what string do I put
} in the RAIDframe ``START disks'' section? You can't mean ``rsd0c'' because

     rsd0d (assuming SCSI, or rwd0d for non-SCSI) on x86.

} a) I can't have raw partitions as RAIDframe components, can I? and

     According to this thread, yes you can.

} b) the kernel mis-computes rsd0c's size, doesn't it?

     The kernel knows the size of the disk.  It's just that the format
of disklabel(5) doesn't allow for disks larger then 2TB.  Of course,
when disklabel(5) was created, disks were sub-100M, and a disk larger
then 2TB was unimaginably large.

} And how do I limit the number of sectors RAIDframe uses (so I can replace
} a failed disc by a slightly smaller one)?

     Not sure off the top of my head.

}-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=

headers

Brian Buhrow | 22 Jul 2012 04:27

Re: disklabel problems on 3TB disc

	Hello.  Below is a /etc/raid0.conf I use with this configuration.
I've been running this way for at least 2 years.
	As to the question about how to replace a failed component with a
slightly smaller one, the answeris you don't.  If you use 3TB disks as your
raid components, you'd better  have 3TB disks as replacements.
	If you  don't want to use the entire disk, then use gpt(8) partitions
on the disks, and build the raid set in the gpt partitions.  In that case,
the devices would look like:
/dev/dk0
/dev/dk1
/dev/dk2
etc.
(This is for the components of the raid set, in raidx.conf, in case that
isn't clear.)
	Then, build another gpt partition on the raid set itself, and it will
be yet another /dev/dk device.

Hope that helps.
-Brian

#Raid Configuration File for fserv1.via.net (BB 4/12/2006)
#Brian Buhrow
#Describe the size of the array, including spares
START array
#numrow numcol numspare
1 8 1

#Disk section
#Stripe across two twa(4) cards.
START disks

(Continue reading)

headers

Edgar Fuß | 22 Jul 2012 13:01

Re: disklabel problems on 3TB disc

> 	As to the question about how to replace a failed component with a
> slightly smaller one, the answeris you don't.  If you use 3TB disks as your
> raid components, you'd better  have 3TB disks as replacements.
Yes, but for what precise value of ``3TB''?
The ones I presently have are 5860533168 sectors. What if the replacement
I get in three years time have only 5860533160 sectors?

The normal way to handle this is to allocate slightly less than the full
capacity to the partition used as a RAID component.

headers

Edgar Fuß | 23 Jul 2012 12:37

Re: disklabel problems on 3TB disc

> You can put a wedge on the disk
That seems to work. At least with manually created (dkctl addwedge) wedges.

> or put the raid on the raw disk itself.
That doesn't work. It truncates the component capacity to the truncated
value in the disklabel.

I even tried to create (raidctl -C) the set with wedges, initialize it (-I),
then unconfigure it (-u), change the components to the full-disc partitions
in the config file and re-configure (-c) it. It came up with full capacity
with the wedges and truncated with the full-discs.

Looks like I have to put GPTs on the component discs.

headers

Mouse | 23 Jul 2012 18:32

Re: disklabel problems on 3TB disc

>> or put the raid on the raw disk itself.
> That doesn't work.  It truncates the component capacity to the
> truncated value in the disklabel.

That could easily just be a code bug.

Back some years ago, I had occasion to (for work) set up a RAID of
something like six or seven TB.  The individual drives were well under
the 2T limit, but even so I had some 32-bit bugs to fix.  It's possible
there's another one in the code path that passes the raw disk size to
the raidframe code.

Of course, it also might not be, too; I haven't looked.  I mention it
mostly to say "don't just give up on it"...well, unless for your
purposes custom bugfixes aren't acceptable, or finding them isn't going
to happen, or some such.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

matthew green | 23 Jul 2012 19:42

re: disklabel problems on 3TB disc


> That could easily just be a code bug.
> 
> Back some years ago, I had occasion to (for work) set up a RAID of
> something like six or seven TB.  The individual drives were well under
> the 2T limit, but even so I had some 32-bit bugs to fix.  It's possible
> there's another one in the code path that passes the raw disk size to
> the raidframe code.

support for >2TB raidframe was not implemented until this comment:

date: 2010/11/01 02:35:25;  author: mrg;  state: Exp;  lines: +19 -21
add support for >2TB raid devices.

which was later pulled upto netbsd-5.  before this, you could not
create or use rf devices larger than 2TB, regardless of the size of
the individual components.  there were on-disk 32 bit values for
disk blocks, that needed to be extended.  (and then we found that
what should have been 'zero' on disk for these blocks was infact
not zero in some small number of cases.)

.mrg.

headers

Mouse | 23 Jul 2012 23:29

Re: disklabel problems on 3TB disc

>> Back some years ago, I had occasion to (for work) set up a RAID of
>> something like six or seven TB.  The individual drives were well
>> under the 2T limit, but even so I had some 32-bit bugs to fix.

> support for >2TB raidframe was not implemented until this comment:

> date: 2010/11/01 02:35:25;  author: mrg;  state: Exp;  lines: +19 -21
> add support for >2TB raid devices.

> which was later pulled upto netbsd-5.  before this, you could not
> create or use rf devices larger than 2TB, regardless of the size of
> the individual components.

Perhaps not, but it was pretty close.  It took only a few fixes.

I did the first version of this under 2.x, but I no longer have that
tree (or, if I do, I don't know where).  Looking at my 4.0.1 tree, I
see only these changesets touching sys/dev/raidframe:

* aec5aaa Bugfix: when clearing diskwatch on a raid `disk', use the correct value for `none set'.
* 096b537 Add diskwatch support to raidframe pseudo-disks.
* 5ba6878 Autoconfiguration rework in raidframe.
* 4d7b7d3 A few >32-bit fixes in raidframe.
* 6174918 Handle shutdown during reconstruction/rebuild better.
* 20a3038 Import newer raidframe code.

The first two are not relevant to this discussion; they're entirely
diskwatch-related.  Taking the other four in chronological order,

* 20a3038 Import newer raidframe code.

(Continue reading)

headers

matthew green | 24 Jul 2012 04:36

re: disklabel problems on 3TB disc


> It's possible there were other fixes required elsewhere in the tree,
> but I don't think so.

ah, i see.  there are a few other changes that you might want to
pick up, though i see that the majority of my changes were to make
it handle >2TB components, though the component label should also
have total raid size i thought, in the __partitionSize and
partitionSizeHi of the current sources.   oh, i see.  the check
is only <=.  see rf_component_label_partitionsize() in current.

(there are also patches you may want to back port to handle
disks that aren't 512 byte block.)

.mrg.

headers

Roland C. Dowdeswell | 21 Jul 2012 19:43

Re: disklabel problems on 3TB disc

On Sat, Jul 21, 2012 at 07:12:15PM +0200, Edgar Fuß wrote:
>

> I don't know whether this is a disklabel(8) or disklabel(5) or
> disklabel(9) problem.

You have to use gpt(8) for disks which have more than 2^32 sectors,
I think, as the disklabel format does not allow them.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/

headers

Edgar Fuß | 23 Jul 2012 16:17

pinning down dk? assignment

Can I somehow pin down which dk? gets assigned to which GPT partition?

In a disklabel world, I have components sd2a..sd6a making raid1.
I then have raid1a mounted on /export/home and raid1e on /export/mail.

In a GPT/wedge word, I have dk0..dk4 (on sd2..sd6) making raid1.
I then have dk5 and dk6 on raid1 mounted on /export/home resp. /export/mail.

Now suppose the machine comes up with sd6 failing to attach.
At that time, I have dk0..dk3, which (plus an absent dk4) will build raid1.
I then get dk4 and dk5 on raid1 and the mail fs mounted on /export/home.

headers

Martin Husemann | 23 Jul 2012 16:21

Re: pinning down dk? assignment

On Mon, Jul 23, 2012 at 04:17:21PM +0200, Edgar Fuß wrote:
> Can I somehow pin down which dk? gets assigned to which GPT partition?

You can mount them by name. I have (on my non-GPT root disk):

NAME=sb2k5Root/a        /       ffs     rw,log           1 1
NAME=sb2k5Root/b        none    swap    sw,dp            0 0

in /etc/fstab. With gpt you can label the partitions with arbitrary names
(instead of the disklabel volume name/partition that I use above).

Martin

headers

Greg Troxel | 23 Jul 2012 16:24

Re: pinning down dk? assignment


Martin Husemann <martin <at> duskware.de> writes:

> On Mon, Jul 23, 2012 at 04:17:21PM +0200, Edgar Fuß wrote:
>> Can I somehow pin down which dk? gets assigned to which GPT partition?
>
> You can mount them by name. I have (on my non-GPT root disk):
>
> NAME=sb2k5Root/a        /       ffs     rw,log           1 1
> NAME=sb2k5Root/b        none    swap    sw,dp            0 0
>
> in /etc/fstab. With gpt you can label the partitions with arbitrary names
> (instead of the disklabel volume name/partition that I use above).

Thanks - I had no idea.  This seems to be missing from the
documentation.  Is it new?

headers

Martin Husemann | 23 Jul 2012 16:29

Re: pinning down dk? assignment

On Mon, Jul 23, 2012 at 10:24:38AM -0400, Greg Troxel wrote:
> Thanks - I had no idea.  This seems to be missing from the
> documentation.  Is it new?

You can find it in fstab(5), but I guess a few hints in wedge related
man pages would not hurt. It is not very new, -6 should have it as well.

Martin

headers

Edgar Fuß | 23 Jul 2012 16:38

Re: pinning down dk? assignment

> You can find it in fstab(5)
Not in 6.0_BETA.

> It is not very new, -6 should have it as well.
Does it? the only special handling of fs_spec I could find in
sbin/mount/mount.c was ``from_mount'', whatever that is.

headers

Michael van Elst | 23 Jul 2012 20:34

Re: pinning down dk? assignment

gdt <at> ir.bbn.com (Greg Troxel) writes:

>> NAME=3Dsb2k5Root/a        /       ffs     rw,log           1 1
>> NAME=3Dsb2k5Root/b        none    swap    sw,dp            0 0
>>
>> in /etc/fstab. With gpt you can label the partitions with arbitrary names
>> (instead of the disklabel volume name/partition that I use above).

>Thanks - I had no idea.  This seems to be missing from the
>documentation.  Is it new?

It's new and a pure userland feature that looks up wedge paths. It probably
won't help you with raidframe.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

headers

Edgar Fuß | 23 Jul 2012 21:14

Re: pinning down dk? assignment

> It probably won't help you with raidframe.
It would indeed help in my case. In case sd6 has gone missing, so dk4 is on the RAID and not on sd6, it would
prevent the wrong filesystem being mounted for dk5.

headers

Michael van Elst | 23 Jul 2012 21:38

Re: pinning down dk? assignment

ef <at> math.uni-bonn.de (=?iso-8859-1?Q?Edgar_Fu=DF?=) writes:

>> It probably won't help you with raidframe.
>It would indeed help in my case. In case sd6 has gone missing, so dk4 is on the RAID and not on sd6, it would
prevent the wrong filesystem being mounted for dk5.

I was refering to the situation with building a raid on wedge components.
Wedges on top of raid are no problem.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

headers

Christos Zoulas | 24 Jul 2012 04:43

Re: pinning down dk? assignment

In article <juk971$qpi$1 <at> serpens.de>,
Michael van Elst <mlelstv <at> serpens.de> wrote:
>ef <at> math.uni-bonn.de (=?iso-8859-1?Q?Edgar_Fu=DF?=) writes:
>
>>> It probably won't help you with raidframe.
>>It would indeed help in my case. In case sd6 has gone missing, so dk4
>is on the RAID and not on sd6, it would prevent the wrong filesystem
>being mounted for dk5.
>
>I was refering to the situation with building a raid on wedge components.
>Wedges on top of raid are no problem.

Actually I do exactly that (raid on top of wedges)

dk0 at wd0: wd0a
dk0: 488397105 blocks at 63, type: raidframe
dk1 at wd1: wd1a
dk1: 488397105 blocks at 63, type: raidframe
dk2 at sd0: sd0a
dk2: 117210177 blocks at 63, type: ffs
Component on: dk0: 488397105
Component on: dk1: 488397105
Found: dk1 at 0
Found: dk1 at 0
Found(low mod_counter): dk0 at 1
raid0: Components: /dev/dk1 /dev/dk0[**FAILED**]

Ignore the failed dk here, this is because of the bad ata code in current.
In fstab I have:

(Continue reading)

headers

Michael van Elst | 24 Jul 2012 07:47

Re: pinning down dk? assignment

christos <at> astron.com (Christos Zoulas) writes:

>In article <juk971$qpi$1 <at> serpens.de>,
>Michael van Elst <mlelstv <at> serpens.de> wrote:
>>ef <at> math.uni-bonn.de (=?iso-8859-1?Q?Edgar_Fu=DF?=) writes:
>>
>>>> It probably won't help you with raidframe.
>>>It would indeed help in my case. In case sd6 has gone missing, so dk4
>>is on the RAID and not on sd6, it would prevent the wrong filesystem
>>being mounted for dk5.
>>
>>I was refering to the situation with building a raid on wedge components.
>>Wedges on top of raid are no problem.

>Actually I do exactly that (raid on top of wedges)

>dk0 at wd0: wd0a
>dk0: 488397105 blocks at 63, type: raidframe
>dk1 at wd1: wd1a
>dk1: 488397105 blocks at 63, type: raidframe
>dk2 at sd0: sd0a
>dk2: 117210177 blocks at 63, type: ffs
>Component on: dk0: 488397105
>Component on: dk1: 488397105
>Found: dk1 at 0
>Found: dk1 at 0
>Found(low mod_counter): dk0 at 1
>raid0: Components: /dev/dk1 /dev/dk0[**FAILED**]

Let wd1 disappear and the raid will try to use wd0a (dk0) and sd0a (dk1).

(Continue reading)

headers

Christos Zoulas | 24 Jul 2012 15:01

Re: pinning down dk? assignment

In article <julcud$9sd$1 <at> serpens.de>,
Michael van Elst <mlelstv <at> serpens.de> wrote:
>
>Let wd1 disappear and the raid will try to use wd0a (dk0) and sd0a (dk1).
>Of course raidframe will notice the mismatch in this case, but you can
>easily imagine more complex scenarios where it doesn't. But a simple
>failure case comes from trying to recover the failed wd1 without
>rebooting. When you replace the drive it may attach as wd1 but then
>as dk2. Now try to teach raidrame that its component changed the path.

That works too because the components are not signed. Actually this
is the exact failure I got because wd0 was not found because of the
latest ata changes!

christos

headers

Mouse | 24 Jul 2012 17:36

Re: pinning down dk? assignment

> Let wd1 disappear and the raid will try to use wd0a (dk0) and sd0a
> (dk1).

This is one reason to use autoconfigured RAIDs when you can.  They are
far more immune (completely immune, in my experience) to confusion from
disks attaching in new orders or at new places.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

headers

Michael van Elst | 24 Jul 2012 21:31

Re: pinning down dk? assignment

mouse <at> Rodents-Montreal.ORG (Mouse) writes:

>This is one reason to use autoconfigured RAIDs when you can.  They are
>far more immune (completely immune, in my experience) to confusion from
>disks attaching in new orders or at new places.

True, but raid autoconfig is only done at boot time.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."

headers

Mouse | 24 Jul 2012 22:22

Re: pinning down dk? assignment

>> This is one reason to use autoconfigured RAIDs when you can.  They
>> are far more immune (completely immune, in my experience) to
>> confusion from disks attaching in new orders or at new places.
> True, but raid autoconfig is only done at boot time.

Also true.  Perhaps there should be some kind of "trigger a pass of
raidframe autoconfig" operation?  Or perhaps some userland equivalent
which scans sysctl.disknames for possible RAID members?

					Mouse

headers

Thomas Klausner | 12 Aug 2012 19:13

Re: pinning down dk? assignment

On Mon, Jul 23, 2012 at 04:21:55PM +0200, Martin Husemann wrote:
> You can mount them by name. I have (on my non-GPT root disk):
> 
> NAME=sb2k5Root/a        /       ffs     rw,log           1 1
> NAME=sb2k5Root/b        none    swap    sw,dp            0 0
> 
> in /etc/fstab. With gpt you can label the partitions with arbitrary names
> (instead of the disklabel volume name/partition that I use above).

Thanks for the example. I've added it to fstab(5), together with an example for gpt-disks.
 Thomas

headers

Christos Zoulas | 23 Jul 2012 18:06

Re: pinning down dk? assignment

In article <20120723141721.GJ4646 <at> trav.math.uni-bonn.de>,
Edgar Fuß  <ef <at> math.uni-bonn.de> wrote:
>Can I somehow pin down which dk? gets assigned to which GPT partition?
>
>In a disklabel world, I have components sd2a..sd6a making raid1.
>I then have raid1a mounted on /export/home and raid1e on /export/mail.
>
>In a GPT/wedge word, I have dk0..dk4 (on sd2..sd6) making raid1.
>I then have dk5 and dk6 on raid1 mounted on /export/home resp. /export/mail.
>
>Now suppose the machine comes up with sd6 failing to attach.
>At that time, I have dk0..dk3, which (plus an absent dk4) will build raid1.
>I then get dk4 and dk5 on raid1 and the mail fs mounted on /export/home.

Use NAME=guid or NAME=underlying-device-name instead of /dev/dkX for the
fs_spec field.

christos

headers

Edgar Fuß | 23 Jul 2012 18:13

Re: pinning down dk? assignment

> Use NAME=guid or NAME=underlying-device-name instead of /dev/dkX for the
> fs_spec field.
Yes, but someone would have to pull-up that to 6.0.
6.0 has src/bin/mount/mount.c 1.94 and NAME= was introduced in 1.95.