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/bnoneswapsw,dp0 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
Re: pinning down dk? assignment
In article julcud$9sd$1...@serpens.de, Michael van Elst mlel...@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
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 HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: pinning down dk? assignment
mo...@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: mlel...@serpens.de A potential Snark may lurk in every tree.
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
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/bnoneswapsw,dp0 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
Re: pinning down dk? assignment
Martin Husemann mar...@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/bnoneswapsw,dp0 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? pgpFVBkRuC1GZ.pgp Description: PGP signature
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
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.
Re: pinning down dk? assignment
In article 20120723141721.gj4...@trav.math.uni-bonn.de, Edgar Fuß e...@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
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.
Re: pinning down dk? assignment
g...@ir.bbn.com (Greg Troxel) writes: NAME=3Dsb2k5Root/a/ ffs rw,log 1 1 NAME=3Dsb2k5Root/bnoneswapsw,dp0 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: mlel...@serpens.de A potential Snark may lurk in every tree.
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.
Re: pinning down dk? assignment
e...@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: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: pinning down dk? assignment
In article juk971$qpi$1...@serpens.de, Michael van Elst mlel...@serpens.de wrote: e...@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: NAME=raid0a / ffs rw,log 7 1 NAME=raid0b noneswapsw 0 0 NAME=raid0e /varffs rw,log 7 3 NAME=raid0f /usrffs rw,log 7 3 NAME=raid0g /usr/local ffs rw,log 7 3 christos
Re: pinning down dk? assignment
chris...@astron.com (Christos Zoulas) writes: In article juk971$qpi$1...@serpens.de, Michael van Elst mlel...@serpens.de wrote: e...@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). 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. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
