headers
Edgar Fuß | 25 Jul 2012 18:41
Picon
Favicon

raid1: unable to open device, error = 16

Now this is strange.

I built raid1 on dk0..dk5.

I gpt'd raid1.

I raidctl -u raid1 and raidctl -c /etc/raid1.conf raid1, and the wedges were 
auto-detected as expected (XXXX'd the GUID and GPT names):

raid1: Components: /dev/dk0 /dev/dk1 /dev/dk2 /dev/dk3 /dev/dk4
raid1: Total Sectors: 23437491200 (11444087 MB)
raid1: GPT GUID: XXXX
dk5 at raid1: XXXX
dk5: 12884901888 blocks at 2048, type: ffs
dk6 at raid1: XXXX
dk6: 6442450944 blocks at 12884903936, type: ffs
dk7 at raid1: XXXX
dk7: 1073741824 blocks at 19327354880, type: ffs
dk8 at raid1: XXXX
dk8: 2097152 blocks at 20401096704, type: ffs
dk9 at raid1: XXXX
dk9: 268435456 blocks at 20403193856, type: ffs
dk10 at raid1: XXXX
dk10: 268435456 blocks at 20671629312, type: ffs
dk11 at raid1: XXXX
dk11: 1073741824 blocks at 20940064768, type: ffs

I newfs'd dk5..8.

I then tried gpt show -l raid1, which now said:
(Continue reading)

Permalink | Reply |
headers
Edgar Fuß | 25 Jul 2012 18:58
Picon
Favicon

Re: raid1: unable to open device, error = 16

> I'll try to re-boot.
OK, now the wedges are auto-detected again.

I don't know whether it matters, but while doing the newfs's, my cwd was /dev 
(because I MAKEDEV'd dk8..dk11), so newfs dk? complained "dk? is a block 
device. use raw device" and I used newfs rdk?.

I'll re-do the newfs's and see what happens.

OK, it's reproducible. After newfs dk5, gpt show raid1 doesn't work any more.

Any hints how to debug this?
Permalink | Reply |
headers
Edgar Fuß | 25 Jul 2012 19:34
Picon
Favicon

Re: raid1: unable to open device, error = 16

> OK, it's reproducible. After newfs dk5, gpt show raid1 doesn't work any more.
Another reboot, and it worked again.

The problem seems not to be newfs (or not only), but raidctl.

If I'm inside /dev and raidctl -c /etc/raid1.conf raid1, I get that "unable 
to open device, error = 16". If I do raidctl -c /etc/raid1.conf raid1 outside 
/dev, it works. If I do raidctl -c /etc/raid1.conf rraid1 (note the "r") 
inside /dev, it also works.

So it's probably not as bad as I initially thought, but confusing enough.
Permalink | Reply |
headers
Brian Buhrow | 25 Jul 2012 20:26

Re: raid1: unable to open device, error = 16

	hello.  that's what I rand into as well.  I found that using the full
pathname to the raid.conf file with raidctl caused things to work as
expected.  Doing less caused confusion if I didn't happen to be in the
right working directory.
-Brian

`i

On Jul 25,  7:34pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: Re: raid1: unable to open device, error = 16
} > OK, it's reproducible. After newfs dk5, gpt show raid1 doesn't work any more.
} Another reboot, and it worked again.
} 
} The problem seems not to be newfs (or not only), but raidctl.
} 
} If I'm inside /dev and raidctl -c /etc/raid1.conf raid1, I get that "unable 
} to open device, error = 16". If I do raidctl -c /etc/raid1.conf raid1 outside 
} /dev, it works. If I do raidctl -c /etc/raid1.conf rraid1 (note the "r") 
} inside /dev, it also works.
} 
} So it's probably not as bad as I initially thought, but confusing enough.
>-- End of excerpt from Edgar =?iso-8859-1?B?RnXf?=
Permalink | Reply |
headers
matthew green | 25 Jul 2012 21:22
Picon
Favicon

re: raid1: unable to open device, error = 16


don't run these commands inside /dev.  library functions like
opendisk() will look for a file-path of the given name before
trying other names.  that tends to make them use the block
dev when you want the char dev.  eg, compare the ktrace for
"newfs raid1d" when you are in/not in /dev.

.mrg.
Permalink | Reply |
headers
Alan Barrett | 27 Jul 2012 14:01
Gravatar

Re: raid1: unable to open device, error = 16

On Thu, 26 Jul 2012, matthew green wrote:
>library functions like
>opendisk() will look for a file-path of the given name before
>trying other names.  that tends to make them use the block
>dev when you want the char dev.  eg, compare the ktrace for
>"newfs raid1d" when you are in/not in /dev.

I think that opendisk should do something like this:

    if (path contains a slash) {
        use specified path, do not search in any way
    } else {
        try /dev/[r]foo
        try /dev/[r]fooX, where X is "c" or "d" depending on kern.rawpartition
    }

If the user wants to open a file in the cwd, then let the
user pass "./foo" instead of "foo" to opendisk.

--apb (Alan Barrett)
Permalink | Reply |
headers
Edgar Fuß | 27 Jul 2012 14:05
Picon
Favicon

Re: raid1: unable to open device, error = 16

> I think that opendisk should do something like this:
Yes.
Permalink | Reply |

Gmane