* help please, can't mount/recover raid 5 array
@ 2013-02-09 21:03 Daniel Sanabria
2013-02-09 23:00 ` Dave Cundiff
2013-02-10 6:29 ` Mikael Abrahamsson
0 siblings, 2 replies; 10+ messages in thread
From: Daniel Sanabria @ 2013-02-09 21:03 UTC (permalink / raw)
To: linux-raid
Hi,
I'm having issues with my raid 5 array after upgrading my os and I
have to say I'm desperate :-(
whenever I try to mount the array I get the following:
[root@lamachine ~]# mount /mnt/raid/
mount: /dev/sda3 is already mounted or /mnt/raid busy
[root@lamachine ~]#
and the messages log is recording the following:
Feb 9 20:25:10 lamachine kernel: [ 3887.287305] EXT4-fs (md2): VFS:
Can't find ext4 filesystem
Feb 9 20:25:10 lamachine kernel: [ 3887.304025] EXT4-fs (md2): VFS:
Can't find ext4 filesystem
Feb 9 20:25:10 lamachine kernel: [ 3887.320702] EXT4-fs (md2): VFS:
Can't find ext4 filesystem
Feb 9 20:25:10 lamachine kernel: [ 3887.353233] ISOFS: Unable to
identify CD-ROM format.
Feb 9 20:25:10 lamachine kernel: [ 3887.353571] FAT-fs (md2): invalid
media value (0x82)
Feb 9 20:25:10 lamachine kernel: [ 3887.368809] FAT-fs (md2): Can't
find a valid FAT filesystem
Feb 9 20:25:10 lamachine kernel: [ 3887.369140] hfs: can't find a HFS
filesystem on dev md2.
Feb 9 20:25:10 lamachine kernel: [ 3887.369665] hfs: unable to find
HFS+ superblock
/etc/fstab is as follows:
[root@lamachine ~]# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Feb 8 17:33:14 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/vg_bigblackbox-LogVol_root / ext4
defaults 1 1
UUID=7bee0f50-3e23-4a5b-bfb5-42006d6c8561 /boot ext4
defaults 1 2
UUID=48be851b-f021-0b64-e9fb-efdf24c84c5f /mnt/raid ext4 defaults 1 2
/dev/mapper/vg_bigblackbox-LogVol_opt /opt ext4
defaults 1 2
/dev/mapper/vg_bigblackbox-LogVol_tmp /tmp ext4
defaults 1 2
/dev/mapper/vg_bigblackbox-LogVol_var /var ext4
defaults 1 2
UUID=70933ff3-8ed0-4486-abf1-01f00023d1b2 swap swap
defaults 0 0
[root@lamachine ~]#
After the upgrade I had to assemble the array manually and didn't get
any errors but I was still getting the mount problem. I went ahead and
recreated it with mdadm --create --assume-clean and still the smae result.
here's some more info about md2:
[root@lamachine ~]# mdadm --misc --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sat Feb 9 17:30:32 2013
Raid Level : raid5
Array Size : 511996928 (488.28 GiB 524.28 GB)
Used Dev Size : 255998464 (244.14 GiB 262.14 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Sat Feb 9 20:47:46 2013
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : lamachine:2 (local to host lamachine)
UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f
Events : 2
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 18 1 active sync /dev/sdb2
2 8 34 2 active sync /dev/sdc2
[root@lamachine ~]#
it looks like it know about how much space is being used which might
indicate that the data is still there?
what can I do to recover the data?
Any help or guidance is more than welcome.
Thanks in advance,
Dan
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: help please, can't mount/recover raid 5 array 2013-02-09 21:03 help please, can't mount/recover raid 5 array Daniel Sanabria @ 2013-02-09 23:00 ` Dave Cundiff 2013-02-10 9:17 ` Daniel Sanabria 2013-02-10 6:29 ` Mikael Abrahamsson 1 sibling, 1 reply; 10+ messages in thread From: Dave Cundiff @ 2013-02-09 23:00 UTC (permalink / raw) To: Daniel Sanabria; +Cc: linux-raid On Sat, Feb 9, 2013 at 4:03 PM, Daniel Sanabria <sanabria.d@gmail.com> wrote: > Hi, > > I'm having issues with my raid 5 array after upgrading my os and I > have to say I'm desperate :-( > > whenever I try to mount the array I get the following: > > [root@lamachine ~]# mount /mnt/raid/ > mount: /dev/sda3 is already mounted or /mnt/raid busy > [root@lamachine ~]# > > and the messages log is recording the following: > > Feb 9 20:25:10 lamachine kernel: [ 3887.287305] EXT4-fs (md2): VFS: > Can't find ext4 filesystem > Feb 9 20:25:10 lamachine kernel: [ 3887.304025] EXT4-fs (md2): VFS: > Can't find ext4 filesystem > Feb 9 20:25:10 lamachine kernel: [ 3887.320702] EXT4-fs (md2): VFS: > Can't find ext4 filesystem > Feb 9 20:25:10 lamachine kernel: [ 3887.353233] ISOFS: Unable to > identify CD-ROM format. > Feb 9 20:25:10 lamachine kernel: [ 3887.353571] FAT-fs (md2): invalid > media value (0x82) > Feb 9 20:25:10 lamachine kernel: [ 3887.368809] FAT-fs (md2): Can't > find a valid FAT filesystem > Feb 9 20:25:10 lamachine kernel: [ 3887.369140] hfs: can't find a HFS > filesystem on dev md2. > Feb 9 20:25:10 lamachine kernel: [ 3887.369665] hfs: unable to find > HFS+ superblock > > /etc/fstab is as follows: > > [root@lamachine ~]# cat /etc/fstab > > # > # /etc/fstab > # Created by anaconda on Fri Feb 8 17:33:14 2013 > # > # Accessible filesystems, by reference, are maintained under '/dev/disk' > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info > # > /dev/mapper/vg_bigblackbox-LogVol_root / ext4 > defaults 1 1 > UUID=7bee0f50-3e23-4a5b-bfb5-42006d6c8561 /boot ext4 > defaults 1 2 > UUID=48be851b-f021-0b64-e9fb-efdf24c84c5f /mnt/raid ext4 defaults 1 2 > /dev/mapper/vg_bigblackbox-LogVol_opt /opt ext4 > defaults 1 2 > /dev/mapper/vg_bigblackbox-LogVol_tmp /tmp ext4 > defaults 1 2 > /dev/mapper/vg_bigblackbox-LogVol_var /var ext4 > defaults 1 2 > UUID=70933ff3-8ed0-4486-abf1-01f00023d1b2 swap swap > defaults 0 0 > [root@lamachine ~]# > > After the upgrade I had to assemble the array manually and didn't get > any errors but I was still getting the mount problem. I went ahead and > recreated it with mdadm --create --assume-clean and still the smae result. > > here's some more info about md2: > [root@lamachine ~]# mdadm --misc --detail /dev/md2 > /dev/md2: > Version : 1.2 > Creation Time : Sat Feb 9 17:30:32 2013 > Raid Level : raid5 > Array Size : 511996928 (488.28 GiB 524.28 GB) > Used Dev Size : 255998464 (244.14 GiB 262.14 GB) > Raid Devices : 3 > Total Devices : 3 > Persistence : Superblock is persistent > > Update Time : Sat Feb 9 20:47:46 2013 > State : clean > Active Devices : 3 > Working Devices : 3 > Failed Devices : 0 > Spare Devices : 0 > > Layout : left-symmetric > Chunk Size : 512K > > Name : lamachine:2 (local to host lamachine) > UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f > Events : 2 > > Number Major Minor RaidDevice State > 0 8 3 0 active sync /dev/sda3 > 1 8 18 1 active sync /dev/sdb2 > 2 8 34 2 active sync /dev/sdc2 > [root@lamachine ~]# > > it looks like it know about how much space is being used which might > indicate that the data is still there? > > what can I do to recover the data? > > Any help or guidance is more than welcome. > > Thanks in advance, > > Dan > -- > 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 What OS did you upgrade from and to? What OS was the array originally created on? Looks like you have LVM on top the of md array so the output of pvdisplay and vgdisplay would be useful. Did you specify metadata version when re-creating the array? Recreating the array at best changed the UUID, and depending on what OS the array was created on, overwrote the beginning of your partitions. -- Dave Cundiff System Administrator A2Hosting, Inc http://www.a2hosting.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-09 23:00 ` Dave Cundiff @ 2013-02-10 9:17 ` Daniel Sanabria 0 siblings, 0 replies; 10+ messages in thread From: Daniel Sanabria @ 2013-02-10 9:17 UTC (permalink / raw) To: Dave Cundiff; +Cc: linux-raid Hi Dave, The upgrade was from fedora 16 to fedora 17 and I think the array was created on F16 or F15. I didn't specify the metadata version when recreating :( Here's the output of pvdisplay and vgdisplay but I don't think I was using LVM here (i know this from an output of an old kickstart the anaconda-ks.cfg on f16): [root@lamachine ~]# [root@lamachine ~]# pvdisplay -v Scanning for physical volume names --- Physical volume --- PV Name /dev/md127 VG Name libvirt_lvm PV Size 90.00 GiB / not usable 3.50 MiB Allocatable yes PE Size 4.00 MiB Total PE 23038 Free PE 5630 Allocated PE 17408 PV UUID VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox --- Physical volume --- PV Name /dev/md126 VG Name vg_bigblackbox PV Size 29.30 GiB / not usable 3.94 MiB Allocatable yes PE Size 4.00 MiB Total PE 7499 Free PE 1499 Allocated PE 6000 PV UUID cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH [root@lamachine ~]# vgdisplay -v Finding all volume groups Finding volume group "libvirt_lvm" --- Volume group --- VG Name libvirt_lvm System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 8 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 89.99 GiB PE Size 4.00 MiB Total PE 23038 Alloc PE / Size 17408 / 68.00 GiB Free PE / Size 5630 / 21.99 GiB VG UUID t8GQck-f2Eu-iD2V-fnJQ-kBm6-QyKw-dR31PB --- Logical volume --- LV Path /dev/libvirt_lvm/win7 LV Name win7 VG Name libvirt_lvm LV UUID uJaz2L-jhCy-kOU2-klnM-i6P7-I13O-5D1u3d LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 25.00 GiB Current LE 6400 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 6144 Block device 253:1 --- Logical volume --- LV Path /dev/libvirt_lvm/cms_test LV Name cms_test VG Name libvirt_lvm LV UUID ix5PwP-Wket-9rAe-foq3-8hJY-jfVL-haCU6a LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 8.00 GiB Current LE 2048 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 6144 Block device 253:2 --- Logical volume --- LV Path /dev/libvirt_lvm/centos_updt LV Name centos_updt VG Name libvirt_lvm LV UUID vp1nAZ-jZmX-BqMb-fuEL-kkto-1d6X-a15ecI LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 8.00 GiB Current LE 2048 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 6144 Block device 253:3 --- Logical volume --- LV Path /dev/libvirt_lvm/cms LV Name cms VG Name libvirt_lvm LV UUID gInAgv-7LAQ-djtZ-Oc6P-xRME-dHU4-Wj885d LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 8.00 GiB Current LE 2048 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 6144 Block device 253:4 --- Logical volume --- LV Path /dev/libvirt_lvm/litp LV Name litp VG Name libvirt_lvm LV UUID dbev0d-b7Tx-WXro-fMvN-dcm6-SH5N-ylIdlS LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 19.00 GiB Current LE 4864 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 6144 Block device 253:5 --- Physical volumes --- PV Name /dev/md127 PV UUID VmsWRd-8qHt-bauf-lvAn-FC97-KyH5-gk89ox PV Status allocatable Total PE / Free PE 23038 / 5630 Finding volume group "vg_bigblackbox" --- Volume group --- VG Name vg_bigblackbox System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 5 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 4 Max PV 0 Cur PV 1 Act PV 1 VG Size 29.29 GiB PE Size 4.00 MiB Total PE 7499 Alloc PE / Size 6000 / 23.44 GiB Free PE / Size 1499 / 5.86 GiB VG UUID VWfuwI-5v2q-w8qf-FEbc-BdGW-3mKX-pZd7hR --- Logical volume --- LV Path /dev/vg_bigblackbox/LogVol_var LV Name LogVol_var VG Name vg_bigblackbox LV UUID 1NJcwG-01B4-6CSY-eijZ-bEES-Rcqd-tTM3ig LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 3.91 GiB Current LE 1000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:6 --- Logical volume --- LV Path /dev/vg_bigblackbox/LogVol_root LV Name LogVol_root VG Name vg_bigblackbox LV UUID VTBWT0-OdxR-R5bG-ZiTV-oZAp-8KX0-s9ziS8 LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 9.77 GiB Current LE 2500 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Path /dev/vg_bigblackbox/LogVol_opt LV Name LogVol_opt VG Name vg_bigblackbox LV UUID x8kbeS-erIn-X1oJ-5oXp-H2AK-HHHQ-Z3GnB1 LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 7.81 GiB Current LE 2000 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:7 --- Logical volume --- LV Path /dev/vg_bigblackbox/LogVol_tmp LV Name LogVol_tmp VG Name vg_bigblackbox LV UUID j8A2Rv-KNo9-MmBV-WMEw-snIu-cfWU-HXkvnM LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 1.95 GiB Current LE 500 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:8 --- Physical volumes --- PV Name /dev/md126 PV UUID cE4ePh-RWO8-Wgdy-YPOY-ehyC-KI6u-io1cyH PV Status allocatable Total PE / Free PE 7499 / 1499 [root@lamachine ~]# here's the output of the old kickstart file: $ cat anaconda-ks.cfg # Kickstart file automatically generated by anaconda. #version=DEVEL install lang en_US.UTF-8 keyboard uk network --onboot yes --device p20p1 --bootproto dhcp --noipv6 --hostname lamachine timezone --utc Europe/London rootpw --iscrypted $6$Ue9iCKeAVqBBTb24$mZFg.v4BjFAM/gD8FOaZBPTu.7PLixoZNWVsa6L65eHl1aON3m.CmTB7ni1gnuH7KqUzG2UPmCOyPEocdByh.1 selinux --enforcing authconfig --enableshadow --passalgo=sha512 firewall --service=ssh # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --none #part --onpart=sdc6 --noformat #part raid.008037 --onpart=sdc5 --noformat #part raid.008034 --onpart=sdc2 --noformat #part raid.008033 --onpart=sdc1 --noformat #part --onpart=sdb6 --noformat #part raid.008021 --onpart=sdb5 --noformat #part swap --onpart=sdb3 --noformat #part raid.008018 --onpart=sdb2 --noformat #part --onpart=sda6 --noformat #part raid.008005 --onpart=sda5 --noformat #raid pv.009003 --level=0 --device=md3 --useexisting --noformat raid.008005 raid.008021 raid.008037 #volgroup libvirt_lvm --pesize=4096 --useexisting --noformat pv.009003 #logvol --name=win7 --vgname=libvirt_lvm --useexisting --noformat #logvol --name=litp --vgname=libvirt_lvm --useexisting --noformat #logvol --name=cms_test --vgname=libvirt_lvm --useexisting --noformat #logvol --name=cms --vgname=libvirt_lvm --useexisting --noformat #logvol --name=centos_updt --vgname=libvirt_lvm --useexisting --noformat #part raid.008003 --onpart=sda3 --noformat #raid /home --fstype=ext4 --level=5 --device=md2 --useexisting --noformat raid.008003 raid.008018 raid.008034 #part raid.008002 --onpart=sda2 --noformat #raid pv.009001 --level=10 --device=md1 --useexisting --noformat raid.008002 raid.008033 #volgroup vg_bigblackbox --pesize=4096 --useexisting --noformat pv.009001 #logvol /var --fstype=ext4 --name=LogVol_var --vgname=vg_bigblackbox --useexisting #logvol /tmp --fstype=ext4 --name=LogVol_tmp --vgname=vg_bigblackbox --useexisting #logvol / --fstype=ext4 --name=LogVol_root --vgname=vg_bigblackbox --useexisting #logvol /opt --fstype=ext4 --name=LogVol_opt --vgname=vg_bigblackbox --useexisting #part /boot --fstype=ext4 --onpart=sda1 bootloader --location=mbr --timeout=5 --driveorder=sda,sdb,sdc --append="nomodeset quiet rhgb" repo --name="Fedora 16 - x86_64" --baseurl=http://mirror.bytemark.co.uk/fedora/linux/releases/16/Everything/x86_64/os/ --cost=1000 repo --name="Fedora 16 - x86_64 - Updates" --baseurl=http://mirror.bytemark.co.uk/fedora/linux/updates/16/x86_64/ --cost=1000 %packages @core @online-docs @virtualization python-libguestfs virt-top libguestfs-tools guestfs-browser %end $ Regards, Daniel On 9 February 2013 23:00, Dave Cundiff <syshackmin@gmail.com> wrote: > On Sat, Feb 9, 2013 at 4:03 PM, Daniel Sanabria <sanabria.d@gmail.com> wrote: >> Hi, >> >> I'm having issues with my raid 5 array after upgrading my os and I >> have to say I'm desperate :-( >> >> whenever I try to mount the array I get the following: >> >> [root@lamachine ~]# mount /mnt/raid/ >> mount: /dev/sda3 is already mounted or /mnt/raid busy >> [root@lamachine ~]# >> >> and the messages log is recording the following: >> >> Feb 9 20:25:10 lamachine kernel: [ 3887.287305] EXT4-fs (md2): VFS: >> Can't find ext4 filesystem >> Feb 9 20:25:10 lamachine kernel: [ 3887.304025] EXT4-fs (md2): VFS: >> Can't find ext4 filesystem >> Feb 9 20:25:10 lamachine kernel: [ 3887.320702] EXT4-fs (md2): VFS: >> Can't find ext4 filesystem >> Feb 9 20:25:10 lamachine kernel: [ 3887.353233] ISOFS: Unable to >> identify CD-ROM format. >> Feb 9 20:25:10 lamachine kernel: [ 3887.353571] FAT-fs (md2): invalid >> media value (0x82) >> Feb 9 20:25:10 lamachine kernel: [ 3887.368809] FAT-fs (md2): Can't >> find a valid FAT filesystem >> Feb 9 20:25:10 lamachine kernel: [ 3887.369140] hfs: can't find a HFS >> filesystem on dev md2. >> Feb 9 20:25:10 lamachine kernel: [ 3887.369665] hfs: unable to find >> HFS+ superblock >> >> /etc/fstab is as follows: >> >> [root@lamachine ~]# cat /etc/fstab >> >> # >> # /etc/fstab >> # Created by anaconda on Fri Feb 8 17:33:14 2013 >> # >> # Accessible filesystems, by reference, are maintained under '/dev/disk' >> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info >> # >> /dev/mapper/vg_bigblackbox-LogVol_root / ext4 >> defaults 1 1 >> UUID=7bee0f50-3e23-4a5b-bfb5-42006d6c8561 /boot ext4 >> defaults 1 2 >> UUID=48be851b-f021-0b64-e9fb-efdf24c84c5f /mnt/raid ext4 defaults 1 2 >> /dev/mapper/vg_bigblackbox-LogVol_opt /opt ext4 >> defaults 1 2 >> /dev/mapper/vg_bigblackbox-LogVol_tmp /tmp ext4 >> defaults 1 2 >> /dev/mapper/vg_bigblackbox-LogVol_var /var ext4 >> defaults 1 2 >> UUID=70933ff3-8ed0-4486-abf1-01f00023d1b2 swap swap >> defaults 0 0 >> [root@lamachine ~]# >> >> After the upgrade I had to assemble the array manually and didn't get >> any errors but I was still getting the mount problem. I went ahead and >> recreated it with mdadm --create --assume-clean and still the smae result. >> >> here's some more info about md2: >> [root@lamachine ~]# mdadm --misc --detail /dev/md2 >> /dev/md2: >> Version : 1.2 >> Creation Time : Sat Feb 9 17:30:32 2013 >> Raid Level : raid5 >> Array Size : 511996928 (488.28 GiB 524.28 GB) >> Used Dev Size : 255998464 (244.14 GiB 262.14 GB) >> Raid Devices : 3 >> Total Devices : 3 >> Persistence : Superblock is persistent >> >> Update Time : Sat Feb 9 20:47:46 2013 >> State : clean >> Active Devices : 3 >> Working Devices : 3 >> Failed Devices : 0 >> Spare Devices : 0 >> >> Layout : left-symmetric >> Chunk Size : 512K >> >> Name : lamachine:2 (local to host lamachine) >> UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f >> Events : 2 >> >> Number Major Minor RaidDevice State >> 0 8 3 0 active sync /dev/sda3 >> 1 8 18 1 active sync /dev/sdb2 >> 2 8 34 2 active sync /dev/sdc2 >> [root@lamachine ~]# >> >> it looks like it know about how much space is being used which might >> indicate that the data is still there? >> >> what can I do to recover the data? >> >> Any help or guidance is more than welcome. >> >> Thanks in advance, >> >> Dan >> -- >> 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 > > What OS did you upgrade from and to? What OS was the array originally > created on? > > Looks like you have LVM on top the of md array so the output of > pvdisplay and vgdisplay would be useful. > > Did you specify metadata version when re-creating the array? > Recreating the array at best changed the UUID, and depending on what > OS the array was created on, overwrote the beginning of your > partitions. > > -- > Dave Cundiff > System Administrator > A2Hosting, Inc > http://www.a2hosting.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-09 21:03 help please, can't mount/recover raid 5 array Daniel Sanabria 2013-02-09 23:00 ` Dave Cundiff @ 2013-02-10 6:29 ` Mikael Abrahamsson [not found] ` <CAHscji0h5nHUssKi23BMfR=Ek+jSH+vK0odYNWkzrVDf6t18mw@mail.gmail.com> 1 sibling, 1 reply; 10+ messages in thread From: Mikael Abrahamsson @ 2013-02-10 6:29 UTC (permalink / raw) To: linux-raid On Sat, 9 Feb 2013, Daniel Sanabria wrote: > After the upgrade I had to assemble the array manually and didn't get > any errors but I was still getting the mount problem. I went ahead and > recreated it with mdadm --create --assume-clean and still the smae > result. Did you save mdadm --examine from the drives *before* you did this? -- Mikael Abrahamsson email: swmike@swm.pp.se ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAHscji0h5nHUssKi23BMfR=Ek+jSH+vK0odYNWkzrVDf6t18mw@mail.gmail.com>]
* Re: help please, can't mount/recover raid 5 array [not found] ` <CAHscji0h5nHUssKi23BMfR=Ek+jSH+vK0odYNWkzrVDf6t18mw@mail.gmail.com> @ 2013-02-10 9:36 ` Daniel Sanabria 2013-02-10 21:05 ` Phil Turmel 0 siblings, 1 reply; 10+ messages in thread From: Daniel Sanabria @ 2013-02-10 9:36 UTC (permalink / raw) To: Mikael Abrahamsson, linux-raid to the whole list this time ... Thanks, Daniel On 10 February 2013 09:17, Daniel Sanabria <sanabria.d@gmail.com> wrote: > Hi Mikael, > > Yes I did. Here it is: > > [root@lamachine ~]# mdadm --examine /dev/sd* > /dev/sda: > MBR Magic : aa55 > Partition[0] : 407552 sectors at 2048 (type 83) > Partition[1] : 61440000 sectors at 409663 (type fd) > Partition[2] : 512000000 sectors at 61849663 (type fd) > Partition[3] : 402918402 sectors at 573849663 (type 05) > mdadm: No md superblock detected on /dev/sda1. > /dev/sda2: > Magic : a92b4efc > Version : 0.90.00 > UUID : 9af006ca:8845bbd3:bfe78010:bc810f04 > Creation Time : Thu Dec 3 22:12:12 2009 > Raid Level : raid10 > Used Dev Size : 30719936 (29.30 GiB 31.46 GB) > Array Size : 30719936 (29.30 GiB 31.46 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 126 > > Update Time : Sat Feb 9 17:21:45 2013 > State : clean > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > Checksum : e6d627b3 - correct > Events : 263120 > > Layout : near=2 > Chunk Size : 64K > > Number Major Minor RaidDevice State > this 0 8 2 0 active sync /dev/sda2 > > 0 0 8 2 0 active sync /dev/sda2 > 1 1 8 33 1 active sync /dev/sdc1 > /dev/sda3: > Magic : a92b4efc > Version : 0.90.00 > UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 > Creation Time : Thu Dec 3 22:12:24 2009 > Raid Level : raid5 > Used Dev Size : 255999936 (244.14 GiB 262.14 GB) > Array Size : 511999872 (488.28 GiB 524.29 GB) > Raid Devices : 3 > Total Devices : 3 > Preferred Minor : 2 > > Update Time : Sat Feb 9 16:09:20 2013 > State : clean > Active Devices : 3 > Working Devices : 3 > Failed Devices : 0 > Spare Devices : 0 > Checksum : 8dd157e5 - correct > Events : 792552 > > Layout : left-symmetric > Chunk Size : 64K > > Number Major Minor RaidDevice State > this 0 8 3 0 active sync /dev/sda3 > > 0 0 8 3 0 active sync /dev/sda3 > 1 1 8 18 1 active sync /dev/sdb2 > 2 2 8 34 2 active sync /dev/sdc2 > /dev/sda4: > MBR Magic : aa55 > Partition[0] : 62918679 sectors at 63 (type 83) > Partition[1] : 7116795 sectors at 82453782 (type 05) > /dev/sda5: > Magic : a92b4efc > Version : 1.2 > Feature Map : 0x0 > Array UUID : acd5374f:72628c93:6a906c4b:5f675ce5 > Name : reading.homeunix.com:3 > Creation Time : Tue Jul 26 19:00:28 2011 > Raid Level : raid0 > Raid Devices : 3 > > Avail Dev Size : 62916631 (30.00 GiB 32.21 GB) > Data Offset : 2048 sectors > Super Offset : 8 sectors > State : clean > Device UUID : 5778cd64:0bbba183:ef3270a8:41f83aca > > Update Time : Tue Jul 26 19:00:28 2011 > Checksum : 96003cba - correct > Events : 0 > > Chunk Size : 512K > > Device Role : Active device 0 > Array State : AAA ('A' == active, '.' == missing) > mdadm: No md superblock detected on /dev/sda6. > /dev/sdb: > MBR Magic : aa55 > Partition[1] : 512000000 sectors at 409663 (type fd) > Partition[2] : 16384000 sectors at 512409663 (type 82) > Partition[3] : 447974402 sectors at 528793663 (type 05) > /dev/sdb2: > Magic : a92b4efc > Version : 0.90.00 > UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 > Creation Time : Thu Dec 3 22:12:24 2009 > Raid Level : raid5 > Used Dev Size : 255999936 (244.14 GiB 262.14 GB) > Array Size : 511999872 (488.28 GiB 524.29 GB) > Raid Devices : 3 > Total Devices : 3 > Preferred Minor : 2 > > Update Time : Sat Feb 9 16:09:20 2013 > State : clean > Active Devices : 3 > Working Devices : 3 > Failed Devices : 0 > Spare Devices : 0 > Checksum : 8dd157f6 - correct > Events : 792552 > > Layout : left-symmetric > Chunk Size : 64K > > Number Major Minor RaidDevice State > this 1 8 18 1 active sync /dev/sdb2 > > 0 0 8 3 0 active sync /dev/sda3 > 1 1 8 18 1 active sync /dev/sdb2 > 2 2 8 34 2 active sync /dev/sdc2 > mdadm: No md superblock detected on /dev/sdb3. > /dev/sdb4: > MBR Magic : aa55 > Partition[0] : 62912354 sectors at 63 (type 83) > Partition[1] : 7116795 sectors at 82447457 (type 05) > /dev/sdb5: > Magic : a92b4efc > Version : 1.2 > Feature Map : 0x0 > Array UUID : acd5374f:72628c93:6a906c4b:5f675ce5 > Name : reading.homeunix.com:3 > Creation Time : Tue Jul 26 19:00:28 2011 > Raid Level : raid0 > Raid Devices : 3 > > Avail Dev Size : 62910306 (30.00 GiB 32.21 GB) > Data Offset : 2048 sectors > Super Offset : 8 sectors > State : clean > Device UUID : 152d0202:64efb3e7:f23658c3:82a239a1 > > Update Time : Tue Jul 26 19:00:28 2011 > Checksum : 892dbb61 - correct > Events : 0 > > Chunk Size : 512K > > Device Role : Active device 1 > Array State : AAA ('A' == active, '.' == missing) > mdadm: No md superblock detected on /dev/sdb6. > /dev/sdc: > MBR Magic : aa55 > Partition[0] : 61440000 sectors at 63 (type fd) > Partition[1] : 512000000 sectors at 61440063 (type fd) > Partition[2] : 403328002 sectors at 573440063 (type 05) > /dev/sdc1: > Magic : a92b4efc > Version : 0.90.00 > UUID : 9af006ca:8845bbd3:bfe78010:bc810f04 > Creation Time : Thu Dec 3 22:12:12 2009 > Raid Level : raid10 > Used Dev Size : 30719936 (29.30 GiB 31.46 GB) > Array Size : 30719936 (29.30 GiB 31.46 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 126 > > Update Time : Sat Feb 9 17:21:45 2013 > State : clean > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > Checksum : e6d627d4 - correct > Events : 263120 > > Layout : near=2 > Chunk Size : 64K > > Number Major Minor RaidDevice State > this 1 8 33 1 active sync /dev/sdc1 > > 0 0 8 2 0 active sync /dev/sda2 > 1 1 8 33 1 active sync /dev/sdc1 > /dev/sdc2: > Magic : a92b4efc > Version : 0.90.00 > UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 > Creation Time : Thu Dec 3 22:12:24 2009 > Raid Level : raid5 > Used Dev Size : 255999936 (244.14 GiB 262.14 GB) > Array Size : 511999872 (488.28 GiB 524.29 GB) > Raid Devices : 3 > Total Devices : 3 > Preferred Minor : 2 > > Update Time : Sat Feb 9 16:09:20 2013 > State : clean > Active Devices : 3 > Working Devices : 3 > Failed Devices : 0 > Spare Devices : 0 > Checksum : 8dd15808 - correct > Events : 792552 > > Layout : left-symmetric > Chunk Size : 64K > > Number Major Minor RaidDevice State > this 2 8 34 2 active sync /dev/sdc2 > > 0 0 8 3 0 active sync /dev/sda3 > 1 1 8 18 1 active sync /dev/sdb2 > 2 2 8 34 2 active sync /dev/sdc2 > /dev/sdc3: > MBR Magic : aa55 > Partition[0] : 62910589 sectors at 63 (type 83) > Partition[1] : 7116795 sectors at 82445692 (type 05) > /dev/sdc5: > Magic : a92b4efc > Version : 1.2 > Feature Map : 0x0 > Array UUID : acd5374f:72628c93:6a906c4b:5f675ce5 > Name : reading.homeunix.com:3 > Creation Time : Tue Jul 26 19:00:28 2011 > Raid Level : raid0 > Raid Devices : 3 > > Avail Dev Size : 62908541 (30.00 GiB 32.21 GB) > Data Offset : 2048 sectors > Super Offset : 8 sectors > State : clean > Device UUID : a0efc1b3:94cc6eb8:deea76ca:772b2d2d > > Update Time : Tue Jul 26 19:00:28 2011 > Checksum : 9eba9119 - correct > Events : 0 > > Chunk Size : 512K > > Device Role : Active device 2 > Array State : AAA ('A' == active, '.' == missing) > mdadm: No md superblock detected on /dev/sdc6. > [root@lamachine ~]# > > Regards, > > Daniel > > On 10 February 2013 06:29, Mikael Abrahamsson <swmike@swm.pp.se> wrote: >> On Sat, 9 Feb 2013, Daniel Sanabria wrote: >> >>> After the upgrade I had to assemble the array manually and didn't get any >>> errors but I was still getting the mount problem. I went ahead and recreated >>> it with mdadm --create --assume-clean and still the smae result. >> >> >> Did you save mdadm --examine from the drives *before* you did this? >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> -- >> 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 [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-10 9:36 ` Daniel Sanabria @ 2013-02-10 21:05 ` Phil Turmel 2013-02-10 22:01 ` Dave Cundiff 0 siblings, 1 reply; 10+ messages in thread From: Phil Turmel @ 2013-02-10 21:05 UTC (permalink / raw) To: Daniel Sanabria; +Cc: Mikael Abrahamsson, linux-raid Hi Daniel, On 02/10/2013 04:36 AM, Daniel Sanabria wrote: > On 10 February 2013 09:17, Daniel Sanabria <sanabria.d@gmail.com> wrote: >> Hi Mikael, >> >> Yes I did. Here it is: [trim /] >> /dev/sda3: >> Magic : a92b4efc >> Version : 0.90.00 =====================^^^^^^^ >> UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 >> Creation Time : Thu Dec 3 22:12:24 2009 >> Raid Level : raid5 >> Used Dev Size : 255999936 (244.14 GiB 262.14 GB) >> Array Size : 511999872 (488.28 GiB 524.29 GB) >> Raid Devices : 3 >> Total Devices : 3 >> Preferred Minor : 2 >> >> Update Time : Sat Feb 9 16:09:20 2013 >> State : clean >> Active Devices : 3 >> Working Devices : 3 >> Failed Devices : 0 >> Spare Devices : 0 >> Checksum : 8dd157e5 - correct >> Events : 792552 >> >> Layout : left-symmetric >> Chunk Size : 64K =====================^^^ >> >> Number Major Minor RaidDevice State >> this 0 8 3 0 active sync /dev/sda3 >> >> 0 0 8 3 0 active sync /dev/sda3 >> 1 1 8 18 1 active sync /dev/sdb2 >> 2 2 8 34 2 active sync /dev/sdc2 From your original post: > /dev/md2: > Version : 1.2 ====================^^^ > Creation Time : Sat Feb 9 17:30:32 2013 > Raid Level : raid5 > Array Size : 511996928 (488.28 GiB 524.28 GB) > Used Dev Size : 255998464 (244.14 GiB 262.14 GB) > Raid Devices : 3 > Total Devices : 3 > Persistence : Superblock is persistent > > Update Time : Sat Feb 9 20:47:46 2013 > State : clean > Active Devices : 3 > Working Devices : 3 > Failed Devices : 0 > Spare Devices : 0 > > Layout : left-symmetric > Chunk Size : 512K ====================^^^^ > > Name : lamachine:2 (local to host lamachine) > UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f > Events : 2 > > Number Major Minor RaidDevice State > 0 8 3 0 active sync /dev/sda3 > 1 8 18 1 active sync /dev/sdb2 > 2 8 34 2 active sync /dev/sdc2 I don't know what possessed you to use "mdadm --create" to try to fix your system, but it is almost always the wrong first step. But since you scrambled it with "mdadm --create", you'll have to fix it with "mdadm --create". mdadm --stop /dev/md2 mdadm --create --assume-clean /dev/md2 --metadata=0.90 \ --level=5 --raid-devices=3 --chunk=64 \ /dev/sda3 /dev/sdb2 /dev/sdc2 Then, you will have to reconstruct the beginning of the array, as much as 3MB worth, that was replaced with v1.2 metadata. (The used dev size differs by 1472kB, suggesting that the new mdadm gave you a new data offset of 2048, and the rest is the difference in the chunk size.) Your original report and follow-ups have not clearly indicated what is on this 524GB array, so I can't be more specific. If it is a filesystem, an fsck may fix it with modest losses. If it is another LVM PV, you may be able to do a vgrestore to reset the 1st megabyte. You didn't activate a bitmap on the array, so the remainder of the new metadata space was probably untouched. HTH, Phil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-10 21:05 ` Phil Turmel @ 2013-02-10 22:01 ` Dave Cundiff 2013-02-11 12:49 ` Daniel Sanabria 0 siblings, 1 reply; 10+ messages in thread From: Dave Cundiff @ 2013-02-10 22:01 UTC (permalink / raw) To: Phil Turmel; +Cc: Daniel Sanabria, Mikael Abrahamsson, linux-raid On Sun, Feb 10, 2013 at 4:05 PM, Phil Turmel <philip@turmel.org> wrote: > Hi Daniel, > > On 02/10/2013 04:36 AM, Daniel Sanabria wrote: >> On 10 February 2013 09:17, Daniel Sanabria <sanabria.d@gmail.com> wrote: >>> Hi Mikael, >>> >>> Yes I did. Here it is: > > [trim /] > >>> /dev/sda3: >>> Magic : a92b4efc >>> Version : 0.90.00 > > =====================^^^^^^^ > >>> UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 >>> Creation Time : Thu Dec 3 22:12:24 2009 >>> Raid Level : raid5 >>> Used Dev Size : 255999936 (244.14 GiB 262.14 GB) >>> Array Size : 511999872 (488.28 GiB 524.29 GB) >>> Raid Devices : 3 >>> Total Devices : 3 >>> Preferred Minor : 2 >>> >>> Update Time : Sat Feb 9 16:09:20 2013 >>> State : clean >>> Active Devices : 3 >>> Working Devices : 3 >>> Failed Devices : 0 >>> Spare Devices : 0 >>> Checksum : 8dd157e5 - correct >>> Events : 792552 >>> >>> Layout : left-symmetric >>> Chunk Size : 64K > > =====================^^^ > >>> >>> Number Major Minor RaidDevice State >>> this 0 8 3 0 active sync /dev/sda3 >>> >>> 0 0 8 3 0 active sync /dev/sda3 >>> 1 1 8 18 1 active sync /dev/sdb2 >>> 2 2 8 34 2 active sync /dev/sdc2 > > From your original post: > >> /dev/md2: >> Version : 1.2 > > ====================^^^ > >> Creation Time : Sat Feb 9 17:30:32 2013 >> Raid Level : raid5 >> Array Size : 511996928 (488.28 GiB 524.28 GB) >> Used Dev Size : 255998464 (244.14 GiB 262.14 GB) >> Raid Devices : 3 >> Total Devices : 3 >> Persistence : Superblock is persistent >> >> Update Time : Sat Feb 9 20:47:46 2013 >> State : clean >> Active Devices : 3 >> Working Devices : 3 >> Failed Devices : 0 >> Spare Devices : 0 >> >> Layout : left-symmetric >> Chunk Size : 512K > > ====================^^^^ > >> >> Name : lamachine:2 (local to host lamachine) >> UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f >> Events : 2 >> >> Number Major Minor RaidDevice State >> 0 8 3 0 active sync /dev/sda3 >> 1 8 18 1 active sync /dev/sdb2 >> 2 8 34 2 active sync /dev/sdc2 > > I don't know what possessed you to use "mdadm --create" to try to fix > your system, but it is almost always the wrong first step. But since > you scrambled it with "mdadm --create", you'll have to fix it with > "mdadm --create". > > mdadm --stop /dev/md2 > > mdadm --create --assume-clean /dev/md2 --metadata=0.90 \ > --level=5 --raid-devices=3 --chunk=64 \ > /dev/sda3 /dev/sdb2 /dev/sdc2 > It looks like your using a dracut based boot system. Once you get the array created and mounting you'll need to update /etc/mdadm.conf with the new array information and run dracut to update your initrd with the new configuration. If not problems could crop up down the road. > Then, you will have to reconstruct the beginning of the array, as much > as 3MB worth, that was replaced with v1.2 metadata. (The used dev size > differs by 1472kB, suggesting that the new mdadm gave you a new data > offset of 2048, and the rest is the difference in the chunk size.) > > Your original report and follow-ups have not clearly indicated what is > on this 524GB array, so I can't be more specific. If it is a > filesystem, an fsck may fix it with modest losses. > > If it is another LVM PV, you may be able to do a vgrestore to reset the > 1st megabyte. You didn't activate a bitmap on the array, so the > remainder of the new metadata space was probably untouched. > If the data on this array is important and without backups it would be a good idea to image the drives before you start doing anything else. Most of your data can likely be recovered but you can easily destroy it beyond conventional repair if your not very careful at this point. According to the fstab in the original post it looks like its just an ext4 filesystem on top of the md. If that is the case an fsck should get you going again after creating the array. You can try a regular fsck but your superblock is most likely gone. A backup superblock if needed is generally accessible by adding -b 32768 to the fsck. Hopefully you didn't have many files in the root of that filesystem. They are all most likely going to end up as random numbered files and directories in lost+found. -- Dave Cundiff System Administrator A2Hosting, Inc http://www.a2hosting.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-10 22:01 ` Dave Cundiff @ 2013-02-11 12:49 ` Daniel Sanabria 2013-02-11 16:30 ` Mikael Abrahamsson 0 siblings, 1 reply; 10+ messages in thread From: Daniel Sanabria @ 2013-02-11 12:49 UTC (permalink / raw) To: Dave Cundiff; +Cc: Phil Turmel, Mikael Abrahamsson, linux-raid Thanks a million Guys !!! I re-created the RAID and fsck it and it's mounting fine now. The array is my /home partition and I can't see any significant losses. But I'm still not sure what happened, I mean what consideration should I take next time I upgrade? Thanks again, Daniel On 10 February 2013 22:01, Dave Cundiff <syshackmin@gmail.com> wrote: > On Sun, Feb 10, 2013 at 4:05 PM, Phil Turmel <philip@turmel.org> wrote: >> Hi Daniel, >> >> On 02/10/2013 04:36 AM, Daniel Sanabria wrote: >>> On 10 February 2013 09:17, Daniel Sanabria <sanabria.d@gmail.com> wrote: >>>> Hi Mikael, >>>> >>>> Yes I did. Here it is: >> >> [trim /] >> >>>> /dev/sda3: >>>> Magic : a92b4efc >>>> Version : 0.90.00 >> >> =====================^^^^^^^ >> >>>> UUID : 0deb6f79:aec7ed69:bfe78010:bc810f04 >>>> Creation Time : Thu Dec 3 22:12:24 2009 >>>> Raid Level : raid5 >>>> Used Dev Size : 255999936 (244.14 GiB 262.14 GB) >>>> Array Size : 511999872 (488.28 GiB 524.29 GB) >>>> Raid Devices : 3 >>>> Total Devices : 3 >>>> Preferred Minor : 2 >>>> >>>> Update Time : Sat Feb 9 16:09:20 2013 >>>> State : clean >>>> Active Devices : 3 >>>> Working Devices : 3 >>>> Failed Devices : 0 >>>> Spare Devices : 0 >>>> Checksum : 8dd157e5 - correct >>>> Events : 792552 >>>> >>>> Layout : left-symmetric >>>> Chunk Size : 64K >> >> =====================^^^ >> >>>> >>>> Number Major Minor RaidDevice State >>>> this 0 8 3 0 active sync /dev/sda3 >>>> >>>> 0 0 8 3 0 active sync /dev/sda3 >>>> 1 1 8 18 1 active sync /dev/sdb2 >>>> 2 2 8 34 2 active sync /dev/sdc2 >> >> From your original post: >> >>> /dev/md2: >>> Version : 1.2 >> >> ====================^^^ >> >>> Creation Time : Sat Feb 9 17:30:32 2013 >>> Raid Level : raid5 >>> Array Size : 511996928 (488.28 GiB 524.28 GB) >>> Used Dev Size : 255998464 (244.14 GiB 262.14 GB) >>> Raid Devices : 3 >>> Total Devices : 3 >>> Persistence : Superblock is persistent >>> >>> Update Time : Sat Feb 9 20:47:46 2013 >>> State : clean >>> Active Devices : 3 >>> Working Devices : 3 >>> Failed Devices : 0 >>> Spare Devices : 0 >>> >>> Layout : left-symmetric >>> Chunk Size : 512K >> >> ====================^^^^ >> >>> >>> Name : lamachine:2 (local to host lamachine) >>> UUID : 48be851b:f0210b64:e9fbefdf:24c84c5f >>> Events : 2 >>> >>> Number Major Minor RaidDevice State >>> 0 8 3 0 active sync /dev/sda3 >>> 1 8 18 1 active sync /dev/sdb2 >>> 2 8 34 2 active sync /dev/sdc2 >> >> I don't know what possessed you to use "mdadm --create" to try to fix >> your system, but it is almost always the wrong first step. But since >> you scrambled it with "mdadm --create", you'll have to fix it with >> "mdadm --create". >> >> mdadm --stop /dev/md2 >> >> mdadm --create --assume-clean /dev/md2 --metadata=0.90 \ >> --level=5 --raid-devices=3 --chunk=64 \ >> /dev/sda3 /dev/sdb2 /dev/sdc2 >> > > It looks like your using a dracut based boot system. Once you get the > array created and mounting you'll need to update /etc/mdadm.conf with > the new array information and run dracut to update your initrd with > the new configuration. If not problems could crop up down the road. > >> Then, you will have to reconstruct the beginning of the array, as much >> as 3MB worth, that was replaced with v1.2 metadata. (The used dev size >> differs by 1472kB, suggesting that the new mdadm gave you a new data >> offset of 2048, and the rest is the difference in the chunk size.) >> >> Your original report and follow-ups have not clearly indicated what is >> on this 524GB array, so I can't be more specific. If it is a >> filesystem, an fsck may fix it with modest losses. >> >> If it is another LVM PV, you may be able to do a vgrestore to reset the >> 1st megabyte. You didn't activate a bitmap on the array, so the >> remainder of the new metadata space was probably untouched. >> > > If the data on this array is important and without backups it would be > a good idea to image the drives before you start doing anything else. > Most of your data can likely be recovered but you can easily destroy > it beyond conventional repair if your not very careful at this point. > > According to the fstab in the original post it looks like its just an > ext4 filesystem on top of the md. If that is the case an fsck should > get you going again after creating the array. You can try a regular > fsck but your superblock is most likely gone. A backup superblock if > needed is generally accessible by adding -b 32768 to the fsck. > Hopefully you didn't have many files in the root of that filesystem. > They are all most likely going to end up as random numbered files and > directories in lost+found. > > > -- > Dave Cundiff > System Administrator > A2Hosting, Inc > http://www.a2hosting.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-11 12:49 ` Daniel Sanabria @ 2013-02-11 16:30 ` Mikael Abrahamsson 2013-02-11 16:39 ` Daniel Sanabria 0 siblings, 1 reply; 10+ messages in thread From: Mikael Abrahamsson @ 2013-02-11 16:30 UTC (permalink / raw) To: Daniel Sanabria; +Cc: linux-raid On Mon, 11 Feb 2013, Daniel Sanabria wrote: > Thanks a million Guys !!! I re-created the RAID and fsck it and it's > mounting fine now. The array is my /home partition and I can't see any > significant losses. But I'm still not sure what happened, I mean what > consideration should I take next time I upgrade? First of all: --create --assume-clean is a huge big enormous hammer. It shouldn't be used unless absolutely necessary, when all other options are exhausted. I am not aware of any gotchas when upgrading, I have done it numerous times, even moved array drives between machines, and it's worked well so far. From your information there isn't really any way to tell what happened. So best way before next upgrade is to save mdadm --examine and hope it works properly (it should). If it doesn't, please send an email to the list with as much information as possible (mdadm --examine, dmesg etc) and see where that leads before using the big hammer. -- Mikael Abrahamsson email: swmike@swm.pp.se ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: help please, can't mount/recover raid 5 array 2013-02-11 16:30 ` Mikael Abrahamsson @ 2013-02-11 16:39 ` Daniel Sanabria 0 siblings, 0 replies; 10+ messages in thread From: Daniel Sanabria @ 2013-02-11 16:39 UTC (permalink / raw) To: Mikael Abrahamsson; +Cc: linux-raid Sure, Thanks again Mikael. Daniel On 11 February 2013 16:30, Mikael Abrahamsson <swmike@swm.pp.se> wrote: > On Mon, 11 Feb 2013, Daniel Sanabria wrote: > >> Thanks a million Guys !!! I re-created the RAID and fsck it and it's >> mounting fine now. The array is my /home partition and I can't see any >> significant losses. But I'm still not sure what happened, I mean what >> consideration should I take next time I upgrade? > > > First of all: --create --assume-clean is a huge big enormous hammer. It > shouldn't be used unless absolutely necessary, when all other options are > exhausted. > > I am not aware of any gotchas when upgrading, I have done it numerous times, > even moved array drives between machines, and it's worked well so far. From > your information there isn't really any way to tell what happened. > > So best way before next upgrade is to save mdadm --examine and hope it works > properly (it should). If it doesn't, please send an email to the list with > as much information as possible (mdadm --examine, dmesg etc) and see where > that leads before using the big hammer. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-02-11 16:39 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-09 21:03 help please, can't mount/recover raid 5 array Daniel Sanabria
2013-02-09 23:00 ` Dave Cundiff
2013-02-10 9:17 ` Daniel Sanabria
2013-02-10 6:29 ` Mikael Abrahamsson
[not found] ` <CAHscji0h5nHUssKi23BMfR=Ek+jSH+vK0odYNWkzrVDf6t18mw@mail.gmail.com>
2013-02-10 9:36 ` Daniel Sanabria
2013-02-10 21:05 ` Phil Turmel
2013-02-10 22:01 ` Dave Cundiff
2013-02-11 12:49 ` Daniel Sanabria
2013-02-11 16:30 ` Mikael Abrahamsson
2013-02-11 16:39 ` Daniel Sanabria
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).