Berni | 1 Feb 2008 13:52
Picon
Picon

raid problem: after every reboot /dev/sdb1 is removed?

Hi!

I have the following problem with my softraid (raid 1). I'm running
Ubuntu 7.10 64bit with kernel 2.6.22-14-generic.

After every reboot my first boot partition in md0 is not synchron. One
of the disks (the sdb1) is removed. 
After a resynch every partition is synching. But after a reboot the
state is "removed". 

The disks are new and both seagate 250gb with exactly the same partition table. 

Here some config files: 

#cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
[raid4] [raid10] 
md2 : active raid1 sda6[0] sdb6[1]
      117185984 blocks [2/2] [UU]

md1 : active raid1 sda5[0] sdb5[1]
      1951744 blocks [2/2] [UU]

md0 : active raid1 sda1[0]
      19534912 blocks [2/1] [U_]	<<<<<<<< this is the problem: looks like U_ after reboot

unused devices: <none>

#fdisk /dev/sda
  Device Boot      Start         End      Blocks   Id  System
(Continue reading)

Greg Cormier | 1 Feb 2008 14:46
Picon

Re: raid problem: after every reboot /dev/sdb1 is removed?

I had the same problem.

Re-doing the partition from ext2 to linux raid fixed my problem, but I
see you're already using that FS type.

Maybe it was the action of re-partitioning in general that fixed my
problem? You could try deleting it and re-creating that partition,
syncing, and rebooting?

Greg

On Fri, Feb 1, 2008 at 7:52 AM, Berni <wstripes <at> gmx.at> wrote:
> Hi!
>
>  I have the following problem with my softraid (raid 1). I'm running
>  Ubuntu 7.10 64bit with kernel 2.6.22-14-generic.
>
>  After every reboot my first boot partition in md0 is not synchron. One
>  of the disks (the sdb1) is removed.
>  After a resynch every partition is synching. But after a reboot the
>  state is "removed".
>
>  The disks are new and both seagate 250gb with exactly the same partition table.
>
>  Here some config files:
>
>  #cat /proc/mdstat
>  Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
>  [raid4] [raid10]
>  md2 : active raid1 sda6[0] sdb6[1]
(Continue reading)

Berni | 1 Feb 2008 18:22
Picon
Picon

Re: raid problem: after every reboot /dev/sdb1 is removed?

Hi

So I deleted all partitions on the second hdd and copied the partition table from the first one. After that I
made a resync. 
After a reboot - the sda1 was removed (in past it was the sdb1) _U
After a second reboot the sda1 again is missing. U_

It looks like only one of them can stay in the /dev/md0 raid. 

Could it be a problem with reiserfs? 
Or that the (sda1,sdb1) are primär partitions? 

thanks
berni

On Fri, 1 Feb 2008 08:46:43 -0500
"Greg Cormier" <gcormier <at> gmail.com> wrote:

> I had the same problem.
> 
> Re-doing the partition from ext2 to linux raid fixed my problem, but I
> see you're already using that FS type.
> 
> Maybe it was the action of re-partitioning in general that fixed my
> problem? You could try deleting it and re-creating that partition,
> syncing, and rebooting?
> 
> Greg
> 
> On Fri, Feb 1, 2008 at 7:52 AM, Berni <wstripes <at> gmx.at> wrote:
(Continue reading)

aristizb | 1 Feb 2008 19:59
Picon
Picon
Favicon

Linux md and iscsi problems

Hello.

Currently I am working on a RAID-1 created using mdadm (version 2.6.2)  
with a local disc and a remote disc connected via iSCSI (open iscsi  
for the initiator and iscsi enterprise target).

I am testing the performance of the RAID writing data to the array  
disc having my target disc on a simulated link of 1 Mbps, I also  
defined my slow device as write-mostly and I am using the write-behind  
option so I can write with a decent speed without having to receive  
the ACK from the slow device.

My test constantly writes a file on the raid for around 20 minutes,  
but then the slow device is marked as faulty; I can recover the raid  
removing the device and adding it again, but the resynchronization  
process takes a long time (obviously because of the slow device).

Here is the message from the kernel when the slow disc fails:
sd 6:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK

Summarizing, I have two questions about the behavior of Linux md with  
slow devices:

1. Is it possible to modify some kind of time-out parameter on the  
mdadm tool so the slow device wouldn't be marked as faulty because of  
its slow performance.

2. Is it possible to control the "buffer" size of the RAID?, in other  
words, can I control the amount of data I can write to the local disc  
before I receive an acknowledgment from the slow device when I am  
(Continue reading)

Neil Brown | 2 Feb 2008 03:32
X-Face
Picon
Gravatar

Re: raid problem: after every reboot /dev/sdb1 is removed?

On Friday February 1, wstripes <at> gmx.at wrote:
> Hi!
> 
> I have the following problem with my softraid (raid 1). I'm running
> Ubuntu 7.10 64bit with kernel 2.6.22-14-generic.
> 
> After every reboot my first boot partition in md0 is not synchron. One
> of the disks (the sdb1) is removed. 
> After a resynch every partition is synching. But after a reboot the
> state is "removed". 

Please send boot logs (e.g. dmesg > afile).

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Andreas-Sokov | 2 Feb 2008 03:59
Picon

mdadm: /dev/md1: Cannot reshape array without increasing size (yet).

Hi linux-raid.

What is problem with raid ?
why "mdadm: /dev/md1: Cannot reshape array without increasing size (yet)."

i have

root <at> raid01:~# mdadm -D /dev/md1
/dev/md1:
        Version : 00.91.03
  Creation Time : Tue Nov 13 18:42:36 2007
     Raid Level : raid5
     Array Size : 1465159488 (1397.29 GiB 1500.32 GB)
  Used Dev Size : 488386496 (465.76 GiB 500.11 GB)
   Raid Devices : 5
  Total Devices : 5
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Sat Feb  2 05:45:11 2008
          State : clean, degraded
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

  Delta Devices : 1, (4->5)
(Continue reading)

Andreas-Sokov | 2 Feb 2008 04:12
Picon

/dev/sdb has different metadata to chosen array /dev/md1 0.91 0.90.

Здравствуйте, linux-raid.

Help please, How i can to fight THIS :

root <at> raid01:~# mdadm -I /dev/sdb
mdadm: /dev/sdb has different metadata to chosen array /dev/md1 0.91 0.90.

--

-- 
С уважением,
 Andreas-Sokov                          mailto:andre.s <at> j8.com.ru

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bill Davidsen | 2 Feb 2008 20:47

Re: raid problem: after every reboot /dev/sdb1 is removed?

Berni wrote:
> Hi!
>
> I have the following problem with my softraid (raid 1). I'm running
> Ubuntu 7.10 64bit with kernel 2.6.22-14-generic.
>
> After every reboot my first boot partition in md0 is not synchron. One
> of the disks (the sdb1) is removed. 
> After a resynch every partition is synching. But after a reboot the
> state is "removed". 
>
> The disks are new and both seagate 250gb with exactly the same partition table. 
>
>   
Did you create the raid arrays and then install on them? Or add them 
after the fact? I have seen this type of problem when the initrd doesn't 
start the array before pivotroot, usually because the raid capabilities 
aren't in the boot image. In that case rerunning grub and mkinitrd may help.

I run raid on Redhat distributions, and some Slackware, so I can't speak 
for Ubuntu from great experience, but that's what it sounds like. When 
you boot, is the /boot mounted on a degraded array or on the raw partition?
> Here some config files: 
>
> #cat /proc/mdstat 
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
> [raid4] [raid10] 
> md2 : active raid1 sda6[0] sdb6[1]
>       117185984 blocks [2/2] [UU]
>       
(Continue reading)

Keld Jørn Simonsen | 2 Feb 2008 20:41
Picon

draft howto on making raids for surviving a disk crash

This is intended for the linux raid howto. Please give comments.
It is not fully ready /keld

Howto prepare for a failing disk

The following will describe how to prepare a system to survive
if one disk fails. This can be important for a server which is
intended to always run. The description is mostly aimed at
small servers, but it can also be used for
work stations to protect it for not losing data, and be running even if a 
disk fails. Some recommendations on larger server setup is given
at the end of the howto.

This requires some extra hardware, especially disks, and the description 
will also touch how to mak the most out of the disks, be it in terms of
available disk space, or input/output speed.

1. Creating of partitions

We recommend creating partitions for /boot, root, swap and other file systems.
This can be done by fdisk, parted or maybe a graphical interface
like the Mandriva/PClinuxos harddrake2.  It is recommended to use drives
with equal sizes and performance characteristics.

If we are using the 2 drives sda and sdb, then sfdisk
may be used to make all the partitions into raid partitions:

   sfdisk -c /dev/sda 1 fd
   sfdisk -c /dev/sda 2 fd
   sfdisk -c /dev/sda 3 fd
(Continue reading)

Bill Davidsen | 2 Feb 2008 21:17

Re: In this partition scheme, grub does not find md information?

Bill Davidsen wrote:
> Moshe Yudkowsky wrote:
>> Michael Tokarev wrote:
>>
>
>> To return to that peformance question, since I have to create at 
>> least 2 md drives using different partitions, I wonder if it's 
>> smarter to create multiple md drives for better performance.
>>
>> /dev/sd[abcd]1 -- RAID1, the /boot, /dev, /bin/, /sbin
>>
>> /dev/sd[abcd]2 -- RAID5, most of the rest of the file system
>>
>> /dev/sd[abcd]3 -- RAID10 o2, a drive that does a lot of downloading 
>> (writes)
>>
> I think the speed of downloads is so far below the capacity of an 
> array that you won't notice, and hopefully you will use things you 
> download more than once, so you still get more reads than writes.
>
>>> For typical filesystem usage, raid5 works good for both reads
>>> and (cached, delayed) writes.  It's workloads like databases
>>> where raid5 performs badly.
>>
>> Ah, very interesting. Is this true even for (dare I say it?) 
>> bittorrent downloads?
>>
> What do you have for bandwidth? Probably not more than a T3 (145Mbit) 
> which will max out at ~15MB/s, far below the write performance of a 
> single drive, much less an array (even raid5).
(Continue reading)


Gmane