Search Results

Search found 242 results on 10 pages for 'mdadm'.

Page 4/10 | < Previous Page | 1 2 3 4 5 6 7 8 9 10  | Next Page >

• How do I align my partition table properly?

  - by Jorge Castro

  I am in the process of building my first RAID5 array. I've used mdadm to create the following set up: root@bondigas:~# mdadm --detail /dev/md1 /dev/md1: Version : 00.90 Creation Time : Wed Oct 20 20:00:41 2010 Raid Level : raid5 Array Size : 5860543488 (5589.05 GiB 6001.20 GB) Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Wed Oct 20 20:13:48 2010 State : clean, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 1% complete UUID : f6dc829e:aa29b476:edd1ef19:85032322 (local to host bondigas) Events : 0.12 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 2 8 48 2 active sync /dev/sdd 4 8 64 3 spare rebuilding /dev/sde While that's going I decided to format the beast with the following command: root@bondigas:~# mkfs.ext4 /dev/md1p1 mke2fs 1.41.11 (14-Mar-2010) /dev/md1p1 alignment is offset by 63488 bytes. This may result in very poor performance, (re)-partitioning suggested. Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=16 blocks, Stripe width=48 blocks 97853440 inodes, 391394047 blocks 19569702 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 11945 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: ^C 27/11945 root@bondigas:~# ^C I am unsure what to do about "/dev/md1p1 alignment is offset by 63488 bytes." and how to properly partition the disks to match so I can format it properly.

  Read the article

• How do I align my partition table properly?

  - by Jorge Castro

  I am in the process of building my first RAID5 array. I've used mdadm to create the following set up: root@bondigas:~# mdadm --detail /dev/md1 /dev/md1: Version : 00.90 Creation Time : Wed Oct 20 20:00:41 2010 Raid Level : raid5 Array Size : 5860543488 (5589.05 GiB 6001.20 GB) Used Dev Size : 1953514496 (1863.02 GiB 2000.40 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Wed Oct 20 20:13:48 2010 State : clean, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 1% complete UUID : f6dc829e:aa29b476:edd1ef19:85032322 (local to host bondigas) Events : 0.12 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 2 8 48 2 active sync /dev/sdd 4 8 64 3 spare rebuilding /dev/sde While that's going I decided to format the beast with the following command: root@bondigas:~# mkfs.ext4 /dev/md1p1 mke2fs 1.41.11 (14-Mar-2010) /dev/md1p1 alignment is offset by 63488 bytes. This may result in very poor performance, (re)-partitioning suggested. Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=16 blocks, Stripe width=48 blocks 97853440 inodes, 391394047 blocks 19569702 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 11945 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: ^C 27/11945 root@bondigas:~# ^C I am unsure what to do about "/dev/md1p1 alignment is offset by 63488 bytes." and how to properly partition the disks to match so I can format it properly.

  Read the article

• missing files after reassemble of RAID-5

  - by Kris_R

  I had to open my file-server's housing on Sunday to replace a faulty fan. What I didn't see was that one of the sata-cables was not properly connected. The 1st thing I did after a reboot was a check of the RAID status and it showed immediately that one drive is missing. Till this moment the device was not used (however it was mounted, so I'm not 100% sure that system did nothing). I stopped md0 and re-plugged the cable: mdadm --stop /dev/md0 poweroff After another reboot I checked the removed drive: mdadm --examine /dev/sdd1 ... Checksum : 3276bc1d - correct Events : 315782 Layout : left-symmetric Chunk Size : 32K Number Major Minor RaidDevice State this 0 8 49 0 active sync /dev/sdd1 0 0 8 49 0 active sync /dev/sdd1 1 1 8 65 1 active sync /dev/sde1 2 2 8 33 2 active sync /dev/sdc1 3 3 8 17 3 active sync /dev/sdb1 I was a bit surprised that it was shown as active (even if earlier mdadm said, that this device was removed from array) and its checksum was OK. I recreated RAID with: mdadm --assemble /dev/md0 --scan The command mdadm --detail /dev/md0 showed that all drives were running and system was in "clean" state. I mounted the device md0 and then came hic-cup. I wanted to work on one of the last files that I had been using before all the situation and it was not there. In another place I missed actually all files from the directory where I was working. As far as I can see most of the files that are older than a few days are intact but some newer ones are missing. Now the big question: what would be your advice? Is there a way to get these data? I thought about removing the drive that was earlier labeled by mdadm and rebuild array with another empty HDD. I've found that after re-assemble the "broken" drive has another label (changed from sdd to sdb). Can this have influence on rebuilt process? If yes, how to reassemble the array properly? I'm sure the SATA-cables are connected still in the same order to the controller. p.s. Please no advises like "restore from backup". I'm doing back-ups on Sunday's night and this happened in the late afternoon, so backup is not really options for me. p.s.s. I asked this question on Unix&Linux but no answer came up during last two days. I'm getting quite anxious. Sorry for duplicating if any of you reading the other forum.

  Read the article

• Path of md device wrong after reboot

  - by flammi88

  I have to set up a software raid (level1) on a Ubuntu server 12.04. It should serve files in the network via Samba. The server has the following disks: 250gb Sata hdd (Ubuntu is installed on that drive) 2 TB Sata hdd (first disk in raid array, data disk) 2 TB Sata hdd (second data disk) I created one partition on every data disk with the type Linux raid autodetect. In the second step I created the raid1 with the following command: mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1 After that, I added the array to the mdconf: mdadm --examine --scan >> /etc/mdadm/mdadm.conf The problem is: After a reboot the array is not available on the path /dev/md0. Instead of that it gets reassembled as /dev/md/0 but it is not very reliable. Has anybody a solution for this issue?

  Read the article

• How to create a software raid5 array without a spare

  - by Yannick M.

  I am trying to create a software raid5 array using mdadm: $ linux # mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --spare-devices=0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 64K mdadm: array /dev/md0 started. However when inspecting /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdd1[4] sdc1[2] sdb1[1] sda1[0] 2930279808 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] [>....................] recovery = 0.3% (2970496/976759936) finish=186.1min speed=87172K/sec unused devices: <none> It seems one drive isn't active, so I check the details of the array: /dev/md0: Version : 00.90.03 Creation Time : Tue Jul 21 16:29:53 2009 Raid Level : raid5 Array Size : 2930279808 (2794.53 GiB 3000.61 GB) Used Dev Size : 976759936 (931.51 GiB 1000.20 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Jul 21 16:29:53 2009 State : clean, degraded, recovering Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 0% complete UUID : ce8b2f40:821d003c:0027688e:a70977ec Events : 0.1 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 17 1 active sync /dev/sdb1 2 8 33 2 active sync /dev/sdc1 4 8 49 3 spare rebuilding /dev/sdd1 And it seems there are only 3 active devices, with one spare. Is it just me, or something wrong here?

  Read the article

• DegradedArray event on /dev/md0 without actually having a RAID

  - by J. Stoever

  Since I upgraded from Ubuntu LTS 10 to LTS 12, I have been getting error messages like: N 60 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md2:Ubuntu-1004-lucid-64-minimal N 61 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md0:Ubuntu-1004-lucid-64-minimal N 62 mdadm monitoring Mon Sep 3 06:38 31/1022 DegradedArray event on /dev/md1:Ubuntu-1004-lucid-64-minimal We do not have a RAID setup, and only have a single hard drive. Ideas ?

  Read the article

• LVM incorrectly reported missing after power failure

  - by mensi

  We have had a major power failure in the data-center. We are using a set of servers for our storage needs. The main server has several pairs of disks mirrored with mdadm. The resulting /dev/mdX are LVM physical volumes and belong to a big volume-group with all our data. After the powerloss, we had the problem that one of the mdadm devices was not auto-detected due to a missing entry in mdadm.conf. As a consequence, the volumegroup had inactive logical volumes due to the missing PV. We were able to fix the mdadm config and reboot. pvscan shows all expected PVs but one LV still does not come up. vgdisplay shows: [...] Cur PV: 3 Act PV: 2 [...] Neither vgscan nor pvscan show any missing devices. What went wrong? How can we force LVM to activate all PVs?

  Read the article

• System won't boot unless I type "exit" at initramfs prompt

  - by Ozzah

  I installed MDADM for my RAID, and ever since that when I boot up the system just sits at the purple screen forever. After pulling my hair out for a week, I finally discovered - purely by accident - that it's sitting at an initramfs prompt in the background and I have to blindly type "exit" and then Ubuntu resumes normal boot. How do I fix this? I am unable to reboot my machine if I'm not sitting in front of it because it will never boot!

  Read the article

• Ubuntu 13.10 software raid

  - by Piotr Belniak

  I had already Ubuntu OS installed on my desktop PC, where the software RAID 5 is configured ( 3 partitions /, swap and home ). This system was upgraded from the 11.04 till 13.04, it was quite messy, so I decided to install fresh system on existing partitions. 1st of all i found that there is no alternate version of the installer ( which i used to create previous installation ), so i stared with the regular image. I installed mdadm tools, assemble the partitions - fdisk are showing them properly - so i'm starting the installation - and everything i going fine until the GRUB instalation - this part fails - regardless of which partition i use as a target. From the other hand, neither OpenSUse and Ubuntu 12.04 alternate does not have any problems with installing the GRUB - on this configuration, unfortunatelly Ubuntu 12.04 - 12.10 upgrade is failing bacause of some Xorg issues ;(. Maybe someone has an experience with installation of ubuntu 13.10 GRUB on the RAID 5 partitions - and could give me a hint, how to solve my problem. Thanks in advance, Piotr

  Read the article

• How to restruct RAID 10?

  - by user276851

  We would like to alter the partition without losing data. Here is the sketch of the plan. I am wondering if it is doable using mdadm; and if so, please kindly point some reference on how to carry out the following steps. For RAID 10, there are four disks used. (1 2)(3 4) The idea is to work on 1 and 3 while keeping 2 and 4 as backup. 1: break RAID 10 into two arrays of RAID 0 => (1 3) (2 4) (how to?) 2: re-partition and format (1 3) 3: copy data from (2 4) to (1 3) 4: re-partition and format (2 4) exactly as (1 3) 5: join (2 4) with (1 3) to form RAID 10 (how to?) Does it sound doable? Thanks a lot! Add: It looks like this guy (drumfile) is doing something similar, but lack of enough detail.

  Read the article

• Unneeded RAID recovery

  - by Shinhan

  I have two software RAID 5s. Today when I turned on my server (after it was off for two weeks when I was on vacation), I got the message that the software RAID is degraded and was offered RAID recovery console or boot degraded. No idea what to do in that recovery console btw, so I just exited it. After the boot finished normally I took a peak at /proc/mdstat but there is nothing amiss there. So I took a look at mdadm --detail /dev/md0 (and md1) and again everything looks fine with Failed Devices being 0 both times. Next I took a look at smartctl --alll /dev/sdX for all of the drives and Reallocated_Sector_Ct is 0. (Lots of other zeros, all numbers look to me fine) Anybody have any ideas why I'm getting the RAID recovery message on boot when nothing seems bad?

  Read the article

• Software Raid 10 corrupted superblock after dual disk failure, how do I recover it?

  - by Shoshomiga

  I have a software raid 10 with 6 x 2tb hard drives (raid 1 for /boot), ubuntu 10.04 is the os. I had a raid controller failure that put 2 drives out of sync, crashed the system and initially the os didnt boot up and went into initramfs instead, saying that drives were busy but I eventually managed to bring the raid up by stopping and assembling the drives. The os booted up and said that there were filesystem errors, I chose to ignore because it would remount the fs in read-only mode if there was a problem. Everything seemed to be working fine and the 2 drives started to rebuild, I was sure that it was a sata controller failure because I had dma errors in my log files. The os crashed soon after that with ext errors. Now its not bringing up the raid, it says that there is no superblock on /dev/sda2, even if I assemble manually with all the device names. I also did a memtest and changed the motherboard in addition to everything else. EDIT: This is my partition layout Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x0009c34a Device Boot Start End Blocks Id System /dev/sdb1 * 2048 511999 254976 83 Linux /dev/sdb2 512000 3904980991 1952234496 83 Linux /dev/sdb3 3904980992 3907028991 1024000 82 Linux swap / Solaris All 6 disks have the same layout, partition #1 is for raid 1 /boot, partition #2 is for raid 10 far plan, partition #3 is swap, but sda did not have swap enabled EDIT2: This is the output of mdadm --detail /dev/md1 Layout : near=1, far=2 Chunk Size : 64k UUID : a0feff55:2018f8ff:e368bf24:bd0fce41 Events : 0.3112126 Number Major Minor RaidDevice State 0 8 34 0 spare rebuilding /dev/sdc2 1 0 0 1 removed 2 8 18 2 active sync /dev/sdb2 3 8 50 3 active sync /dev/sdd2 4 0 0 4 removed 5 8 82 5 active sync /dev/sdf2 6 8 66 - spare /dev/sde2 EDIT3: I ran ddrescue and it has copied everything from sda except a single 4096 byte sector that I suspect is the raid superblock EDIT4: Here is some more info too long to fit here lshw: http://pastebin.com/2eKrh7nF mdadm --detail /dev/sd[abcdef]1 (raid1): http://pastebin.com/cgMQWerS mdadm --detail /dev/sd[abcdef]2 (raid10): http://pastebin.com/V5dtcGPF dumpe2fs of /dev/sda2 (from the ddrescue cloned drive): http://pastebin.com/sp0GYcJG I tried to recreate md1 based on this info with the command mdadm --create /dev/md1 -v --assume-clean --level=10 --raid-devices=6 --chunk=64K --layout=f2 /dev/sda2 missing /dev/sdc2 /dev/sdd2 missing /dev/sdf2 But I can't mount it, I also tried to recreate it based on my initial mdadm --detail /dev/md1 but it still doesn't mount It also warns me that /dev/sda2 is an ext2fs file system but I guess its because of ddrescue

  Read the article

• Linux software RAID6: 3 drives offline - how to force online?

  - by Ole Tange

  This is similar to 3 drives fell out of Raid6 mdadm - rebuilding? except that it is not due to a failing cable. Instead the 3rd drive fell offline during rebuild of another drive. The drive failed with: kernel: end_request: I/O error, dev sdc, sector 293732432 kernel: md/raid:md0: read error not correctable (sector 293734224 on sdc). After rebooting both these sectors and the sectors around them are fine. This leads me to believe the error is intermittent and thus the device simply took too long to error correct the sector and remap it. I expect that no data was written to the RAID after it failed. Therefore I hope that if I can kick the last failing device online that the RAID is fine and that the xfs_filesystem is OK, maybe with a few missing recent files. Taking a backup of the disks in the RAID takes 24 hours, so I would prefer that the solution works the first time. I have therefore set up a test scenario: export PRE=3 parallel dd if=/dev/zero of=/tmp/raid${PRE}{} bs=1k count=1000k ::: 1 2 3 4 5 parallel mknod /dev/loop${PRE}{} b 7 ${PRE}{} \; losetup /dev/loop${PRE}{} /tmp/raid${PRE}{} ::: 1 2 3 4 5 mdadm --create /dev/md$PRE -c 4096 --level=6 --raid-devices=5 /dev/loop${PRE}[12345] cat /proc/mdstat mkfs.xfs -f /dev/md$PRE mkdir -p /mnt/disk2 umount -l /mnt/disk2 mount /dev/md$PRE /mnt/disk2 seq 1000 | parallel -j1 mkdir -p /mnt/disk2/{}\;cp /bin/* /mnt/disk2/{}\;sleep 0.5 & mdadm --fail /dev/md$PRE /dev/loop${PRE}3 /dev/loop${PRE}4 cat /proc/mdstat # Assume reboot so no process is using the dir kill %1; sync & kill %1; sync & # Force fail one too many mdadm --fail /dev/md$PRE /dev/loop${PRE}1 parallel --tag -k mdadm -E ::: /dev/loop${PRE}? | grep Upda # loop 2,5 are newest. loop1 almost newest => force add loop1 Next step is to add loop1 back - and this is where I am stuck. After that do a xfs-consistency check. When that works, check that the solution also works on real devices (such a 4 USB sticks).

  Read the article

• MD RAID 1 with external bitmap doesn't fully resync

  - by user64744

  I have an interesting configuration: dual boot system with a RAID 1 that needs to be visible in both Windows and Linux. The Windows install is Win 7 Enterprise, and the Linux install is Kubuntu 10.04. To get the RAID to work, I set it up using Windows's "Dynamic Disks" RAID 1, and brought it up in Linux using MD with no persistent superblock, and a write-intent bitmap on another partition. (Without this bitmap, MD had no way of knowing that the array was in sync, and would do a complete resync every time the array started.) The array is assembled like so: mdadm --build /dev/md1 -l 1 -n 2 -b /var/local/md1.bitmap /dev/sdb2 /dev/sdc2 I expected that the first time I ran this command, it would resync the array, write out a bitmap with no dirty chunks, and all would be good. This wasn't the case: after completing the resync, the bitmap was mostly clean, but about 5% dirty blocks remained, as revealed by mdadm -X /var/local/md1.bitmap I didn't mount the filesystem on /dev/md1 or touch it in any other way. I then found that stopping and restarting the array: mdadm --stop /dev/md1 mdadm --build /dev/md1 -l 1 -n 2 -b /var/local/md1.bitmap /dev/sdb2 /dev/sdc2 did indeed read in the bitmap, with an ensuing resync that went quickly because most of the blocks were marked clean. The confusing part is that this resync further reduced the number of dirty blocks, but still did not remove all of them. By repeatedly stopping and restarting I could slowly bring the dirty block count down to around 0.6%, where it seemed to level out. Any ideas what could be causing this? It smells to me of a race condition somewhere that leads to blocks either being skipped over during synchronization or not properly cleared from the bitmap, but I really have no evidence to prove this. It doesn't look like hardware issues since both drives are new and have zero read errors and reallocated sectors reported by smartctl -a.

  Read the article

• Degraded RAID-5 array with lvm2 lost superblock and partition table

  - by Fred Phillips

  I have a RAID-5 array of 4x1TB hard disks with one lvm2 partition on Ubuntu Linux 10.04 LTS. One of the disks has failed. I have re-assembled the array without this failed disk but now mdadm --examine claims the array has no superblock and fdisk says it has no partition table. What can I do to recover the data? # mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sat Mar 5 14:43:49 2011 Raid Level : raid5 Array Size : 2930276352 (2794.53 GiB 3000.60 GB) Used Dev Size : 976758784 (931.51 GiB 1000.20 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Update Time : Sat Mar 5 15:06:49 2011 State : clean, degraded Active Devices : 3 Working Devices : 3 Failed Devices : 1 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : boba:1 (local to host boba) UUID : 52eb4bc9:c3d8aab5:e0699505:e0e1aa05 Events : 18 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 65 1 active sync /dev/sde1 2 8 49 2 active sync /dev/sdd1 3 0 0 3 removed 4 8 17 - faulty spare /dev/sdb1 # mdadm --examine /dev/md0 mdadm: No md superblock detected on /dev/md0. # fdisk -l /dev/md0 Disk /dev/md0: 3000.6 GB, 3000602984448 bytes 2 heads, 4 sectors/track, 732569088 cylinders Units = cylinders of 8 * 512 = 4096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1572864 bytes Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] md0 : active raid5 sdb1[4](F) sda1[0] sdd1[2] sde1[1] 2930276352 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_] unused devices: <none>

  Read the article

• Use old raid drive as boot device without data loss

  - by Gabriel

  There were two disks in sw-raid. There were /dev/md1 as swap, /dev/md2 as boot and a /dev/md3 with ext4. The sw-raid was disabled by stopping and removing mdadm and then zeroing the superblock on each /dev/mdX partition with: sudo mdadm --zero-superblock /dev/sda1 sudo mdadm --zero-superblock /dev/sda2 sudo mdadm --zero-superblock /dev/sda3 In the disk that is the first boot device, I don't know if it's relevant, the system type of each partition was set back from fd to 82 or 83 with fdisk, /etc/fstab was updated, changing /dev/mdX to /dev/sdaX, and grub was reinstalled on the boot partition (/dev/sda2) with grub-instal. But the system wont boot. What else should I do to use this disk as the boot device without reinstall or data loss? Current output of fdisk Device Boot Start End Blocks Id System /dev/sda1 2048 33556480 16777216+ 82 Linux swap / Solaris /dev/sda2 * 33558528 34607104 524288+ 83 Linux /dev/sda3 34609152 3907027120 1936208984+ 83 Linux With it doesn't boot I mean that it stops in the grub console (with the grub> symbol). A ls command says: (hd0) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1) It's weird because hd1 was formatted with ext4...

  Read the article

• Can a non-redundant RAID5 cause any serious problems (compared to RAID0)?

  - by leemes

  I used to have a three-disc RAID5 (mdadm) in my computer for personal media storage (music, videos, photos, programs, games, ...). It had three discs with 750 GB each, resulting in an array capacity of 1.5 TB. One day (one year ago), I needed one of those discs to install another operating system. I thought, I don't need the redundancy anymore since I backup the most important stuff (personal photos e.g.) on an external disc anyway. So I decided to remove one of the three discs without converting the RAID to RAID0 or even two separate discs, because I had no temporary storage (since one cannot simply convert the RAID5 to RAID0 AFAIK). So now, for about one year, I have a non-redundant RAID5 with 2 of 3 discs running. Sometimes, one of the discs has a defective contact at the power cable or something similar causing the drive to stop working temporarily (I don't know exactly what it is). Since it still works when rebooting the computer and in most cases by calling some mdadm commands, it wasn't that problematic. Note that the data is not very critical, since I still have a backup of the most important stuff. But in the last few weeks, one of the drives fails very frequently (every few hours), so it gets really annoying to manage this. My questions are: Is there any disadvantage (apart from the annoying management) of a non-redundant RAID5 (with one drive less than typical) over a RAID0? If I understand it correctly, both have no redundancy and the same capacity. On a temporary drive failure, I can restart the array in both cases, assuming that the drive itself still works after the failure. Can it happen that the drive contents alter on a drive failure, making the array inconsistent? If so, can I tell mdadm to check the array for failures (without a file system level checking tool)? Since the drive most probably only has a defective contact causing it to fail for a second only, can I tell mdadm to automatically restart the array, so I will not even notice the failure if no application wanted to access the file system during the failure?

  Read the article

• LUKS no longer accepts my my passphrase

  - by Two Spirit

  I created a 4 drive RAID5 setup using mdadm and upgrading from 2TB drives to the new Hitachi 7200RPM 4TB drives. I can initially open my luks partition, but later can no longer access it. I can no longer access my LUKS partition even tho I have the right passphrases. It was working and then at an unknown point in time loose access to LUKS. I've used the same procedures for upgrading from 500G to 1TB to 1.5TB to 2TB. After the first time this happened a week ago, I thought maybe there was some corruption so I added a 2nd Key as a backup. After the second time the LUKS became unaccessible, none of the keys worked. I put LUKS on it using cryptsetup -c aes -s 256 -y luksFormat /dev/md0 # cryptsetup luksOpen /dev/md0 md0_crypt Enter LUKS passphrase: Enter LUKS passphrase: Enter LUKS passphrase: Command failed: No key available with this passphrase. The first time this happened while I was upgrading to 4TB drives, I thought it was a fluke, and ultimately had to recover from backups. I went an used luksAddKey to add a 2nd key as a backup. It happened again and I tried both passphrases, and neither worked. The only thing I'm doing differently this time around is that I've upgraded to 4TB drives which use GPT instead of fdisk. The last time I had to even reboot the box was over 2 years ago. I'm using ubuntu-8.04-server with kernel 2.6.24-29 and upgraded to -2.6.24-31, but that didn't fix the problem.

  Read the article

• Must partprobe before using drive?

  - by Jeff Welling

  This is a followup question to Cannot mount /dev/sdc1 on Debian 5.0, special device /dev/sdc1 doesn't exist Basically, I have 6 SATA hard drives in a machine and I'm trying to create a RAID6 array with them. When I try to run the mdadm command to create (with the verbose option) a raid array, I see messages like "mdadm: super1.x cannot open /dev/sdf1: No such device or address" which are resolved by doing partprobe /dev/sdf and then re-running the mdadm command. The problem is that I have to run partprobe after each reboot, and from experience I don't think this is normal behaviour -- on no other linux machine do I have to partprobe the device before I can use it. Something must be going wrong, but how do I troubleshoot this to find out what? Could this be caused by a hardware problem? Edit: Additional note - before I seemed to only have this problem with one drive, but now I'm having it with 3 drives.

  Read the article

• How to add new partition to RAID-1 array on Redhat FC10?

  - by Peter Scott

  I have a RH FC10 system with RAID 1 partitions, here is mdadm.conf: # mdadm.conf written out by anaconda DEVICE partitions MAILADDR root ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90 UUID=9588bfe1:ddfd5858:1067c814:ac499922 ARRAY /dev/md3 level=raid1 num-devices=2 metadata=0.90 UUID=3895ca46:c1526588:d48acd7e:c153aa83 ARRAY /dev/md4 level=raid1 num-devices=2 metadata=0.90 UUID=ebd4920f:b46c1f18:2eced24a:a21ca861 ARRAY /dev/md2 level=raid1 num-devices=2 metadata=0.90 UUID=048e8198:5d6d9682:d3a1e5c3:d475ad80 ARRAY /dev/md0 level=raid1 num-devices=2 metadata=0.90 UUID=d89ec2de:079d4be5:e00ee8f5:fcb19188 I want to carve off 500MB from md4 to make a new partition (for an AFS cache). I haven't touched mdadm or any other disk partitioning tools in years. md4 is 50GB and less than 10% used. What's the easiest way of doing this?

  Read the article

• Recover RAID 5 data after created new array instead of re-using

  - by Brigadieren

  Folks please help - I am a newb with a major headache at hand (perfect storm situation). I have a 3 1tb hdd on my ubuntu 11.04 configured as software raid 5. The data had been copied weekly onto another separate off the computer hard drive until that completely failed and was thrown away. A few days back we had a power outage and after rebooting my box wouldn't mount the raid. In my infinite wisdom I entered mdadm --create -f... command instead of mdadm --assemble and didn't notice the travesty that I had done until after. It started the array degraded and proceeded with building and syncing it which took ~10 hours. After I was back I saw that that the array is successfully up and running but the raid is not I mean the individual drives are partitioned (partition type f8 ) but the md0 device is not. Realizing in horror what I have done I am trying to find some solutions. I just pray that --create didn't overwrite entire content of the hard driver. Could someone PLEASE help me out with this - the data that's on the drive is very important and unique ~10 years of photos, docs, etc. Is it possible that by specifying the participating hard drives in wrong order can make mdadm overwrite them? when I do mdadm --examine --scan I get something like ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0 Interestingly enough name used to be 'raid' and not the host hame with :0 appended. Here is the 'sanitized' config entries: DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1 CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST <system> MAILADDR root ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b Here is the output from mdstat cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid5 sdd1[0] sdf1[3] sde1[1] 1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none> fdisk shows the following: fdisk -l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000bf62e Device Boot Start End Blocks Id System /dev/sda1 * 1 9443 75846656 83 Linux /dev/sda2 9443 9730 2301953 5 Extended /dev/sda5 9443 9730 2301952 82 Linux swap / Solaris Disk /dev/sdb: 750.2 GB, 750156374016 bytes 255 heads, 63 sectors/track, 91201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000de8dd Device Boot Start End Blocks Id System /dev/sdb1 1 91201 732572001 8e Linux LVM Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00056a17 Device Boot Start End Blocks Id System /dev/sdc1 1 60801 488384001 8e Linux LVM Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ca948 Device Boot Start End Blocks Id System /dev/sdd1 1 121601 976760001 fd Linux raid autodetect Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes 255 heads, 63 sectors/track, 152001 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/dm-0 doesn't contain a valid partition table Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x93a66687 Device Boot Start End Blocks Id System /dev/sde1 1 121601 976760001 fd Linux raid autodetect Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xe6edc059 Device Boot Start End Blocks Id System /dev/sdf1 1 121601 976760001 fd Linux raid autodetect Disk /dev/md0: 2000.4 GB, 2000401989632 bytes 2 heads, 4 sectors/track, 488379392 cylinders Units = cylinders of 8 * 512 = 4096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk identifier: 0x00000000 Disk /dev/md0 doesn't contain a valid partition table Per suggestions I did clean up the superblocks and re-created the array with --assume-clean option but with no luck at all. Is there any tool that will help me to revive at least some of the data? Can someone tell me what and how the mdadm --create does when syncs to destroy the data so I can write a tool to un-do whatever was done? After the re-creating of the raid I run fsck.ext4 /dev/md0 and here is the output root@tanserv:/etc/mdadm# fsck.ext4 /dev/md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 Per Shanes' suggestion I tried root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0 mke2fs 1.41.14 (22-Dec-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=128 blocks, Stripe width=256 blocks 122101760 inodes, 488379392 blocks 24418969 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 14905 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 and run fsck.ext4 with every backup block but all returned the following: root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0 e2fsck 1.41.14 (22-Dec-2010) fsck.ext4: Invalid argument while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> Any suggestions? Regards!

  Read the article

• Re-assembling the RAID-5 array reboots my CentOS-5 machine

  - by xraminx

  I have 3 HDD's, each divided into 3 partitions. I had created a RAID-1 for boot partition md0 created from sda0, sdb0 and had also created two RAID-5 arrays: md1 created from sda1, sdb1, sdc1 md2 created from sda2, sdb2, sdc2 It used to work fine but one day I had to power off the machine (cold reboot) to get any response from the machine. After that, when the system started booting, it tried for a while to reconstruct the RAID arrays but after a few minutes it crashed silently. I booted the system in linux rescue mode from the DVD and tried to re-assemble the RAID devices manually. I was able to re-assemble md0 and md1 using: mdadm --assemble --scan /dev/md0 mdadm --assemble --scan /dev/md1 But when I try to re-assemble md2 using: mdadm --assemble --scan /dev/md2 the system reboots silently again. How can I fix this problem?

  Read the article

• growing EBS RAID volume

  - by Ryan Fernandes

  I've created a RAID0 configuration with two 1GB EBS volumes, mounted at /dev/md0 using mdadm and formatted with XFS Next, I copied some files over to fill the volume to around 30% of its capacity (of 2GB) I then created snapshots of the volumes using ec2-consistent-snapshot and created volumes of the said snapshots but specified the volume size to be 2GB (effective doubling the capacity on each disk) I then spun up a new instance, assembled the RAID0 configuration on /dev/md0 from the 2 volumes mentioned above and mount it to /vol df -hT showed /vol as 2GB (as expected) Now I ran sudo xfs_growfs -d /vol. The command completed normally but reported blocks changed from 523776 to 524160 (only!) and df -hT still showed /vol as 2GB (instead of the expected 4GB) I rebooted, remounted, reassembled the RAID but it still reports the old size. EDIT: trying to grow the RAID using mdadm --grow yields mdadm: raid0 array /dev/md0 cannot be reshaped Is there any other way I can grow a RAID0 array?

  Read the article

• Raid 5 with 4 disks on Debian automatically creates a spare drive

  - by Razer

  I'm trying to to create a RAID 5 with 4x 2TB disks on Debian 6. I followed the instructions from: http://zackreed.me/articles/38-software-raid-5-in-debian-with-mdadm I created the raid with following command: sudo mdadm --create --verbose /dev/md0 --auto=yes --level=5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 After creating the RAID mdadm --detail /dev/md0 shows me: /dev/md0: Version : 1.2 Creation Time : Mon Jun 11 18:14:26 2012 Raid Level : raid5 Array Size : 5860535808 (5589.04 GiB 6001.19 GB) Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Update Time : Mon Jun 11 18:14:26 2012 State : clean, degraded Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 512K Name : rsserver:0 (local to host rsserver) UUID : a68c3c99:1ef865e9:5a8a7bdc:64710ed8 Events : 0 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 2 8 49 2 active sync /dev/sdd1 3 0 0 3 removed 4 8 65 - spare /dev/sde1 Why is there a spare drive? I didn't create one. I don't want to use a spare drive.

  Read the article

• How to remove a drive from a 2-drive RAID 5 array?

  - by DrSAR

  There is some information available on shape changes in RAID arrays but I'm a little nervous and would like confirmation: Problem: I have 2 500GB drive as software raid 5 (mdadm). I would like to free one of the two drives since RAID-redundancy is for wimps... Can I just mdadm --grow --array-size=1 followed by a mdadm --grow --raid-disks 1? This seems too simple. How would I specify which drive gets freed? Part of the reason for this maneuver is that I don't have additional space to run a backup.

  Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10  | Next Page >