* Re: Storage device enumeration script
From: John Robinson @ 2011-05-27 9:15 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <4DDE249C.7080004@anonymous.org.uk>
On 26/05/2011 10:59, John Robinson wrote:
[...]
> [root@beast lsdrv]# python2.6 lsdrv
> PCI [pata_marvell] 03:00.0 IDE interface: Marvell Technology Group Ltd.
> 88SE6121 SATA II Controller (rev b2)
> └─scsi 0:0:0:0 HL-DT-ST DVD-RAM GH22NP20
> └─sr0: Empty/Unknown 1.00g
> PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10
> Family) SATA AHCI Controller
> ├─scsi 2:0:0:0 ATA Hitachi HDS72101
> │ └─sda: Empty/Unknown 931.51g
> Traceback (most recent call last):
> File "lsdrv", line 387, in <module>
> show_blocks(" %s " % branch[0], [phy.block])
> File "lsdrv", line 339, in show_blocks
> show_blocks("%s %s " % (indent, branch[0]), [blockbyname[x] for x in subs])
> KeyError: 'sda1'
>
> Now, something's not getting picked up about sda. Looking at Mathias'
> "sweet" output, it's not coping with the (DOS) partition table. Another
> variation on my kernel's /sys or still to old a Python or ...?
Still seeing this. I added a print command so I can see that
dev.partitions is being populated successfully. I'm not entirely sure
where dev.ID_ etc are supposed to be coming from, but if it's that
`blkid -p -o udev /dev/block/8:0` then I'm afraid CentOS 5's blkid
doesn't understand the -p or -o udev options, it doesn't produce any
output for whole drives with partition tables, and there isn't a
/dev/block directory. It's blkid 1.0.0 from e2fsprogs 1.39-23.el5_5.1.
If that knocks CentOS 5 support on the head then so be it...
Cheers,
John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: Roman Mamedov @ 2011-05-27 3:58 UTC (permalink / raw)
To: Brad Campbell
Cc: lrhorer, 'Phil Turmel', 'Mathias Burén',
linux-raid
In-Reply-To: <4DDEED47.1040809@fnarfbargle.com>
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
On Fri, 27 May 2011 08:16:07 +0800
Brad Campbell <brad@fnarfbargle.com> wrote:
> On 27/05/11 08:13, Leslie Rhorer wrote:
> >>
> > I can't speak to Ubuntu, but Debian evidently does not. I don't
> > know what "pvs" is, but neither bash nor Python recognize it as a file
> > anywhere in the path.
> apt-get install lvm2.
Sure, but lsdrv shouldn't assume lvm2 is installed or require it to be
installed. Not everyone uses LVM, and simply installing it automatically adds
things to initramfs (PV/VG/LV detection?), which can slow down boot-up process.
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Storage device enumeration script
From: Brad Campbell @ 2011-05-27 0:16 UTC (permalink / raw)
To: lrhorer; +Cc: 'Phil Turmel', 'Mathias Burén', linux-raid
In-Reply-To: <42.A9.00666.D9CEEDD4@cdptpa-omtalb.mail.rr.com>
On 27/05/11 08:13, Leslie Rhorer wrote:
>>
> I can't speak to Ubuntu, but Debian evidently does not. I don't
> know what "pvs" is, but neither bash nor Python recognize it as a file
> anywhere in the path.
apt-get install lvm2.
^ permalink raw reply
* RE: Storage device enumeration script
From: Leslie Rhorer @ 2011-05-27 0:13 UTC (permalink / raw)
To: 'Phil Turmel', 'Mathias Burén'; +Cc: linux-raid
In-Reply-To: <4DDE3C73.6010504@turmel.org>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Phil Turmel
> Sent: Thursday, May 26, 2011 6:42 AM
> To: Mathias Burén
> Cc: lrhorer@satx.rr.com; linux-raid@vger.kernel.org
> Subject: Re: Storage device enumeration script
>
> On 05/26/2011 02:16 AM, Mathias Burén wrote:
> > On 26 May 2011 07:14, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
> >>
> >> I get an error right off the bat:
> >>
> >> Traceback (most recent call last):
> >> File "./lsdrv.txt", line 264, in <module>
> >> for x in runx(['pvs', '-o',
> >> 'pv_name,pv_used,pv_size,pv_uuid,vg_name,vg_size,vg_free,vg_uuid',
> >> '--noheadings', '--separator', ' ']).split("\n"):
> >> File "./lsdrv.txt", line 50, in runx
> >> sub = Popen(*args, **kwargs)
> >> File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
> >> errread, errwrite)
> >> File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
> >> raise child_exception
> >> OSError: [Errno 2] No such file or directory
> >>
> >> I'm running Python 2.6.6 and mdadm 3.1.4 running on kernel 2.6.32-5-
> amd64
> >>
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-raid"
> in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >
> > I get that in Ubuntu 11.04 on a laptop as well.
> >
> > /M
>
> Does a plain install of Ubuntu include the LVM utilities? Can you run
> "pvs" directly?
I can't speak to Ubuntu, but Debian evidently does not. I don't
know what "pvs" is, but neither bash nor Python recognize it as a file
anywhere in the path.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Upgrading from metadata 0.9
From: Phillip Susi @ 2011-05-26 19:23 UTC (permalink / raw)
To: linux-raid
Is there a way to upgrade an existing raid array using metadata format
0.9 to a 1.x format without loosing data?
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 19:16 UTC (permalink / raw)
To: CoolCold
Cc: Torbjørn Skagestad, Roman Mamedov, linux-raid, Roman Mamedov,
John Robinson, Mathias Burén
In-Reply-To: <BANLkTimqPRxqF5McHEqSKA5N_Wa=t4vAxw@mail.gmail.com>
On 05/26/2011 02:58 PM, CoolCold wrote:
> I guess we should move off this list, may be continue on github comments.
I enabled the wiki on github for now. At some point I'll create a dev list.
https://github.com/pturmel/lsdrv/wiki
And I've created a issue for the floppy drive problem(s).
Phil
^ permalink raw reply
* Re: Storage device enumeration script
From: CoolCold @ 2011-05-26 18:58 UTC (permalink / raw)
To: Torbjørn Skagestad
Cc: Phil Turmel, Roman Mamedov, linux-raid, Roman Mamedov,
John Robinson, Mathias Burén
In-Reply-To: <1306435355.3684.7.camel@ts-workstation>
I guess we should move off this list, may be continue on github comments.
On Thu, May 26, 2011 at 10:42 PM, Torbjørn Skagestad <torbjorn@itpas.no> wrote:
> Hi,
>
> I'm hitting this as well.It seems to be triggered by my non-existing
> floppy device.
>
> As there is no real floppy device connected, no driver is loaded, so we
> never see a /driver directory. This loop then goes all the way up to /,
> where it loops forever at 100% cpu.
>
>
> from probe_controller()
> 151 while cpath and not os.path.exists(cpath+'/driver'):
> 152 cpath = os.path.dirname(cpath)
> 153 if cpath in controllers:
> 154 return controllers[cpath]
>
>
> On Thu, 2011-05-26 at 14:22 -0400, Phil Turmel wrote:
>> On 05/26/2011 02:12 PM, Roman Mamedov wrote:
>> [...]
>> > Now it locks up with 100% CPU load and no output, I waited for a couple of
>> > minutes. On Ctrl-C:
>> >
>> > ^CTraceback (most recent call last):
>> > File "./lsdrv", line 274, in <module>
>> > probe_block('/sys/block/'+x)
>> >
>> > $ ls /sys/block/
>> > etherd!e1.5 etherd!e2.1 md0 md2 sda sdc sde sdg
>> > etherd!e1.6 fd0 md1 md4 sdb sdd sdf
>> >
>> > The first two devices are actually down at this moment, maybe that's the
>> > reason? Still I'd expect not 100% CPU load by lsdrv, but 0% CPU and 100%
>> > iowait in this case.
>>
>> Sounds like an infinite loop, or infinite recursion. Could you apply the temporary patch below so I can see how far the probing got?
>>
>> > Output of the old (bash) lsdrv:
>> >
>> > Controller device @ pci0000:00/0000:00:06.0 [pata_amd]
>> > IDE interface: nVidia Corporation CK804 IDE (rev f2)
>> > host8: [Empty]
>> > host9: [Empty]
>> > Controller device @ pci0000:00/0000:00:07.0 [sata_nv]
>> > IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
>> > host6: /dev/sdd ATA Hitachi HDS5C302 {SN: ..............}
>> > host7: /dev/sde ATA WDC WD15EADS-00S {SN: ..............}
>> > Controller device @ pci0000:00/0000:00:08.0 [sata_nv]
>> > IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
>> > host10: /dev/sdf ATA WDC WD20EADS-00S {SN: ..............}
>> > host11: /dev/sdg ATA WDC WD20EADS-00S {SN: ..............}
>> > Controller device @ pci0000:00/0000:00:0d.0/0000:02:00.0 [ahci]
>> > SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s
>> > controller (rev 10) host4: /dev/sdc ATA Hitachi HDS5C302 {SN: ..............}
>> > host5: [Empty]
>> > Controller device @ pci0000:00/0000:00:0e.0/0000:01:00.0 [sata_mv]
>> > SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
>> > SATA-II (rev 02) host0: [Empty]
>> > host1: [Empty]
>> > host2: /dev/sda ATA ST31000528AS {SN: ..............}
>> > host3: /dev/sdb ATA Hitachi HDS72202 {SN: ..............}
>>
>> The old code never attempted to recurse into the layers of block devices, so it can't have recursion problems.
>>
>> Phil
>>
>> 8<-------------------------
>>
>> diff --git a/lsdrv b/lsdrv
>> index d1caaf8..37728c1 100755
>> --- a/lsdrv
>> +++ b/lsdrv
>> @@ -145,6 +145,7 @@ def sect2size(sectors):
>> # the struct object w/ filled in details.
>> controllers=dict()
>> def probe_controller(cpathlink):
>> + print "Probing controller %s" % cpathlink
>> cpath = os.path.realpath(cpathlink)
>> if cpath in controllers:
>> return controllers[cpath]
>> @@ -186,6 +187,7 @@ def probe_controller(cpathlink):
>> # controller.
>> phydevs=dict()
>> def probe_device(devpathlink, nodestr):
>> + print "Probing device %s" % devpathlink
>> devpath = os.path.realpath(devpathlink)
>> if devpath in phydevs:
>> return phydevs[devpath]
>> @@ -214,6 +216,7 @@ def probe_device(devpathlink, nodestr):
>> blockbyname=dict()
>> blockbynode=dict()
>> def probe_block(blocklink):
>> + print "Probing block %s" % blocklink
>> name=blocklink.rsplit('/', 1)[-1]
>> if name in blockbyname:
>> return
>
> --
> Torbjørn Skagestad
> Ide Til Produkt A/S
>
>
--
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: Torbjørn Skagestad @ 2011-05-26 18:42 UTC (permalink / raw)
To: Phil Turmel
Cc: Roman Mamedov, linux-raid, Roman Mamedov, John Robinson, CoolCold,
Mathias Burén
In-Reply-To: <4DDE9A61.2070201@turmel.org>
Hi,
I'm hitting this as well.It seems to be triggered by my non-existing
floppy device.
As there is no real floppy device connected, no driver is loaded, so we
never see a /driver directory. This loop then goes all the way up to /,
where it loops forever at 100% cpu.
from probe_controller()
151 while cpath and not os.path.exists(cpath+'/driver'):
152 cpath = os.path.dirname(cpath)
153 if cpath in controllers:
154 return controllers[cpath]
On Thu, 2011-05-26 at 14:22 -0400, Phil Turmel wrote:
> On 05/26/2011 02:12 PM, Roman Mamedov wrote:
> [...]
> > Now it locks up with 100% CPU load and no output, I waited for a couple of
> > minutes. On Ctrl-C:
> >
> > ^CTraceback (most recent call last):
> > File "./lsdrv", line 274, in <module>
> > probe_block('/sys/block/'+x)
> >
> > $ ls /sys/block/
> > etherd!e1.5 etherd!e2.1 md0 md2 sda sdc sde sdg
> > etherd!e1.6 fd0 md1 md4 sdb sdd sdf
> >
> > The first two devices are actually down at this moment, maybe that's the
> > reason? Still I'd expect not 100% CPU load by lsdrv, but 0% CPU and 100%
> > iowait in this case.
>
> Sounds like an infinite loop, or infinite recursion. Could you apply the temporary patch below so I can see how far the probing got?
>
> > Output of the old (bash) lsdrv:
> >
> > Controller device @ pci0000:00/0000:00:06.0 [pata_amd]
> > IDE interface: nVidia Corporation CK804 IDE (rev f2)
> > host8: [Empty]
> > host9: [Empty]
> > Controller device @ pci0000:00/0000:00:07.0 [sata_nv]
> > IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
> > host6: /dev/sdd ATA Hitachi HDS5C302 {SN: ..............}
> > host7: /dev/sde ATA WDC WD15EADS-00S {SN: ..............}
> > Controller device @ pci0000:00/0000:00:08.0 [sata_nv]
> > IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
> > host10: /dev/sdf ATA WDC WD20EADS-00S {SN: ..............}
> > host11: /dev/sdg ATA WDC WD20EADS-00S {SN: ..............}
> > Controller device @ pci0000:00/0000:00:0d.0/0000:02:00.0 [ahci]
> > SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s
> > controller (rev 10) host4: /dev/sdc ATA Hitachi HDS5C302 {SN: ..............}
> > host5: [Empty]
> > Controller device @ pci0000:00/0000:00:0e.0/0000:01:00.0 [sata_mv]
> > SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
> > SATA-II (rev 02) host0: [Empty]
> > host1: [Empty]
> > host2: /dev/sda ATA ST31000528AS {SN: ..............}
> > host3: /dev/sdb ATA Hitachi HDS72202 {SN: ..............}
>
> The old code never attempted to recurse into the layers of block devices, so it can't have recursion problems.
>
> Phil
>
> 8<-------------------------
>
> diff --git a/lsdrv b/lsdrv
> index d1caaf8..37728c1 100755
> --- a/lsdrv
> +++ b/lsdrv
> @@ -145,6 +145,7 @@ def sect2size(sectors):
> # the struct object w/ filled in details.
> controllers=dict()
> def probe_controller(cpathlink):
> + print "Probing controller %s" % cpathlink
> cpath = os.path.realpath(cpathlink)
> if cpath in controllers:
> return controllers[cpath]
> @@ -186,6 +187,7 @@ def probe_controller(cpathlink):
> # controller.
> phydevs=dict()
> def probe_device(devpathlink, nodestr):
> + print "Probing device %s" % devpathlink
> devpath = os.path.realpath(devpathlink)
> if devpath in phydevs:
> return phydevs[devpath]
> @@ -214,6 +216,7 @@ def probe_device(devpathlink, nodestr):
> blockbyname=dict()
> blockbynode=dict()
> def probe_block(blocklink):
> + print "Probing block %s" % blocklink
> name=blocklink.rsplit('/', 1)[-1]
> if name in blockbyname:
> return
--
Torbjørn Skagestad
Ide Til Produkt A/S
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Can not start md0 after upgrade. SOLVED
From: Stan Hoeppner @ 2011-05-26 18:38 UTC (permalink / raw)
To: John McMonagle; +Cc: linux-raid
In-Reply-To: <201105261320.08844.johnm@advocap.org>
On 5/26/2011 1:20 PM, John McMonagle wrote:
> On Wednesday, May 25, 2011 04:57:38 pm Stan Hoeppner wrote:
>> Please show the contents of /etc/mdadm.conf, and dmesg output.
>
> The problem was it was starting mdadm before the scsi driver was done
> initializing.
>
> Found solution at http://wiki.debian.org/InitramfsDebug
> Added kernel parameter scsi_mod.scan=sync
>
> Ran in to this years ago but forgot :-(
Glad to hear you resolved it. Is it safe to assume that taking a peek
at dmesg was useful?
--
Stan
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 18:22 UTC (permalink / raw)
To: Roman Mamedov
Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov, John Robinson,
CoolCold, Mathias Burén
In-Reply-To: <20110527001235.2b47572e@natsu>
On 05/26/2011 02:12 PM, Roman Mamedov wrote:
[...]
> Now it locks up with 100% CPU load and no output, I waited for a couple of
> minutes. On Ctrl-C:
>
> ^CTraceback (most recent call last):
> File "./lsdrv", line 274, in <module>
> probe_block('/sys/block/'+x)
>
> $ ls /sys/block/
> etherd!e1.5 etherd!e2.1 md0 md2 sda sdc sde sdg
> etherd!e1.6 fd0 md1 md4 sdb sdd sdf
>
> The first two devices are actually down at this moment, maybe that's the
> reason? Still I'd expect not 100% CPU load by lsdrv, but 0% CPU and 100%
> iowait in this case.
Sounds like an infinite loop, or infinite recursion. Could you apply the temporary patch below so I can see how far the probing got?
> Output of the old (bash) lsdrv:
>
> Controller device @ pci0000:00/0000:00:06.0 [pata_amd]
> IDE interface: nVidia Corporation CK804 IDE (rev f2)
> host8: [Empty]
> host9: [Empty]
> Controller device @ pci0000:00/0000:00:07.0 [sata_nv]
> IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
> host6: /dev/sdd ATA Hitachi HDS5C302 {SN: ..............}
> host7: /dev/sde ATA WDC WD15EADS-00S {SN: ..............}
> Controller device @ pci0000:00/0000:00:08.0 [sata_nv]
> IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
> host10: /dev/sdf ATA WDC WD20EADS-00S {SN: ..............}
> host11: /dev/sdg ATA WDC WD20EADS-00S {SN: ..............}
> Controller device @ pci0000:00/0000:00:0d.0/0000:02:00.0 [ahci]
> SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s
> controller (rev 10) host4: /dev/sdc ATA Hitachi HDS5C302 {SN: ..............}
> host5: [Empty]
> Controller device @ pci0000:00/0000:00:0e.0/0000:01:00.0 [sata_mv]
> SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
> SATA-II (rev 02) host0: [Empty]
> host1: [Empty]
> host2: /dev/sda ATA ST31000528AS {SN: ..............}
> host3: /dev/sdb ATA Hitachi HDS72202 {SN: ..............}
The old code never attempted to recurse into the layers of block devices, so it can't have recursion problems.
Phil
8<-------------------------
diff --git a/lsdrv b/lsdrv
index d1caaf8..37728c1 100755
--- a/lsdrv
+++ b/lsdrv
@@ -145,6 +145,7 @@ def sect2size(sectors):
# the struct object w/ filled in details.
controllers=dict()
def probe_controller(cpathlink):
+ print "Probing controller %s" % cpathlink
cpath = os.path.realpath(cpathlink)
if cpath in controllers:
return controllers[cpath]
@@ -186,6 +187,7 @@ def probe_controller(cpathlink):
# controller.
phydevs=dict()
def probe_device(devpathlink, nodestr):
+ print "Probing device %s" % devpathlink
devpath = os.path.realpath(devpathlink)
if devpath in phydevs:
return phydevs[devpath]
@@ -214,6 +216,7 @@ def probe_device(devpathlink, nodestr):
blockbyname=dict()
blockbynode=dict()
def probe_block(blocklink):
+ print "Probing block %s" % blocklink
name=blocklink.rsplit('/', 1)[-1]
if name in blockbyname:
return
^ permalink raw reply related
* Re: Can not start md0 after upgrade. SOLVED
From: John McMonagle @ 2011-05-26 18:20 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DDD7B52.2060800@hardwarefreak.com>
On Wednesday, May 25, 2011 04:57:38 pm Stan Hoeppner wrote:
> On 5/25/2011 3:21 PM, John McMonagle wrote:
> > On Wednesday 25 May 2011 10:39:51 am Stan Hoeppner wrote:
> >> On 5/25/2011 10:06 AM, John McMonagle wrote:
> >>> On Wednesday, May 25, 2011 09:54:32 am Stan Hoeppner wrote:
> >>>> On 5/25/2011 8:19 AM, John McMonagle wrote:
> >>>>> Just upgraded a poweredge 1850 server from Debian lenny to squeeze
> >>>>> and can not boot with the new 2.6.32 kernel.
> >>>>>
> >>>>> From lspci have this controller:
> >>>>> SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
> >>>>> Fusion-MPT Dual Ultra320 SCSI (rev 08)
> >>>>>
> >>>>>
> >>>>> Running mdadm raid with root on md0.
> >>>>>
> >>>>> Normally run xen but all info is for when running without xen.
> >>>>>
> >>>>> I can still boot with the 2.6.26 kernel but not with the new 2.6.32
> >>>>> kernel. Under 2.6.32 it fails to start md0.
> >>>>> in the busy box console
> >>>>> Can see all the needed partitions.
> >>>>> What was sda and sdb are now sdb and sdc that should not matter??
> >>>>> mdadm.conf is:
> >>>>> DEVICE partitions
> >>>>> CREATE owner=root group=disk mode=0660 auto=yes
> >>>>> HOMEHOST <system>
> >>>>> MAILADDR xxxxx@advocap.org
> >>>>> ARRAY /dev/md0 level=raid1 num-devices=2
> >>>>> UUID=6f744c89:d2578f95:c150b018:d9f789b1
> >>>>> ARRAY /dev/md1 level=raid1 num-devices=2
> >>>>> UUID=7938d59c:28a69e5e:3facbdc2:12974557
> >>>>
> >>>> This is probably due to udev changes. What device is now sda?
> >>>>
> >>>> Using drive UUIDs instead of /dev/sdx in your arrays should fix this.
> >>>
> >>> I think sda is a cd or virtual cd now.
> >>>
> >>> In the mdadm.conf it uses uuids and no /dev/sdx references or are you
> >>> referring to something else?
> >>
> >> How is /dev/md0 assembled in your initramfs? You said your root
> >> filesystem is on /dev/md0. Thus /dev/md0 must be assembled before
> >> /etc/mdadm.conf can be read.
> >>
> >> Another way around this problem is to create persistent udev rules. But
> >> since this requires created one-to-one mappings between
> >> /dev/sdx<->drive_UUID mappings, it is easy to simply have mdraid use
> >> drive UUIDs across the board, including within initramfs.
> >
> > Stan
> >
> > The /etc/mdadm/mdadm.conf file is in the initramfs and is referenced by
> > the /scripts/local-top/mdadm script.
> > If I run it manually it starts raid Ok and I can mount /dev/md0
> > I'm not sure how on gets it to complete the boot process.
>
> Please show the contents of /etc/mdadm.conf, and dmesg output.
The problem was it was starting mdadm before the scsi driver was done
initializing.
Found solution at http://wiki.debian.org/InitramfsDebug
Added kernel parameter scsi_mod.scan=sync
Ran in to this years ago but forgot :-(
John
^ permalink raw reply
* Re: Storage device enumeration script
From: Roman Mamedov @ 2011-05-26 18:12 UTC (permalink / raw)
To: Phil Turmel
Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov, John Robinson,
CoolCold, Mathias Burén
In-Reply-To: <4DDE95C1.5030401@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
On Thu, 26 May 2011 14:02:41 -0400
Phil Turmel <philip@turmel.org> wrote:
> Hi Roman,
>
> On 05/26/2011 01:54 PM, Roman Mamedov wrote:
> > On Thu, 26 May 2011 13:46:59 -0400
> > Phil Turmel <philip@turmel.org> wrote:
> >
> >> if you just want the latest script:
> >>
> >> https://github.com/pturmel/lsdrv/raw/HEAD/lsdrv
> >
> > I already reported this earlier, but still in this version:
> >
> > Traceback (most recent call last):
> > File "./lsdrv", line 274, in <module>
> > probe_block('/sys/block/'+x)
> > File "./lsdrv", line 226, in probe_block
> > dev.phy = probe_device(blkpath+'/device', nodestr)
> > File "./lsdrv", line 193, in probe_device
> > vendor=fileline1(devpath+'/vendor'),
> > File "./lsdrv", line 49, in fileline1
> > fh = open(filename, 'r')
> > IOError: [Errno 2] No such file or directory:
> > '/sys/devices/platform/floppy.0/vendor'
>
> I used the wrong exception type. Fix pushed. Try again?
Now it locks up with 100% CPU load and no output, I waited for a couple of
minutes. On Ctrl-C:
^CTraceback (most recent call last):
File "./lsdrv", line 274, in <module>
probe_block('/sys/block/'+x)
$ ls /sys/block/
etherd!e1.5 etherd!e2.1 md0 md2 sda sdc sde sdg
etherd!e1.6 fd0 md1 md4 sdb sdd sdf
The first two devices are actually down at this moment, maybe that's the
reason? Still I'd expect not 100% CPU load by lsdrv, but 0% CPU and 100%
iowait in this case.
Output of the old (bash) lsdrv:
Controller device @ pci0000:00/0000:00:06.0 [pata_amd]
IDE interface: nVidia Corporation CK804 IDE (rev f2)
host8: [Empty]
host9: [Empty]
Controller device @ pci0000:00/0000:00:07.0 [sata_nv]
IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
host6: /dev/sdd ATA Hitachi HDS5C302 {SN: ..............}
host7: /dev/sde ATA WDC WD15EADS-00S {SN: ..............}
Controller device @ pci0000:00/0000:00:08.0 [sata_nv]
IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
host10: /dev/sdf ATA WDC WD20EADS-00S {SN: ..............}
host11: /dev/sdg ATA WDC WD20EADS-00S {SN: ..............}
Controller device @ pci0000:00/0000:00:0d.0/0000:02:00.0 [ahci]
SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s
controller (rev 10) host4: /dev/sdc ATA Hitachi HDS5C302 {SN: ..............}
host5: [Empty]
Controller device @ pci0000:00/0000:00:0e.0/0000:01:00.0 [sata_mv]
SCSI storage controller: Marvell Technology Group Ltd. 88SX7042 PCI-e 4-port
SATA-II (rev 02) host0: [Empty]
host1: [Empty]
host2: /dev/sda ATA ST31000528AS {SN: ..............}
host3: /dev/sdb ATA Hitachi HDS72202 {SN: ..............}
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 18:02 UTC (permalink / raw)
To: Roman Mamedov
Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov, John Robinson,
CoolCold, Mathias Burén
In-Reply-To: <20110526235415.584ae2e2@natsu>
Hi Roman,
On 05/26/2011 01:54 PM, Roman Mamedov wrote:
> On Thu, 26 May 2011 13:46:59 -0400
> Phil Turmel <philip@turmel.org> wrote:
>
>> if you just want the latest script:
>>
>> https://github.com/pturmel/lsdrv/raw/HEAD/lsdrv
>
> I already reported this earlier, but still in this version:
>
> Traceback (most recent call last):
> File "./lsdrv", line 274, in <module>
> probe_block('/sys/block/'+x)
> File "./lsdrv", line 226, in probe_block
> dev.phy = probe_device(blkpath+'/device', nodestr)
> File "./lsdrv", line 193, in probe_device
> vendor=fileline1(devpath+'/vendor'),
> File "./lsdrv", line 49, in fileline1
> fh = open(filename, 'r')
> IOError: [Errno 2] No such file or directory:
> '/sys/devices/platform/floppy.0/vendor'
I used the wrong exception type. Fix pushed. Try again?
Phil
^ permalink raw reply
* Re: Storage device enumeration script
From: Roman Mamedov @ 2011-05-26 17:54 UTC (permalink / raw)
To: Phil Turmel
Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov, John Robinson,
CoolCold, Mathias Burén
In-Reply-To: <4DDE9213.2070508@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
On Thu, 26 May 2011 13:46:59 -0400
Phil Turmel <philip@turmel.org> wrote:
> if you just want the latest script:
>
> https://github.com/pturmel/lsdrv/raw/HEAD/lsdrv
I already reported this earlier, but still in this version:
Traceback (most recent call last):
File "./lsdrv", line 274, in <module>
probe_block('/sys/block/'+x)
File "./lsdrv", line 226, in probe_block
dev.phy = probe_device(blkpath+'/device', nodestr)
File "./lsdrv", line 193, in probe_device
vendor=fileline1(devpath+'/vendor'),
File "./lsdrv", line 49, in fileline1
fh = open(filename, 'r')
IOError: [Errno 2] No such file or directory:
'/sys/devices/platform/floppy.0/vendor'
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Storage device enumeration script
From: Mathias Burén @ 2011-05-26 17:51 UTC (permalink / raw)
To: Phil Turmel
Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov, John Robinson,
CoolCold
In-Reply-To: <4DDE9213.2070508@turmel.org>
On 26 May 2011 18:46, Phil Turmel <philip@turmel.org> wrote:
> On 05/26/2011 07:39 AM, Phil Turmel wrote:
>> On 05/26/2011 04:11 AM, CoolCold wrote:
>>> May be setup some github repo for this?
>>>
>>
>> Yes, I'll do this later today. Obviously needed. :(
>
> Done. With part of Torbjørn's patch and further fixes as proper commits.
>
> https://github.com/pturmel/lsdrv
>
> if you just want the latest script:
>
> https://github.com/pturmel/lsdrv/raw/HEAD/lsdrv
>
> Bug reports welcome. Patches, too.
>
> I'm especially interested in users with hardware raid controllers... not all of them expose their devices through the SCSI subsystem. I've an older HP SmartArray here to play with, so I know it basically works. I'm interested in enumerating the physical drives hooked to these controller subsystems.
>
> Phil
>
I think all looks good now:
~/bin $ sudo python2 ./lsdrv
PCI [ahci] 00:0b.0 SATA controller: nVidia Corporation MCP79 AHCI
Controller (rev b1)
├─scsi 0:0:0:0 ATA Corsair CSSD-F60 {10326505580009990027}
│ └─sda: Partitioned (dos) 55.90g
│ ├─sda1: (ext4) 100.00m 'ssd_boot' {ae879f86-73a4-451f-bb6b-e778ad1b57d6}
│ │ └─Mounted as /dev/sda1 @ /boot
│ ├─sda2: (swap) 2.00g 'ssd_swap' {a28e32fa-628c-419a-9693-ca88166d230f}
│ └─sda3: (ext4) 53.80g 'ssd_root' {6e812ed7-01c4-4a76-ae31-7b3d36d847f5}
│ └─Mounted as /dev/disk/by-label/ssd_root @ /
├─scsi 1:0:0:0 ATA WDC WD20EARS-00M {WD-WCAZA1022443}
│ └─sdb: Partitioned (dos) 1.82t
│ └─sdb1: MD raid6 (1/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
│ └─md0: PV LVM2_member 9.08t/9.08t VG lvstorage 9.08t
{YLEUKB-klxF-X3gF-6dG3-DL4R-xebv-6gKQc2}
│ └─Volume Group lvstorage (md0) 0 free {
Xd0HTM-azdN-v9kJ-C7vD-COcU-Cnn8-6AJ6hI}
│ └─dm-0: (ext4) 9.08t 'storage'
{0ca82f13-680f-4b0d-a5d0-08c246a838e5}
│ └─Mounted as /dev/mapper/lvstorage-storage @ /raid6volume
├─scsi 2:0:0:0 ATA WDC WD20EARS-00M {WD-WMAZ20152590}
│ └─sdc: Partitioned (dos) 1.82t
│ └─sdc1: MD raid6 (3/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
├─scsi 3:0:0:0 ATA WDC WD20EARS-00M {WD-WMAZ20188479}
│ └─sdd: Partitioned (dos) 1.82t
│ └─sdd1: MD raid6 (2/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
├─scsi 4:x:x:x [Empty]
└─scsi 5:x:x:x [Empty]
PCI [sata_mv] 05:00.0 SCSI storage controller: HighPoint Technologies,
Inc. RocketRAID 230x 4 Port SATA-II Controller (rev 02)
├─scsi 6:0:0:0 ATA WDC WD20EARS-00M {WD-WCAZA3609190}
│ └─sde: Partitioned (dos) 1.82t
│ └─sde1: MD raid6 (6/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
├─scsi 7:0:0:0 ATA SAMSUNG HD204UI {S2HGJ1RZ800964}
│ └─sdf: Partitioned (dos) 1.82t
│ └─sdf1: MD raid6 (4/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
├─scsi 8:0:0:0 ATA WDC WD20EARS-00M {WD-WCAZA1000331}
│ └─sdg: Partitioned (dos) 1.82t
│ └─sdg1: MD raid6 (0/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
└─scsi 9:0:0:0 ATA SAMSUNG HD204UI {S2HGJ1RZ800850}
└─sdh: Partitioned (dos) 1.82t
└─sdh1: MD raid6 (5/7) 1.82t md0 clean in_sync 'ion:0'
{e6595c64-b3ae-90b3-f011-33ac3f402d20}
Nice.
/M
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 17:46 UTC (permalink / raw)
To: Torbjørn Skagestad
Cc: linux-raid, Roman Mamedov, John Robinson, CoolCold,
Mathias Burén
In-Reply-To: <4DDE3BF1.7030105@turmel.org>
On 05/26/2011 07:39 AM, Phil Turmel wrote:
> On 05/26/2011 04:11 AM, CoolCold wrote:
>> May be setup some github repo for this?
>>
>
> Yes, I'll do this later today. Obviously needed. :(
Done. With part of Torbjørn's patch and further fixes as proper commits.
https://github.com/pturmel/lsdrv
if you just want the latest script:
https://github.com/pturmel/lsdrv/raw/HEAD/lsdrv
Bug reports welcome. Patches, too.
I'm especially interested in users with hardware raid controllers... not all of them expose their devices through the SCSI subsystem. I've an older HP SmartArray here to play with, so I know it basically works. I'm interested in enumerating the physical drives hooked to these controller subsystems.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: creating degraded raid1 with imsm metadata
From: Jiang, Dave @ 2011-05-26 16:40 UTC (permalink / raw)
To: FDi, linux-raid@vger.kernel.org
In-Reply-To: <20110526074259.GA31623@r00t3d.com>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of FDi
> Sent: Thursday, May 26, 2011 12:43 AM
> To: linux-raid@vger.kernel.org
> Subject: creating degraded raid1 with imsm metadata
>
> Hello *,
>
> Since Intel's Matrix Storage Manager option ROM doesn't support creating of
> degraded arrays I was wondering if I could use mdadm to make one? I had a
> very hard time finding documentation about how mdadm is supposed to
> work with imsm.
>
> The plan is to make a 2x1TB raid1 with one device missing and then later add
> the other disk in once all the data has been copied to the degraded array. So
> a typical raid1 migration scenario, which Intel oddly enough doesn't seem to
> support with their option ROM.
Not sure if that's possible but have you looked at the Linux RAID wiki on IMSM information?
https://raid.wiki.kernel.org/index.php/RAID_setup#External_Metadata
^ permalink raw reply
* Re: [PATCH 2 of 9] MD: should_read_superblock
From: Jonathan Brassow @ 2011-05-26 14:50 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110526103209.4972289d@notabene.brown>
On May 25, 2011, at 7:32 PM, NeilBrown wrote:
> On Wed, 25 May 2011 09:00:19 -0500 Jonathan Brassow <jbrassow@redhat.com>
> wrote:
>
>>
>> On May 24, 2011, at 11:01 PM, NeilBrown wrote:
>>
>>> On Mon, 23 May 2011 22:06:09 -0500 Jonathan Brassow <jbrassow@f14.redhat.com>
>>> wrote:
>>>
>>>> Patch name: md-should_read_superblock.patch
>>>>
>>>> Add new function to determine whether MD superblocks should be read.
>>>>
>>>> It used to be sufficient to check if mddev->raid_disks was set to determine
>>>> whether to read the superblock or not. However, device-mapper (dm-raid.c)
>>>> sets this value before calling md_run(). Thus, we need additional mechanisms
>>>> for determining whether to read the superblock. This patch adds the condition
>>>> that if rdev->meta_bdev is set, the superblock should be read - something that
>>>> only device-mapper does (and only when there are superblocks to be read/used).
>>>>
>>>> Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
>>>
>>> I've been feeling uncomfortable about this and have spent a while trying to
>>> see if my discomfort is at all justified. It seems that maybe it is.
>>>
>>> The discomfort is really at analyze_sbs being used for dm arrays. It is
>>> really for arrays where md completely controls the metadata. dm array are in
>>> a strange intermediate situation where some metadata is controlled by
>>> user-space (so md is told about some details of the array) and other metadata
>>> is managed by the kernel - so md finds those bits out by itself.
>>>
>>> It isn't yet entirely clear to me how to handle the half-way state best.
>>>
>>> But the particular problem is that analyse_sbs can call kick_rdev_from_array.
>>> This will call export_rdev which will call kobject_put(&rdev->kboj) which is
>>> bad because dm-based rdevs do not get their kobj initialised.
>>>
>>> So I think analyse_sbs should not be used for dm arrays.
>>> Rather the code in dm-raid.c which parses the metadata_device info from the
>>> constructor line should load_super. Then before md_run is called it should
>>> do the 'validate_super' step and record any failures.
>>>
>>> So the only super_types method that md code would call on a dm-raid array
>>> would be sync_super.
>>>
>>> Does that work for you?
>>
>> That seems sensible. It changes things up a bit though...
>>
>> 1) the load_super and validate_super functions would go into dm-raid.c, but stubs (returning EINVAL) would remain in md.c in order to fill-out the super_types pointers.
>> 2) the device-mapper superblock would have to move to a common place because it would need to be shared by the super functions in dm-raid.c and sync_super in md.c. I'd rather not put the new superblock in md_p.h... perhaps a new file, dm-raid.h? (You could hide the superblock entirely in dm-raid.c, but you'd have to export a function from dm-raid.c that would be called by sync_super in md.c - necessitating a dm-raid.h again. Is this a better solution?)
>>
>> brassow
>
> How about we put a 'sync_super' or possibly a 'struct super_type' pointer in
> mddev_t, and use it instead of mddev->major_version for finding operations.
> Then all knowledge of the dm metadata can live in dm-raid.c??
I was just thinking that - yes, that sounds good.
I haven't thought about it too deeply yet, so I'm not sure which I like better:
1) just sync_super ptr in mddev_t
2) super_types in mddev_t
My first impression is just sync_super, after all, the load and validate can be done within device-mapper and never need to be called by MD outside analyze_sbs and routines that add devices, right? Perhaps we would just remove sync_super from super_types or check for mddev->sync_super before calling super_types[x].sync_super? I'll think more about it.
thanks,
brassow
^ permalink raw reply
* Re: Storage device enumeration script
From: Torbjørn Skagestad @ 2011-05-26 12:05 UTC (permalink / raw)
To: Phil Turmel; +Cc: John Robinson, linux-raid, Roman Mamedov
In-Reply-To: <4DDE3E60.3010408@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
On Thu, 2011-05-26 at 07:49 -0400, Phil Turmel wrote:
> On 05/26/2011 05:59 AM, John Robinson wrote:
> > On 26/05/2011 10:45, Torbjørn Skagestad wrote:
> >> Hi,
> >>
> >> Great tool, thanks for sharing.
> >>
> >> I had to add some error handling to get it to work properly.
> >> Currently it runs on Ubuntu 10.04, 10.10 and 11.04.
> >>
> >> Added the check John Robinson asked for as well.
> >>
> >> Attached patch for those interested.
> >
> > Thanks, Torbjørn!
> >
> > Getting there:
> >
> > [root@beast lsdrv]# python2.6 lsdrv
> > PCI [pata_marvell] 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b2)
> > └─scsi 0:0:0:0 HL-DT-ST DVD-RAM GH22NP20
> > └─sr0: Empty/Unknown 1.00g
> > PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller
> > ├─scsi 2:0:0:0 ATA Hitachi HDS72101
> > │ └─sda: Empty/Unknown 931.51g
> > Traceback (most recent call last):
> > File "lsdrv", line 387, in <module>
> > show_blocks(" %s " % branch[0], [phy.block])
> > File "lsdrv", line 339, in show_blocks
> > show_blocks("%s %s " % (indent, branch[0]), [blockbyname[x] for x in subs])
> > KeyError: 'sda1'
> >
> > Now, something's not getting picked up about sda. Looking at Mathias' "sweet" output, it's not coping with the (DOS) partition table. Another variation on my kernel's /sys or still to old a Python or ...?
>
> Hmmm. I'll set up another CentOS VM. If I recall correctly, that kernel has the original block devices in folders named '.../block:sda1' instead of '.../block/sda1'. I'll have to identify this in the initial sweep through sysfs.
>
For CentOS 5.4 (2.6.18-128.1.14) it is /sys/block/sda/sda[1-9]
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Torbjørn Skagestad
Idé Til Produkt AS
torborn@itpas.no
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 12:00 UTC (permalink / raw)
To: CoolCold; +Cc: Mathias Burén, linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <BANLkTik-HjxNPGON7ZEwOSKJZOBzeETeAg@mail.gmail.com>
On 05/26/2011 04:24 AM, CoolCold wrote:
[...]
> On Debian Lenny produces error:
> root@gamma2:/tmp# python lsdrv
> Traceback (most recent call last):
> File "lsdrv", line 17, in <module>
> import os, io, re
> ImportError: No module named io
Huh. The 'io' module is v2.6 and above. Another reason to make a helper function for reading these files.
Phil
^ permalink raw reply
* Re: Storage device enumeration script
From: Torbjørn Skagestad @ 2011-05-26 11:52 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov, John Robinson, CoolCold
In-Reply-To: <4DDE3BF1.7030105@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
On Thu, 2011-05-26 at 07:39 -0400, Phil Turmel wrote:
> Thanks Torbjørn !
>
> I tend to short the error-checking when I'm putting something together... Clearly, this script was less baked than I thought.
>
> On 05/26/2011 05:45 AM, Torbjørn Skagestad wrote:
> > @@ -166,9 +171,12 @@
> > devpath = os.path.realpath(devpathlink)
> > if devpath in phydevs:
> > return phydevs[devpath]
> > - phy = Struct(dpath=devpath, node=nodestr,
> > - vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
> > - model=io.FileIO(devpath+'/model').read().split("\n",1)[0].strip())
> > + try:
> > + phy = Struct(dpath=devpath, node=nodestr,
> > + vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
> > + model=io.FileIO(devpath+'/model').read().split("\n",1)[0].strip())
> > + except IOError:
> > + return None
> > if os.path.exists(devpath+'/unique_id'):
> > phy.serial = io.FileIO(devpath+'/unique_id').read().split("\n",1)[0].strip()
> > if not phy.serial:
>
> This hunk will have to be done differently. "phy" needs to be set without vendor & model if they can't be read. I'll make a helper function to read the first line of a file, or return None.
That makes sense.
Guess I was too trigger happy here and ignored some devices in the
process.
>
> On 05/26/2011 04:11 AM, CoolCold wrote:
> > May be setup some github repo for this?
> >
>
> Yes, I'll do this later today. Obviously needed. :(
>
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Torbjørn Skagestad
Idé Til Produkt AS
torborn@itpas.no
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 11:49 UTC (permalink / raw)
To: John Robinson; +Cc: Torbjørn Skagestad, linux-raid, Roman Mamedov
In-Reply-To: <4DDE249C.7080004@anonymous.org.uk>
On 05/26/2011 05:59 AM, John Robinson wrote:
> On 26/05/2011 10:45, Torbjørn Skagestad wrote:
>> Hi,
>>
>> Great tool, thanks for sharing.
>>
>> I had to add some error handling to get it to work properly.
>> Currently it runs on Ubuntu 10.04, 10.10 and 11.04.
>>
>> Added the check John Robinson asked for as well.
>>
>> Attached patch for those interested.
>
> Thanks, Torbjørn!
>
> Getting there:
>
> [root@beast lsdrv]# python2.6 lsdrv
> PCI [pata_marvell] 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6121 SATA II Controller (rev b2)
> └─scsi 0:0:0:0 HL-DT-ST DVD-RAM GH22NP20
> └─sr0: Empty/Unknown 1.00g
> PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller
> ├─scsi 2:0:0:0 ATA Hitachi HDS72101
> │ └─sda: Empty/Unknown 931.51g
> Traceback (most recent call last):
> File "lsdrv", line 387, in <module>
> show_blocks(" %s " % branch[0], [phy.block])
> File "lsdrv", line 339, in show_blocks
> show_blocks("%s %s " % (indent, branch[0]), [blockbyname[x] for x in subs])
> KeyError: 'sda1'
>
> Now, something's not getting picked up about sda. Looking at Mathias' "sweet" output, it's not coping with the (DOS) partition table. Another variation on my kernel's /sys or still to old a Python or ...?
Hmmm. I'll set up another CentOS VM. If I recall correctly, that kernel has the original block devices in folders named '.../block:sda1' instead of '.../block/sda1'. I'll have to identify this in the initial sweep through sysfs.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 11:41 UTC (permalink / raw)
To: Mathias Burén; +Cc: lrhorer, linux-raid
In-Reply-To: <BANLkTinKG2THYLQUK4Bo-tOamQTvLpQpqg@mail.gmail.com>
On 05/26/2011 02:16 AM, Mathias Burén wrote:
> On 26 May 2011 07:14, Leslie Rhorer <lrhorer@satx.rr.com> wrote:
>>
>> I get an error right off the bat:
>>
>> Traceback (most recent call last):
>> File "./lsdrv.txt", line 264, in <module>
>> for x in runx(['pvs', '-o',
>> 'pv_name,pv_used,pv_size,pv_uuid,vg_name,vg_size,vg_free,vg_uuid',
>> '--noheadings', '--separator', ' ']).split("\n"):
>> File "./lsdrv.txt", line 50, in runx
>> sub = Popen(*args, **kwargs)
>> File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
>> errread, errwrite)
>> File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
>> raise child_exception
>> OSError: [Errno 2] No such file or directory
>>
>> I'm running Python 2.6.6 and mdadm 3.1.4 running on kernel 2.6.32-5-amd64
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> I get that in Ubuntu 11.04 on a laptop as well.
>
> /M
Does a plain install of Ubuntu include the LVM utilities? Can you run "pvs" directly?
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: Phil Turmel @ 2011-05-26 11:39 UTC (permalink / raw)
To: Torbjørn Skagestad
Cc: linux-raid, Roman Mamedov, John Robinson, CoolCold
In-Reply-To: <1306403130.9437.109.camel@torbjorn>
Thanks Torbjørn !
I tend to short the error-checking when I'm putting something together... Clearly, this script was less baked than I thought.
On 05/26/2011 05:45 AM, Torbjørn Skagestad wrote:
> @@ -166,9 +171,12 @@
> devpath = os.path.realpath(devpathlink)
> if devpath in phydevs:
> return phydevs[devpath]
> - phy = Struct(dpath=devpath, node=nodestr,
> - vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
> - model=io.FileIO(devpath+'/model').read().split("\n",1)[0].strip())
> + try:
> + phy = Struct(dpath=devpath, node=nodestr,
> + vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
> + model=io.FileIO(devpath+'/model').read().split("\n",1)[0].strip())
> + except IOError:
> + return None
> if os.path.exists(devpath+'/unique_id'):
> phy.serial = io.FileIO(devpath+'/unique_id').read().split("\n",1)[0].strip()
> if not phy.serial:
This hunk will have to be done differently. "phy" needs to be set without vendor & model if they can't be read. I'll make a helper function to read the first line of a file, or return None.
On 05/26/2011 04:11 AM, CoolCold wrote:
> May be setup some github repo for this?
>
Yes, I'll do this later today. Obviously needed. :(
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Storage device enumeration script
From: John Robinson @ 2011-05-26 9:59 UTC (permalink / raw)
To: Torbjørn Skagestad; +Cc: Phil Turmel, linux-raid, Roman Mamedov
In-Reply-To: <1306403130.9437.109.camel@torbjorn>
On 26/05/2011 10:45, Torbjørn Skagestad wrote:
> Hi,
>
> Great tool, thanks for sharing.
>
> I had to add some error handling to get it to work properly.
> Currently it runs on Ubuntu 10.04, 10.10 and 11.04.
>
> Added the check John Robinson asked for as well.
>
> Attached patch for those interested.
Thanks, Torbjørn!
Getting there:
[root@beast lsdrv]# python2.6 lsdrv
PCI [pata_marvell] 03:00.0 IDE interface: Marvell Technology Group Ltd.
88SE6121 SATA II Controller (rev b2)
└─scsi 0:0:0:0 HL-DT-ST DVD-RAM GH22NP20
└─sr0: Empty/Unknown 1.00g
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10
Family) SATA AHCI Controller
├─scsi 2:0:0:0 ATA Hitachi HDS72101
│ └─sda: Empty/Unknown 931.51g
Traceback (most recent call last):
File "lsdrv", line 387, in <module>
show_blocks(" %s " % branch[0], [phy.block])
File "lsdrv", line 339, in show_blocks
show_blocks("%s %s " % (indent, branch[0]), [blockbyname[x] for x
in subs])
KeyError: 'sda1'
Now, something's not getting picked up about sda. Looking at Mathias'
"sweet" output, it's not coping with the (DOS) partition table. Another
variation on my kernel's /sys or still to old a Python or ...?
Cheers,
John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox