* 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
* Re: Storage device enumeration script
From: Torbjørn Skagestad @ 2011-05-26 9:45 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC301.7090608@turmel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1506 bytes --]
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
On Wed, 2011-05-25 at 23:03 -0400, Phil Turmel wrote:
> Hi All,
>
> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>
> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>
> New features:
> Supports non-SCSI storage devices
> Describes layered block devices
> MD raid
> LVM
> generic device mapper
> loop (partial)
> Shows UUIDs
> Shows mountpoints
> Avoids repeating subtrees when enumerating raid devices
>
> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>
> Please give it a whirl.
>
> Phil
--
Torbjørn Skagestad
Idé Til Produkt AS
torborn@itpas.no
[-- Attachment #1.2: lsdrv.patch --]
[-- Type: text/x-patch, Size: 1821 bytes --]
--- lsdrv 2011-05-26 11:06:44.000000000 +0200
+++ lsdrv.py 2011-05-26 11:34:50.000000000 +0200
@@ -47,7 +47,12 @@
def runx(*args, **kwargs):
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE
- sub = Popen(*args, **kwargs)
+ try:
+ sub = Popen(*args, **kwargs)
+ except OSError as e:
+ print "Unable to execute " + str(args[0][0])
+ print e
+ exit()
out, err = sub.communicate()
return out
@@ -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:
@@ -189,6 +197,8 @@
blockbyname=dict()
blockbynode=dict()
sysclassblock="/sys/class/block/"
+if(not os.path.exists(sysclassblock)):
+ sysclassblock = "/sys/block/"
for x in os.listdir(sysclassblock):
nodestr=io.FileIO(sysclassblock+x+'/dev').read().split("\n")[0]
sizestr=sect2size(io.FileIO(sysclassblock+x+'/size').read().split("\n")[0])
@@ -250,7 +260,10 @@
devstat = os.stat(mdev)
nodestr="%d:%d" % (os.major(devstat.st_rdev), os.minor(devstat.st_rdev))
if nodestr in blockbynode:
- mntstat = os.statvfs(mnt)
+ try:
+ mntstat = os.statvfs(mnt)
+ except OSError:
+ mntstat = None
dev = blockbynode[nodestr]
dev.mountdev = mdev
dev.mountpoint = mnt
[-- 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: John Robinson @ 2011-05-26 9:27 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov
In-Reply-To: <4DDDC301.7090608@turmel.org>
On 26/05/2011 04:03, Phil Turmel wrote:
> Hi All,
>
> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>
> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>
> New features:
> Supports non-SCSI storage devices
> Describes layered block devices
> MD raid
> LVM
> generic device mapper
> loop (partial)
> Shows UUIDs
> Shows mountpoints
> Avoids repeating subtrees when enumerating raid devices
>
> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>
> Please give it a whirl.
On CentOS 5:
[root@beast lsdrv]# ./lsdrv
Traceback (most recent call last):
File "./lsdrv", line 17, in ?
import os, io, re
ImportError: No module named io
[root@beast lsdrv]# python -V
Python 2.4.3
Maybe this is too old, so I got Python 2.6.5 from EPEL. Trying again:
[root@beast lsdrv]# python2.6 lsdrv
Traceback (most recent call last):
File "./lsdrv", line 192, in <module>
for x in os.listdir(sysclassblock):
OSError: [Errno 2] No such file or directory: '/sys/class/block/'
So I changed sysclassblock to '/sys/block/' to suit EL5's 2.6.18 kernel
(so it might be nice ;-) if you could auto-detect which was present):
[root@beast lsdrv]# python2.6 lsdrv
Traceback (most recent call last):
File "lsdrv", line 198, in <module>
dev.phy = probe_device(sysclassblock+x+'/device', nodestr)
File "lsdrv", line 170, in probe_device
vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
File "/usr/lib64/python2.6/io.py", line 631, in __init__
_fileio._FileIO.__init__(self, name, mode, closefd)
IOError: [Errno 2] No such file or directory:
'/sys/devices/platform/floppy.0/vendor'
This looks like the same error Roman had.
Cheers,
John.
^ permalink raw reply
* Re: Storage device enumeration script
From: CoolCold @ 2011-05-26 8:24 UTC (permalink / raw)
To: Phil Turmel; +Cc: Mathias Burén, linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC750.6040600@turmel.org>
On Thu, May 26, 2011 at 7:21 AM, Phil Turmel <philip@turmel.org> wrote:
> On 05/25/2011 11:10 PM, Mathias Burén wrote:
>> On 26 May 2011 04:03, Phil Turmel <philip@turmel.org> wrote:
>>> Hi All,
>>>
>>> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>>>
>>> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>>>
>>> New features:
>>> Supports non-SCSI storage devices
>>> Describes layered block devices
>>> MD raid
>>> LVM
>>> generic device mapper
>>> loop (partial)
>>> Shows UUIDs
>>> Shows mountpoints
>>> Avoids repeating subtrees when enumerating raid devices
>>>
>>> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>>>
>>> Please give it a whirl.
>>>
>>> Phil
>>>
>>
>> Awesome, however:
>>
>> $ ./lsdrv.py
>> File "./lsdrv.py", line 301
>> print "%s └─Volume Group %s (%s) %s free {%s}" % (indent,
>> vg.name, ','.join([dev.name for dev in vg.PVs]), vg.free, vg.uuid)
>> ^
>> SyntaxError: invalid syntax
>>
>> Maybe it's a copy-paste thing from my mail that does it. Could you put
>> it somewhere, like a pastebin?
>
> Yeah, should have thought of that first.
>
> http://www.turmel.org/other/lsdrv
>
> HTH,
Works in Debian Squeeze, but requires packages pciutils and sg3-utils
to be installed.
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
>
> 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
>
--
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: CoolCold @ 2011-05-26 8:11 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC301.7090608@turmel.org>
May be setup some github repo for this?
On Thu, May 26, 2011 at 7:03 AM, Phil Turmel <philip@turmel.org> wrote:
> Hi All,
>
> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>
> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>
> New features:
> Supports non-SCSI storage devices
> Describes layered block devices
> MD raid
> LVM
> generic device mapper
> loop (partial)
> Shows UUIDs
> Shows mountpoints
> Avoids repeating subtrees when enumerating raid devices
>
> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>
> Please give it a whirl.
>
> Phil
>
--
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
* creating degraded raid1 with imsm metadata
From: FDi @ 2011-05-26 7:42 UTC (permalink / raw)
To: linux-raid
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.
EOF
^ permalink raw reply
* Re: Storage device enumeration script
From: Mathias Burén @ 2011-05-26 6:16 UTC (permalink / raw)
To: lrhorer; +Cc: Phil Turmel, linux-raid
In-Reply-To: <7D.22.00666.3BFEDDD4@cdptpa-omtalb.mail.rr.com>
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
--
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: Leslie Rhorer @ 2011-05-26 6:14 UTC (permalink / raw)
To: 'Phil Turmel', linux-raid
In-Reply-To: <4DDDC301.7090608@turmel.org>
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
^ permalink raw reply
* Re: Storage device enumeration script
From: Roman Mamedov @ 2011-05-26 5:25 UTC (permalink / raw)
To: Phil Turmel; +Cc: Mathias Burén, linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC750.6040600@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On Wed, 25 May 2011 23:21:52 -0400
Phil Turmel <philip@turmel.org> wrote:
> Yeah, should have thought of that first.
>
> http://www.turmel.org/other/lsdrv
Traceback (most recent call last):
File "/r/scripts/lsdrv", line 198, in <module>
dev.phy = probe_device(sysclassblock+x+'/device', nodestr)
File "/r/scripts/lsdrv", line 170, in probe_device
vendor=io.FileIO(devpath+'/vendor').read().split("\n",1)[0].strip(),
File "/usr/lib/python2.6/io.py", line 631, in __init__
_fileio._FileIO.__init__(self, name, mode, closefd)
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
* Question on md126 / md127 issues
From: Dylan Distasio @ 2011-05-26 4:10 UTC (permalink / raw)
To: linux-raid
Hi all-
I recently created a RAID1 2 disk mdadm array /dev/md1 with 1.2
metadata on a Ubuntu system that has 3 other mdadm arrays running on
it. The power went out at my house last night, and I rebooted the
system when it came back up.
When it came back up, my new array was in two pieces /dev/md126 and
/dev/md127 (with incorrect members, showing 1 active drive, 1 spare in
each). I rebooted again, and had what appeared to be my working
array, but showing up under /dev/md127. I could stop and do a --scan
to assemble it correctly as /dev/md1, but when I rebooted again I got
the same results with 126 and 127. My mdadm.conf was correct.
I did some searching on my archives of this list, and found a solution
as follows:
-----------
How to fix the '125/126/127' mdadm issue.
The array has '125' stored as the 'preferred minor' in the metadata.
You can change this by assembling with --update=super-minor.
e.g.
mdadm -S /dev/md125
mdadm -A /dev/md1 --update=super-minor
it should get details of which devices to included from /etc/mdadm.conf.
However it is possible that mdadm.conf in your initrd also the name
as /dev/md125.
So once you have performed the above, run mkinitrd again, reboot, and report
what happens.
----------------
I had to run the above commands, and then make sure I ran
update-initramfs -v -u for it to stick after reboot.
My issue is solved, but I would like to understand what the root cause
is, and why the above solution worked. Can someone elaborate on what
super-minor is? This is a home system and I had backups so I was
comfortable trying the above, but I don't typically like running
commands on faith I don't understand fully, especially in Linux.
Can anyone shed some light on this? I can provide further OS and
array details if necessary, but it sounds like this issue has occurred
for others in the past.
Thanks.
^ permalink raw reply
* Re: Storage device enumeration script
From: Mathias Burén @ 2011-05-26 3:25 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC750.6040600@turmel.org>
On 26 May 2011 04:21, Phil Turmel <philip@turmel.org> wrote:
> On 05/25/2011 11:10 PM, Mathias Burén wrote:
>> On 26 May 2011 04:03, Phil Turmel <philip@turmel.org> wrote:
>>> Hi All,
>>>
>>> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>>>
>>> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>>>
>>> New features:
>>> Supports non-SCSI storage devices
>>> Describes layered block devices
>>> MD raid
>>> LVM
>>> generic device mapper
>>> loop (partial)
>>> Shows UUIDs
>>> Shows mountpoints
>>> Avoids repeating subtrees when enumerating raid devices
>>>
>>> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>>>
>>> Please give it a whirl.
>>>
>>> Phil
>>>
>>
>> Awesome, however:
>>
>> $ ./lsdrv.py
>> File "./lsdrv.py", line 301
>> print "%s └─Volume Group %s (%s) %s free {%s}" % (indent,
>> vg.name, ','.join([dev.name for dev in vg.PVs]), vg.free, vg.uuid)
>> ^
>> SyntaxError: invalid syntax
>>
>> Maybe it's a copy-paste thing from my mail that does it. Could you put
>> it somewhere, like a pastebin?
>
> Yeah, should have thought of that first.
>
> http://www.turmel.org/other/lsdrv
>
> HTH,
>
> Phil
>
Aha, Archlinux defaults to python3. If I run the script with python2
it works. :)
~/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}
Sweet.
/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 3:21 UTC (permalink / raw)
To: Mathias Burén; +Cc: linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <BANLkTiky1L9fisPnxMKsceG19LbhxcF0ag@mail.gmail.com>
On 05/25/2011 11:10 PM, Mathias Burén wrote:
> On 26 May 2011 04:03, Phil Turmel <philip@turmel.org> wrote:
>> Hi All,
>>
>> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>>
>> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>>
>> New features:
>> Supports non-SCSI storage devices
>> Describes layered block devices
>> MD raid
>> LVM
>> generic device mapper
>> loop (partial)
>> Shows UUIDs
>> Shows mountpoints
>> Avoids repeating subtrees when enumerating raid devices
>>
>> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>>
>> Please give it a whirl.
>>
>> Phil
>>
>
> Awesome, however:
>
> $ ./lsdrv.py
> File "./lsdrv.py", line 301
> print "%s └─Volume Group %s (%s) %s free {%s}" % (indent,
> vg.name, ','.join([dev.name for dev in vg.PVs]), vg.free, vg.uuid)
> ^
> SyntaxError: invalid syntax
>
> Maybe it's a copy-paste thing from my mail that does it. Could you put
> it somewhere, like a pastebin?
Yeah, should have thought of that first.
http://www.turmel.org/other/lsdrv
HTH,
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: Mathias Burén @ 2011-05-26 3:10 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid, Roman Mamedov, John Robinson
In-Reply-To: <4DDDC301.7090608@turmel.org>
On 26 May 2011 04:03, Phil Turmel <philip@turmel.org> wrote:
> Hi All,
>
> Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
>
> I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
>
> New features:
> Supports non-SCSI storage devices
> Describes layered block devices
> MD raid
> LVM
> generic device mapper
> loop (partial)
> Shows UUIDs
> Shows mountpoints
> Avoids repeating subtrees when enumerating raid devices
>
> I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
>
> Please give it a whirl.
>
> Phil
>
Awesome, however:
$ ./lsdrv.py
File "./lsdrv.py", line 301
print "%s └─Volume Group %s (%s) %s free {%s}" % (indent,
vg.name, ','.join([dev.name for dev in vg.PVs]), vg.free, vg.uuid)
^
SyntaxError: invalid syntax
Maybe it's a copy-paste thing from my mail that does it. Could you put
it somewhere, like a pastebin?
cheers,
/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
* Storage device enumeration script
From: Phil Turmel @ 2011-05-26 3:03 UTC (permalink / raw)
To: linux-raid; +Cc: Roman Mamedov, John Robinson
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Hi All,
Last November, I shared a shell script that helped me keep track of the specific hot-swap drives I had in the various slots of my servers. Although encouraged by Roman and John, I declined to make a project out of it.
I've since kicked it around some more, and thought a bit about supporting more than just the SCSI subsystem. The latest and greatest is still built around some standard executables: blkid, lspci, lsusb, sginfo, and smartctl. The original was similar to "lsscsi", but with controller details and device serial numbers.
New features:
Supports non-SCSI storage devices
Describes layered block devices
MD raid
LVM
generic device mapper
loop (partial)
Shows UUIDs
Shows mountpoints
Avoids repeating subtrees when enumerating raid devices
I struggled with the last item, until I gave up on bash. I needed to pass data to subroutines by reference, and bash is sorely lacking in that area. The new script is in python. I'm releasing this one under the GPL version 2.
Please give it a whirl.
Phil
[-- Attachment #2: lsdrv --]
[-- Type: text/plain, Size: 14388 bytes --]
#! /usr/bin/python
# -*- coding: utf-8 -*-
#
# lsdrv - Report on a system's disk interfaces and how they are used.
#
# Copyright (C) 2011 Philip J. Turmel <philip@turmel.org>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, version 2.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
import os, io, re
from subprocess import Popen, PIPE
#-------------------
# Handy base for objects as "bags of properties"
# inspired by Peter Norvig http://norvig.com/python-iaq.html
# Unlike the original, this one supplies 'None' instead of an attribute
# error when an explicitly named property has not yet been set.
class Struct(object):
def __init__(self, **entries):
self.__dict__.update(entries)
def __repr__(self, recurse=[]):
if self in recurse:
return type(self)
args = []
for (k,v) in vars(self).items():
if isinstance(v, Struct):
args.append('%s=%s' % (k, v.__repr__(recurse+[self])))
else:
args.append('%s=%s' % (k, repr(v)))
return '%s(%s)' % (type(self), ', '.join(args))
def clone(self):
return type(self)(**self.__dict__)
def __getattr__(self, attr):
return None
#-------------------
# Spawn an executable and collect its output. Equivalent to the
# check_output convenience function of the subprocess module introduced
# in python 2.7.
def runx(*args, **kwargs):
kwargs['stdout'] = PIPE
kwargs['stderr'] = PIPE
sub = Popen(*args, **kwargs)
out, err = sub.communicate()
return out
#-------------------
# Extract a matched expression from a string buffer
# If a match is found, return the given replace expression.
re1 = re.compile(r'([/:][a-zA-Z]*)0+([0-9])')
re2 = re.compile(r'Serial.+\'(.+)\'')
re3 = re.compile(r'Serial.+:(.+)')
def extractre(regexp, buffer, retexp=r'\1'):
mo = re.search(regexp, buffer)
if mo:
return mo.expand(retexp)
return None
#-------------------
# Extract shell variable assignments from a multiline string buffer
# This simple implementation returns everything after the equals sign
# as the value, including any quotes.
varsre = re.compile(r'^\s*([a-zA-Z][a-zA-Z0-9_]*)\s*=(.+)$', re.MULTILINE)
def extractvars(buffer):
vars=dict()
for mo in varsre.finditer(buffer):
vars[mo.group(1)] = mo.group(2)
return vars
#-------------------
# By Seo Sanghyeon. Some changes by Connelly Barnes and Phil Turmel.
def try_int(s):
try: return int(s)
except: return s
natsortre = re.compile(r'(\d+|\D+)')
def natsort_key(s):
if isinstance(s, str):
return map(try_int, natsortre.findall(s))
else:
try:
return tuple([natsort_keys(x) for x in s])
except:
return s
def natcmp(a, b):
return cmp(natsort_key(a), natsort_key(b))
#-------------------
# Convert device sizes expressed in kibibytes into human-readable
# sizes with a reasonable power-of-two suffix.
def k2size(k):
if k<1000:
return "%4.2fk" % k
m=k/1024.0
if m<1000:
return "%4.2fm" % m
g=m/1024.0
if g<1000:
return "%4.2fg" % g
t=g/1024.0
if t<1000:
return "%4.2ft" % t
p=t/1024.0
return "%4.2fp" % p
#-------------------
# Convert device sizes expressed as 512-byte sectors into human-readable
# sizes with a reasonable power-of-two suffix.
def sect2size(sectors):
return k2size(int(sectors)/2.0)
#-------------------
# Given a sysfs path to the parent of a physical block device, resolve the
# controller path, look it up in the list of known controllers, and return
# the corresponding struct object. If it's not present in the list, create
# the struct object w/ filled in details.
controllers=dict()
def probe_controller(cpathlink):
cpath = os.path.realpath(cpathlink)
if cpath in controllers:
return controllers[cpath]
while cpath and not os.path.exists(cpath+'/driver'):
cpath = os.path.dirname(cpath)
if cpath in controllers:
return controllers[cpath]
if not cpath:
return None
cntrlr = Struct(cpath=cpath, units=dict(),
abbrev=re1.sub(r'\1\2', cpath[12:]),
driver = os.path.realpath(cpath+'/driver').rsplit('/',1)[-1],
modpre = io.FileIO(cpath+'/modalias').read().split("\n",1)[0].split(':',1)[0])
if cntrlr.modpre == 'pci':
cntrlr.description = runx(['lspci', '-s', cntrlr.abbrev.rsplit('/',1)[-1]]).split("\n",1)[0]
cntrlr.descriptors = ['PCI', '[%s]' % cntrlr.driver, cntrlr.description]
elif cntrlr.modpre == 'usb':
if os.path.exists(cpath+'/busnum'):
cntrlr.busnum = io.FileIO(cpath+'/busnum').read().split("\n",1)[0]
cntrlr.devnum = io.FileIO(cpath+'/devnum').read().split("\n",1)[0]
cntrlr.serial = io.FileIO(cpath+'/serial').read().split("\n",1)[0]
else:
parentpath = os.path.dirname(cpath)
cntrlr.busnum = io.FileIO(parentpath+'/busnum').read().split("\n",1)[0]
cntrlr.devnum = io.FileIO(parentpath+'/devnum').read().split("\n",1)[0]
cntrlr.serial = io.FileIO(parentpath+'/serial').read().split("\n",1)[0]
cntrlr.description = runx(['lsusb', '-s', cntrlr.busnum+':'+cntrlr.devnum]).split("\n",1)[0]
cntrlr.descriptors = ['USB', '[%s]' % cntrlr.driver, cntrlr.description, '{%s}' % cntrlr.serial]
else:
cntrlr.descriptors = ['Controller %s' % cntrlr.abbrev[1:], '[%s]' % cntrlr.driver, cntrlr.description]
controllers[cpath] = cntrlr
return cntrlr
#-------------------
# Given a link to a physical block device syspath, resolve the real device
# path, look it up in the list of known physical devices, and return
# the corresponding struct object. If it's not present in the list,
# create the struct object w/ filled in details, and probe its
# controller.
phydevs=dict()
def probe_device(devpathlink, nodestr):
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())
if os.path.exists(devpath+'/unique_id'):
phy.serial = io.FileIO(devpath+'/unique_id').read().split("\n",1)[0].strip()
if not phy.serial:
phy.serial = extractre(re2, runx(['sginfo', '-s', '/dev/block/'+nodestr]))
if not phy.serial:
phy.serial = extractre(re3, runx(['smartctl', '-i', '/dev/block/'+nodestr]))
phy.name = "%s %s" % (os.path.realpath(devpath+'/subsystem').rsplit('/',1)[-1], devpath.rsplit('/',1)[-1])
phy.controller = probe_controller(os.path.dirname(devpath))
if phy.controller:
phy.controller.units[phy.name] = phy
phydevs[devpath] = phy
return phy
#-------------------
# Collect block device information and create dictionaries by kernel
# name and by device major:minor. Probe each block device and try to
# describe the filesystem or other usage.
blockbyname=dict()
blockbynode=dict()
sysclassblock="/sys/class/block/"
for x in os.listdir(sysclassblock):
nodestr=io.FileIO(sysclassblock+x+'/dev').read().split("\n")[0]
sizestr=sect2size(io.FileIO(sysclassblock+x+'/size').read().split("\n")[0])
node = nodestr.split(':',1)
dev=Struct(name=x, node=nodestr, size=sizestr, major=int(node[0]), minor=int(node[1]), shown=False)
if os.path.exists(sysclassblock+x+'/device'):
dev.phy = probe_device(sysclassblock+x+'/device', nodestr)
if dev.phy:
dev.phy.block = dev
if os.path.exists(sysclassblock+x+'/holders'):
dev.holders = os.listdir(sysclassblock+x+'/holders')
else:
dev.holders = []
if os.path.exists(sysclassblock+x+'/slaves'):
dev.slaves = os.listdir(sysclassblock+x+'/slaves')
else:
dev.slaves = []
dev.partitions = [y for y in os.listdir(sysclassblock+x) if os.path.exists(sysclassblock+x+'/'+y+'/dev')]
dev.__dict__.update(extractvars(runx(['blkid', '-p', '-o', 'udev', '/dev/block/'+nodestr])))
if os.path.exists(sysclassblock+x+'/md'):
dev.isMD = True
dev.__dict__.update(extractvars(runx(['mdadm', '--export', '--detail', '/dev/block/'+nodestr])))
if dev.ID_FS_TYPE == 'linux_raid_member':
dev.hasMD = True
dev.__dict__.update(extractvars(runx(['mdadm', '--export', '--examine', '/dev/block/'+nodestr])))
if dev.holders:
mddir=sysclassblock+x+'/holders/'+dev.holders[0]+'/md/'
dev.MD_array_state = io.FileIO(mddir+'array_state').read().split("\n")[0]
dev.MD_array_size = io.FileIO(mddir+'array_size').read().split("\n")[0]
dev.MD_slot = io.FileIO(mddir+'dev-'+x+'/slot').read().split("\n")[0]
dev.MD_state = io.FileIO(mddir+'dev-'+x+'/state').read().split("\n")[0]
dev.FS = "MD %s (%s/%s) %s %s %s %s" % (dev.MD_LEVEL, dev.MD_slot, int(dev.MD_DEVICES), dev.size, dev.holders[0], dev.MD_array_state, dev.MD_state)
else:
dev.FS = "MD %s (%s) %s inactive" % (dev.MD_LEVEL, dev.MD_DEVICES, dev.size)
elif dev.ID_FS_TYPE and dev.ID_FS_TYPE[0:3] == 'LVM':
# Placeholder string for inactive physical volumes. It'll be
# overwritten when active PVs are scanned.
dev.FS = "PV %s (inactive)" % dev.ID_FS_TYPE
elif dev.ID_PART_TABLE_TYPE:
dev.FS = "Partitioned (%s) %s" % (dev.ID_PART_TABLE_TYPE, dev.size)
elif dev.ID_FS_TYPE:
dev.FS = "(%s) %s" % (dev.ID_FS_TYPE, dev.size)
else:
dev.FS = "Empty/Unknown %s" % dev.size
if dev.ID_FS_LABEL:
dev.FS += " '%s'" % dev.ID_FS_LABEL
if dev.ID_FS_UUID:
dev.FS += " {%s}" % dev.ID_FS_UUID
blockbyname[x] = dev
blockbynode[nodestr] = dev
#-------------------
# Collect information on mounted file systems and annotate the
# corresponding block device. Use the block device's major:minor node
# numbers, as the mount list often shows symlinks.
for x in io.FileIO('/proc/mounts').readlines():
if x[0:5] == '/dev/':
mdev, mnt = tuple(x.split(' ', 2)[0:2])
devstat = os.stat(mdev)
nodestr="%d:%d" % (os.major(devstat.st_rdev), os.minor(devstat.st_rdev))
if nodestr in blockbynode:
mntstat = os.statvfs(mnt)
dev = blockbynode[nodestr]
dev.mountdev = mdev
dev.mountpoint = mnt
dev.mountinfo = mntstat
#-------------------
# Collect information on LVM volumes and groups and annotate the
# corresponding block device. Use the block device's major:minor node
# numbers, as the mount list often shows symlinks.
vgroups = dict()
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"):
if x:
pv_name, pv_used, pv_size, pv_uuid, vg_name, vg_size, vg_free, vg_uuid = tuple(x.strip().split(' ',7))
devstat = os.stat(pv_name)
nodestr="%d:%d" % (os.major(devstat.st_rdev), os.minor(devstat.st_rdev))
if nodestr in blockbynode:
dev = blockbynode[nodestr]
dev.vg_name = vg_name
if not dev.hasLVM:
dev.hasLVM = True
dev.pv_used = pv_used
dev.pv_size = pv_size
dev.pv_uuid = pv_uuid
dev.FS = "PV %s %s/%s VG %s %s {%s}" % (dev.ID_FS_TYPE, pv_used, pv_size, vg_name, vg_size, pv_uuid)
if vg_name in vgroups:
vgroups[vg_name].PVs += [dev]
else:
vgroups[vg_name] = Struct(name=vg_name, size=vg_size, free=vg_free, uuid=vg_uuid, LVs=[], PVs=[dev])
for x in runx(['lvs', '-o', 'vg_name,lv_name,lv_path', '--noheadings', '--separator', ' ']).split("\n"):
if x:
vg_name, lv_name, lv_path = tuple(x.strip().split(' ',2))
devstat = os.stat(lv_path)
nodestr="%d:%d" % (os.major(devstat.st_rdev), os.minor(devstat.st_rdev))
if nodestr in blockbynode:
dev = blockbynode[nodestr]
dev.isLVM = True
dev.vg_name = vg_name
dev.__dict__.update(extractvars(runx(['lvs', '--rows', '-o', 'all', '--nameprefixes', '--noheadings', '--unquoted', lv_path])))
if vg_name in vgroups:
vgroups[vg_name].LVs += [dev]
else:
vgroups[vg_name] = Struct(name=vg_name, LVs=[dev], PVs=[])
def show_vgroup(indent, vg):
if vg.shown:
return
print "%s └─Volume Group %s (%s) %s free {%s}" % (indent, vg.name, ','.join([dev.name for dev in vg.PVs]), vg.free, vg.uuid)
show_blocks(indent+" ", vg.LVs)
vg.shown = True
#-------------------
# Given an indent level and list of block device names, recursively describe
# them.
continuation = ('│', '├')
corner = (' ', 'â””')
def show_blocks(indent, blocks):
blocks = [x for x in blocks if not x.shown]
for blk in blocks:
if blk == blocks[-1]:
branch=corner
else:
branch=continuation
print "%s %s─%s: %s" % (indent, branch[1], blk.name, blk.FS)
if blk.mountpoint:
print "%s %s └─Mounted as %s @ %s" % (indent, branch[0], blk.mountdev, blk.mountpoint)
elif blk.hasLVM:
show_vgroup(indent+" ", vgroups[blk.vg_name])
else:
subs = blk.partitions + blk.holders
subs.sort(natcmp)
if subs:
show_blocks("%s %s " % (indent, branch[0]), [blockbyname[x] for x in subs])
blk.shown = True
#-------------------
# Collect SCSI host / controller pairs from sysfs and create an ordered tree. Skip
# hosts that have targets, as they will already be in the list. Add empty physical
# device entries for hosts without targets.
scsidir = "/sys/bus/scsi/devices/"
scsilist = os.listdir(scsidir)
hosts = dict([(int(x[4:]), Struct(n=int(x[4:]), cpath=os.path.dirname(os.path.realpath(scsidir+x)), hpath='/'+x)) for x in scsilist if x[0:4]=='host'])
for n, host in hosts.items():
cntrlr = probe_controller(host.cpath)
if cntrlr :
targets = [x for x in os.listdir(host.cpath+host.hpath) if x[0:6]=='target']
if not targets:
phy = Struct(name='scsi %d:x:x:x [Empty]' % host.n)
cntrlr.units[phy.name] = phy
for cntrlr in controllers.values():
cntrlr.unitlist = cntrlr.units.keys()
if cntrlr.unitlist:
cntrlr.unitlist.sort(natcmp)
cntrlr.first = cntrlr.unitlist[0]
else:
cntrlr.first = ''
tree=[(cntrlr.first, cntrlr) for cntrlr in controllers.values()]
tree.sort(natcmp)
for f, cntrlr in tree:
print " ".join(cntrlr.descriptors)
if cntrlr.unitlist:
cntrlr.units[cntrlr.unitlist[-1]].last = True
branch = continuation
for key in cntrlr.unitlist:
phy = cntrlr.units[key]
if phy.last:
branch = corner
unitdetail = phy.name
if phy.vendor:
unitdetail += ' '+phy.vendor
if phy.model:
unitdetail += ' '+phy.model
if phy.serial:
unitdetail += " {%s}" % phy.serial.strip()
print ' %s─%s' % (branch[1], unitdetail)
if phy.block:
show_blocks(" %s " % branch[0], [phy.block])
unshown = [z.name for z in blockbynode.values() if z.size != '0.00k' and not z.shown]
unshown.sort(natcmp)
if unshown:
print "Other Block Devices"
show_blocks("", [blockbyname[x] for x in unshown])
^ permalink raw reply
* Re: [PATCH 7 of 9] MD: new sb type
From: NeilBrown @ 2011-05-26 0:34 UTC (permalink / raw)
To: Jonathan Brassow; +Cc: linux-raid
In-Reply-To: <2AE351EE-5C38-4C1B-B6A6-C9ABF5718E48@redhat.com>
On Wed, 25 May 2011 09:40:06 -0500 Jonathan Brassow <jbrassow@redhat.com>
wrote:
>
> On May 24, 2011, at 11:16 PM, NeilBrown wrote:
>
> >> + __le32 level;
> >> + __le32 new_level;
> >> +
> >> + __le32 layout;
> >> + __le32 new_layout;
> >> +
> >> + __le32 stripe_sectors;
> >> + __le32 new_stripe_sectors;
> >> +
> >> + __le32 num_devices; /* Number of devs in RAID, Max = 64 */
> >> + __le32 new_num_devices;
> >
> > Presumably the dm table knows all this info as well and it is just here for
> > error checking - yes?
>
> Error checking, yes... but a little bit more.
>
> If we keep this information in the superblock (instead of LVM metadata), then the act of reshaping is done like this:
> 1) initial RAID device created - LVM (or some other DM utilizing manager) records necessary info to re-instantiate this device.
> 2) A reshape (if LVM, 'lvconvert') is issued. LVM will record only the information about the new RAID layout. It will submit only this information to device-mapper (and on to MD) for further activations.
> The information in the superblock is then used to say, "ok, I see you passed in RAID6 information, but I was RAID5, so I must convert (or continue to convert)." Any new conversions while a conversion is in process are denied. So, it is relevant only so far as reshaping is concerned.
OK, that makes sense.
You could argue that the 'new' info is redundant because that is what is
provided in the dm table, but it probably make sense to keep it.
Thanks,
NeilBrown
>
> If we keep this information in the LVM metadata, the process becomes far more messy:
> 1) initial RAID device created
> 2) A reshape is issued. This time LVM must record all the information for both states - requiring additions to the LVM metadata layout, which in turn require new code for parsing and assembling this information as well as the code for turning it into something device-mapper can understand.
> 3) The reshape issued to device-mapper would require a new constructor, destructor, and status functions in dm-raid.c specifically for reshape scenarios.
> 4) An event would have to be raised when the reshape is complete in order to inform LVM to complete the reshape action (i.e. remove the intermediate metadata and write the final metadata describing the end product). This requires new plug-ins for the 'dmeventd' daemon, and of course, new LVM code to be able to convert from the hybrid device to the final device. And what happens if the daemon is hung, segfaulting, or just not there? The final change-over doesn't complete. If this is followed by a machine reboot, LVM will have no way of knowing whether the process was never begun or whether it was finished - reshape_offset doesn't help in this case.
> This is a truly horrible way to go...
>
> I've cleaned up the other items you mentioned. Of course, depending on which way we go regarding analyze_sbs, the bulk of these super functions may be pushed into dm-raid.c.
>
> brassow
^ permalink raw reply
* Re: [PATCH 2 of 9] MD: should_read_superblock
From: NeilBrown @ 2011-05-26 0:32 UTC (permalink / raw)
To: Jonathan Brassow; +Cc: linux-raid
In-Reply-To: <99ECF7E7-26F0-4613-9269-2BB91EBBF54C@redhat.com>
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??
NeilBrown
^ permalink raw reply
* Re: Can not start md0 after upgrade.
From: Stan Hoeppner @ 2011-05-25 21:57 UTC (permalink / raw)
To: John McMonagle; +Cc: linux-raid
In-Reply-To: <201105251521.15679.johnm@advocap.org>
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.
--
Stan
^ permalink raw reply
* Re: Can not start md0 after upgrade.
From: John McMonagle @ 2011-05-25 20:21 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DDD22C7.2000501@hardwarefreak.com>
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.
John
I just did another attempt.
After it failing I did the following from the
^ permalink raw reply
* Re: Can not start md0 after upgrade.
From: Stan Hoeppner @ 2011-05-25 15:39 UTC (permalink / raw)
To: John McMonagle; +Cc: linux-raid
In-Reply-To: <201105251006.30945.johnm@advocap.org>
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
^ permalink raw reply
* Re: disable raid autodetect at boot
From: Alexander Lyakas @ 2011-05-25 15:15 UTC (permalink / raw)
To: Michael Tokarev; +Cc: linux-raid
In-Reply-To: <4DDA5F51.3090501@msgid.tls.msk.ru>
Michael,
thank you for your advice.
The only place where I saw mdadm is being called on boot is via
/etc/init.d/mdadm, which starts mdadm with --monitor --scan options.
Still I disabled the daemon start (in /etc/default/mdadm), but
inactive raid keeps reappearing on boot.
How can I find out who else might be calling mdadm on boot?
Thanks,
Alex.
On Mon, May 23, 2011 at 4:21 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 23.05.2011 16:50, Alexander Lyakas wrote:
>> Michael,
>> can you pls explain what do I need to look at to disable this.
>
>> On Mon, May 23, 2011 at 1:35 PM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
>>> This is not kernel autodetection, this is your initramfs/initrd
>>> and mdadm. Or maybe mdadm in the regular root filesystem.
>
> You need to find out where and how mdadm is called
> on your system during bootup, and fix that place.
>
> /mjt
>
--
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.
From: John McMonagle @ 2011-05-25 15:06 UTC (permalink / raw)
To: Stan Hoeppner; +Cc: linux-raid
In-Reply-To: <4DDD1828.2020306@hardwarefreak.com>
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?
John
^ permalink raw reply
* Re: Can not start md0 after upgrade.
From: Stan Hoeppner @ 2011-05-25 14:54 UTC (permalink / raw)
To: John McMonagle; +Cc: linux-raid
In-Reply-To: <201105250819.27372.johnm@advocap.org>
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.
--
Stan
^ permalink raw reply
* Re: [PATCH 7 of 9] MD: new sb type
From: Jonathan Brassow @ 2011-05-25 14:40 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110525141645.24e8fe29@notabene.brown>
On May 24, 2011, at 11:16 PM, NeilBrown wrote:
>> + __le32 level;
>> + __le32 new_level;
>> +
>> + __le32 layout;
>> + __le32 new_layout;
>> +
>> + __le32 stripe_sectors;
>> + __le32 new_stripe_sectors;
>> +
>> + __le32 num_devices; /* Number of devs in RAID, Max = 64 */
>> + __le32 new_num_devices;
>
> Presumably the dm table knows all this info as well and it is just here for
> error checking - yes?
Error checking, yes... but a little bit more.
If we keep this information in the superblock (instead of LVM metadata), then the act of reshaping is done like this:
1) initial RAID device created - LVM (or some other DM utilizing manager) records necessary info to re-instantiate this device.
2) A reshape (if LVM, 'lvconvert') is issued. LVM will record only the information about the new RAID layout. It will submit only this information to device-mapper (and on to MD) for further activations.
The information in the superblock is then used to say, "ok, I see you passed in RAID6 information, but I was RAID5, so I must convert (or continue to convert)." Any new conversions while a conversion is in process are denied. So, it is relevant only so far as reshaping is concerned.
If we keep this information in the LVM metadata, the process becomes far more messy:
1) initial RAID device created
2) A reshape is issued. This time LVM must record all the information for both states - requiring additions to the LVM metadata layout, which in turn require new code for parsing and assembling this information as well as the code for turning it into something device-mapper can understand.
3) The reshape issued to device-mapper would require a new constructor, destructor, and status functions in dm-raid.c specifically for reshape scenarios.
4) An event would have to be raised when the reshape is complete in order to inform LVM to complete the reshape action (i.e. remove the intermediate metadata and write the final metadata describing the end product). This requires new plug-ins for the 'dmeventd' daemon, and of course, new LVM code to be able to convert from the hybrid device to the final device. And what happens if the daemon is hung, segfaulting, or just not there? The final change-over doesn't complete. If this is followed by a machine reboot, LVM will have no way of knowing whether the process was never begun or whether it was finished - reshape_offset doesn't help in this case.
This is a truly horrible way to go...
I've cleaned up the other items you mentioned. Of course, depending on which way we go regarding analyze_sbs, the bulk of these super functions may be pushed into dm-raid.c.
brassow
^ permalink raw reply
* Re: [PATCH 2 of 9] MD: should_read_superblock
From: Jonathan Brassow @ 2011-05-25 14:00 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20110525140157.497bebaf@notabene.brown>
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
^ permalink raw reply
* Can not start md0 after upgrade.
From: John McMonagle @ 2011-05-25 13:19 UTC (permalink / raw)
To: linux-raid
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
raid1 mptbase mptscsih and mptspi module are loaded.
Looks right but does not start md0.
Any ideas?
Thanks
John
^ 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