similar to: xen on suse 9.3 and software raid

Il 30/01/19 16:49, Simon Matter ha scritto: >> On 01/30/19 03:45, Alessandro Baggi wrote: >>> Il 29/01/19 20:42, mark ha scritto: >>>> Alessandro Baggi wrote: >>>>> Il 29/01/19 18:47, mark ha scritto: >>>>>> Alessandro Baggi wrote: >>>>>>> Il 29/01/19 15:03, mark ha scritto: >>>>>>>

CentOS 6.3, x86_64. I have noticed when building a new software RAID-6 array on CentOS 6.3 that the mismatch_cnt grows monotonically while the array is building: # cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md11 : active raid6 sdg[5] sdf[4] sde[3] sdd[2] sdc[1] sdb[0] 3904890880 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU]

I''m struggling to get Xen to boot on a FC4 Opteron box. I''ve included the tail of the boot log below [1]. I suspect that the problems relates to the software RAID 1 root and boot partitions, and how it relates to the initrd image. The RAID volumes fail to mount. I compiled the Xen snapshot from the 23rd September, and the only change I''ve made is to enable the

On 01/30/19 03:45, Alessandro Baggi wrote: > Il 29/01/19 20:42, mark ha scritto: >> Alessandro Baggi wrote: >>> Il 29/01/19 18:47, mark ha scritto: >>>> Alessandro Baggi wrote: >>>>> Il 29/01/19 15:03, mark ha scritto: >>>>> >>>>>> I've no idea what happened, but the box I was working on last week

Andreas, why is it relevant only in case of RAID5 or RAID6? regards, Martin On Fri, Mar 7, 2014 at 5:57 PM, Andreas Dilger <adilger@dilger.ca> wrote: > Note that stride and stripe width only make sense for RAI-5/6 arrays. > For RAID-1 it doesn't really matter. > > Cheers, Andreas > >> On Mar 6, 2014, at 13:46, Martin T <m4rtntns@gmail.com> wrote: >>

I installed Centos 6.x 64 bit with the minimal ISO and used two disks in RAID 1 array. Filesystem Size Used Avail Use% Mounted on /dev/md2 97G 918M 91G 1% / tmpfs 16G 0 16G 0% /dev/shm /dev/md1 485M 54M 407M 12% /boot /dev/md3 3.4T 198M 3.2T 1% /vz Personalities : [raid1] md1 : active raid1 sda1[0] sdb1[1] 511936 blocks super 1.0

Hi, I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or ext4) file-system to this RAID1 array using mke2fs utility. According to RAID-related tutorials, I should create the file-system like this: # mkfs.ext3 -v -L myarray -m 0.5 -b 4096 -E stride=16,stripe-width=32 /dev/md0

Hi all, As part of my raid experience, I have yet to have to do this, but was wondering how you guys would attempt it. I have 3 drives in a raid 1, with one as a hot spare. They are 250gb with all space used by two raid devices, 1 with boot, the other with LVMs filling them up. Now, lets say down the road I want to put in 500gb drives and replace them....yikes. I was thinking of taking out the

Hi, I encounter a problem with Syslinux 5.00 I cannot really describe. So I created two small videos: Booting with Syslinux 5.00 (1.3 MB): <https://www.dropbox.com/s/b6g8cdf2t9v48c6/boot-syslinux5-fail.mp4> How I fixed the problem by downgrading to Syslinux 4.06 and how booting should look like (6.5 MB): <https://www.dropbox.com/s/lt7cpgfm0qvqtba/boot-syslinux5-how-i-fixed-it.mp4>

I've just finished installing a new Bacula storeage server. Prior to doing the install I did some research and ended up deciding to do the following config. 6x4TB drives /boot/efi efi_fs sda1 /boot/efi_copy efi_fs sdb1 /boot xfs RAID1 sda2 sdb2 VG RAID6 all drives containing SWAP / /home /var/bacula Questions: 1) The big problem with this is that it is dependant on sda for

Note that stride and stripe width only make sense for RAI-5/6 arrays. For RAID-1 it doesn't really matter. Cheers, Andreas > On Mar 6, 2014, at 13:46, Martin T <m4rtntns@gmail.com> wrote: > > Hi, > > I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or

The stripe and stride options do two things: - shift block and inode bitmaps in each group to be on different disks - align the block allocation to the stripe and stride boundaries to avoid read-modify-write in RAID The first one is irrelevant if the flex_bg option is used, since it already packs the bitmaps together and achieves the same effect. The second is meaningless for RAID-1 since

Hello, I have a weird problem after adding new PV do LMV volume group. It seems the error comes out only during boot time. Please read the story. I have couple of 1U machines. They all have two, four or more Fujitsu-Siemens SAS 2,5" disks, which are bounded in Raid1 pairs with Linux mdadm. First pair of disks has always two arrays (md0, md1). Small md0 is used for booting and the rest - md1

Howdy folks, I''m trying to boot Xen 3.0 on a Centos 4(.2) system with root on a software raid1 volume. When booting the Xen kernel, ''raidautorun'' in the /init nash script fails to assemble either the root md or the raid5 md containing my LVM volumes. If I move root to /dev/hda1, the system boots fine. raidautorun still fails to assemble the md devices, but mdadm

I''ve spent the past while researching this but I''m just not finding a solution. I''ve been trying to get my xen kernel booting on a pretty much stock CentOS 4.4 installation. I installed Xen from src rpm and installed all the requisite software and I''m sure it''s with the ram disk but I can''t figure out how to resolve this. With a stock kernel

As promised, here''s what I did to get iSCSI root running under XenU under Debian 3.1 (Sarge): Be running linux 2.6 under XenU. Build XenU with SCSI disk support (I did them as modules) Get linux-iscsi 4.0.1.8 from http://sourceforge.net/projects/linux-iscsi/ Build it according to the instructions there (i found it a bit tricky) and install under your XenU Get iscsi-init 4.0.1 from

Received the following message in mail to root: Message 257: >From root at desk4.localdomain Tue Oct 28 07:25:37 2014 Return-Path: <root at desk4.localdomain> X-Original-To: root Delivered-To: root at desk4.localdomain From: mdadm monitoring <root at desk4.localdomain> To: root at desk4.localdomain Subject: DegradedArray event on /dev/md0:desk4 Date: Tue, 28 Oct 2014 07:25:27

hi all! back in Aug several of you assisted me in solving a problem where one of my drives had dropped out of (or been kicked out of) the raid1 array. something vaguely similar appears to have happened just a few mins ago, upon rebooting after a small update. I received four emails like this, one for /dev/md0, one for /dev/md1, one for /dev/md125 and one for /dev/md126: Subject: DegradedArray

I'am running CentOS 4.3 on an (Intel) with one SATA disk (/dev/sda). The output of fdisk -l: Disk /dev/sda: 81.9 GB, 81964302336 bytes 255 heads, 63 sectors/track, 9964 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 19 152586 83 Linux /dev/sda2 20 2569

I've managed to install CentOS 5.1 on S5000PAL with fakeraid Intel Embedded Raid Technology II Raid1 (LSI chipset) with some help of kickstart declaration 'driverdisk --source=http://.../driver.img' Then I've had some problems with yum update - new kernel didn't know about megasr.ko. I've solved it with commands: cd /lib/modules/ cp 2.6.18-53.el5PAE/updates/megasr.ko