gmane.linux.raid

Genuine Cruzer Blade USB flash drive 8GB Flash Disk

Multicom Systems — 2013-05-17T14:02:12

Get a Genuine Cruzer Blade USB flash drive 8GB Flash Disk For Ksh 2000/= only

Click Here to View
http://www.sandisk.com/products/usb/drives/cruzer-blade/

With its stylish, compact design and generous capacity, the Cruzer Blade USB Flash Drive makes it easy to back up, transfer, and share your files. Available in capacities up to 32GB** , this USB drive lets you carry your photos, movies, music, and personal data wherever you go.

Compact design that fits in your pocket.

Drives up to 32GB can hold your most important data
SanDisk Secure Access software password protects** your files
Includes up to 2GB of online backup** with Yuu Waa
Transports important personal files, music, and video
 
Offer Valid while stock Last. Free Delivery within Nairobi. Make your order now.

"WARRANTY 1 YEAR"
 
Regards,
Jimmy
Multicom Systems (K)
Sales Team
multicomsystemskenya< at >gmail.com
Cell: 0721-946602
Nairobi - Kenya 

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to m

[PATCH] raid5: After bio_reset, it must set some parameter of struct bio.

majianpeng — 2013-05-17T07:29:36

In commit 2f6db2a7073452b1, raid5 used bio_reset.But Kent Overstreet 
leak some fields of bio to set.So it will cause bugs:
[  355.746233] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
[  355.783651] ------------[ cut here ]------------
[  355.783707] kernel BUG at drivers/scsi/scsi_lib.c:1196!
[  355.783756] invalid opcode: 0000 [#1] SMP 
[  355.783846] Modules linked in: raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx netconsole configfs e1000e btrfs xor raid6_pq
[  355.784208] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc1+ #158
[  355.784261] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015  11/09/2011
[  355.784336] task: ffffffff81c10440 ti: ffffffff81c00000 task.ti: ffffffff81c00000
[  355.784386] RIP: 0010:[<ffffffff81428fd2>]  [<ffffffff81428fd2>] scsi_setup_fs_cmnd+0x92/0xa0
[  355.784469] RSP: 0018:ffff8800bd203c48  EFLAGS: 00010046
[  355.784517] RAX: 0000000000000000 RBX: ffff880036e1a000

RAID 5 - All superblocks gone due to MBR/GPT mishap - how do i figure out chunk size?

den RDC — 2013-05-16T19:24:12

Hello

Due to a nasty (human) error,  4 2tb disks in raid5 have lost their
1st megabyte of data ( including superblock ). In an attempt to get
the array to a state usable enough to at least attempt data recovery,
I have been trying to re-enable the array using various chunk size and
partition start offsets, but i cant seem to get it anywhere near a
consistent state ( recovery tools only return files or pieces of files
smaller then the chunk size, indicating alignment/chunk size
inconsistencies ).

The data I do have is :
- the order of the disks
- the pretty solid assumption that all data, even parity should be
fine for most of the disk except the very beginning.
- the exact size of the MD device before it got corrupted.

Is there any way, however adventurous, to glean the missing data (
chunk size, chunk alignment/offset ) from analysis of the existing
data ?

Kind regards
den_RDC
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo< at >vger.kernel.org
M

SpareMissing event, but spare not missing

Ole Tange — 2013-05-15T13:51:37

The last couple of days I have received a warning about a missing
spare for a device that has several spares.

  A SparesMissing event had been detected on md device /dev/md1.
  :
  md1 : active raid6 sdas[12](S) sdx[0] sdaq[11](S) sdau[13](S)
sdah[9] sdaf[8] sdae[7] sdad[6] sdac[5] sdab[4] sdaa[3] sdz[2] sdy[1]
      31256138752 blocks super 1.2 level 6, 128k chunk, algorithm 2
[10/10] [UUUUUUUUUU]
      bitmap: 0/2 pages [0KB], 1048576KB chunk

I have tried removing one of the spares and adding it again. Same error.

$ mdadm --version
mdadm - v3.1.4 - 31st August 2010
$ uname -a
Linux orsted 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012
x86_64 GNU/Linux

/Ole


The automated mail:

This is an automatically generated mail message from mdadm
running on orsted

A SparesMissing event had been detected on md device /dev/md1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid6] [raid5] [raid4] [raid0]
md3 : active raid0 md1[0] md2[1]
      62512

GRUB2 MBR/GPT sizing question

Niclas Arndt — 2013-05-14T22:10:36

Hi,

Sorry if this is slightly off-topic. I'm trying to figure out the HDD size
limitation using GRUB2 MBR-only with three md raid sets:

6*2 TB Samsung HD204UI partitioned like so:
Boot from sda MBR
15 GB / on raid1 pair ext4
15 GB swap on raid1 pair
32 MB unused fat16 per drive
1.9 TB /storage on raid 5 ext4 using all 6 drives

The above has been working flawlessly on openSUSE 11.3, 11.4, 12.2, and
initial install on 12.3. However, the first 12.3 kernel update replaced
GRUB2 with a failing GRUB0.97(!).

After much tinkering, I gdisk-converted the drives to a GRUB2 MBR+GPT with
the 32 MB partition used for grub_bios. This survives the kernel update,
so I think that I no longer have a problem. Either way, I would like to
understand if I was wrong or if the kernel update is misbehaving.

Surely, MBR supports 2TB drives with 512-byte sectors even though there is
a larger md raid?

Similarly, another identical server with 4*4TB Deskstar 7K4000 drives had
exactly the same MBR-only problem (also avoided by conver

Corruption during RAID5->RAID6 migration

James Doebbler — 2013-05-14T19:56:22

Hello,

I have encountered a scary situation with corruption on my RAID array
and would like any help/advice/pointers that might help me
save/recover any data I can.  I'll try to describe the situation as
best I can, so forgive the length of this email.

I have a personal file and media server running Ubuntu Linux Server
12.04.2, kernel version 3.2.0-41-generic.  I have a mdadm RAID5 array
of 2TB disks that I've been adding disks to and growing as needed off
the past couple of years and everything has been great other than a
non-zero mismatch_cnt.  The array was currently at 10TB/6 device and I
decided it was time to move to a RAID6 array since the number of
devices was getting large.  I wanted to minimize the chance of a total
failure during a rebuild as well as hopefully be able to resolve any
future mismatch_cnts correctly with the extra parity information.

I had read on Neil Brown's blog that the migration would be much
faster if I was also adding capacity, so I installed two new 2TB
drives, added them

Raid5 double failure recovery

Chris Finley — 2013-05-13T00:01:57

I could really use some experienced guidance before proceeding. This 4
disk raid 5 (md0) holds media for MythTV and represents a great deal
of work ripping my own DVDs. The system is on another drive, so most
of the raid content is large-file and contiguous.

System:  /dev/sda
Raid:   /dev/sd[cdef]1

From what I can tell, about a week ago, sde dropped out of the array.
Ironically, Disk Utility says this drive is "healthy". With new disk
in hand, I went to repair it a few days ago and found sdd dropped from
the array as well.  I ran bad-blocks -v on sdd which found more bad
sectors. I have NOT tried to force assembly or recreation of the
array.
The mdadm -E results are at
http://pastebin.com/7ng1bmyZ.

The event counts:
sdc : 42810
sdd : 42785
sde : 35760
sdf : 42810

I was thinking of doing a force assembly and then adding the new drive
as a fourth.
mdadm --assemble --force /dev/sd[cdf]1
Since these three are the closest event counts.

Questions:
1. Would including sde (with the week-old data) in the forced

test

Roy Sigurd Karlsbakk — 2013-05-12T20:30:39

Just sending a test messge…

Investment Placement

Mr. Wayne Scott — 2013-05-06T19:18:18

Greetings,

I am a Civil Lawyer in the United Kingdom. I have a Client that has Interest in investing in Your country. Can You be of assistance?

I shall give you details when you reply

Wayne
--
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

Investment Placement

Mr. Wayne Scott — 2013-05-03T18:14:24

Greetings,

I am a Civil Lawyer in the United Kingdom. I have a Client that has Interest in investing in Your country. Can You be of assistance?

I shall give you details when you reply

Wayne
--
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

Unusual RAID 1 recovery problem

John Rowe — 2013-05-10T17:31:15

Following a system reinstall (an upgrade from Scientific Linux 5.x  to
to 6.x), I had a RAID1 array that  I could start manually with:


but would not start automatically on reboot. SL is a RedHat clone and
all partitions were of type "fd".

The above command worked fine and I could see all my data, but every
time I rebooted the RAID1 array wasn't there.

Encouraged by the reassuring words of the mdadm man page:

        --assume-clean
                      Tell mdadm that the array pre-existed and is known
        to be clean.  It can be  useful  when trying to recover from a
        major failure as you can be sure that no data will be affected
        unless you actually write to the array.
        
I tried:


This worked, following the usual warning about how the partitions had
previously been part of an array. But now:


refuses to do anything even if I try:


I get an error message listing various possibilities such as "bad
superblock". dmesg tells me it can't find an ext2 file system
on /dev/md0


Cle

Investment Placement

Mr. Wayne Scott — 2013-05-08T23:41:12

Greetings,

I am a Civil Lawyer in the United Kingdom. I have a Client that has Interest in investing in Your country. Can You be of assistance?

I shall give you details when you reply

Wayne
--
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

мигом превратить надежду в реальность

kalaidin — 2013-05-10T03:03:55

Web: http://tinyurl.com/crfjdy8 она подсобит Вам <<разложить полностью по полочкам>> и сфокусировать скрытые источники на центровом - на Вашей цели! Мы представляем вашему вниманию новенькую видеопрограмму людям, которые следуют к своим целям! Мы ведим как помочь Вам достичь успеха! и не существенно, какую цель Вы перед собою производите - поменять службу, открыть бизнес либо исхудать на 10 кил. Вам когда - нибудь выпадало присутствовать в эдакой ситуации, когда-либо Вы не могли остановится на цели, Все свободное время рассеивались на всяческие мелочи. начинали поступать

[PATCH] bcache: Fix incompatible pointer type warning

Emil Goode — 2013-05-09T20:39:26

The function pointer release in struct block_device_operations
should point to functions declared as void.

Sparse warnings:

drivers/md/bcache/super.c:656:27: warning:
incorrect type in initializer (different base types)
drivers/md/bcache/super.c:656:27:
expected void ( *release )( ... )
drivers/md/bcache/super.c:656:27:
got int ( static [toplevel] *<noident> )( ... )

drivers/md/bcache/super.c:656:2: warning:
initialization from incompatible pointer type [enabled by default]

drivers/md/bcache/super.c:656:2: warning:
(near initialization for ‘bcache_ops.release’) [enabled by default]

Signed-off-by: Emil Goode <emilgoode< at >gmail.com>
---
 drivers/md/bcache/super.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 76c7f6c..938bbff 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
< at >< at > -637,11 +637,10 < at >< at > static int open_dev(struct block_device *b, fmode_t mode)
 return 0;
 }
 
-static int release_d

Акция для любых клиентов. забегаете срочно!

kamazmaster2005 — 2013-05-09T12:34:22

милостиво поглядеть на наш сайт. Вам полюбится то ровно Вы на нем приглянете. http://snurl.com/26zalfe

Быстро, стильно и удобно,
Слушай голос такой спокойный
--
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

vess raid stripes disappear

2013-05-09T11:29:41

I have an interesting problem with a Vessraid 1830s.
We have a few of these that work fine but one seems
to lose its filesets. The only difference between the
good ones and the bad one is that the bad one has firmware
version 3.06 while the good ones are at 3.05 (This may
not be relevant).

Here's what happens. If I plug the raid into a 32 bit
RHEL5 box with large files enabled, syslog does pick
it up:

kernel: Vendor: Promise  Model:VessRAID 1830s Rev: 0306
Type: Direct-Access     ANSI SCSI revision: 05
SCSI device sdc:2929686528 2048-byte hdwr sectors (5999998 MB)


Using the web gui, I can carve out partitions,
I make three stripes across 4 disks of 2Terabytes each
using RAID5.
cat /proc/partitions   shows the raw devices as well as
the correct sizes. I then use gnu-parted (v3.1) to make the
filesets:

mklabel gpt
mkpart primray 0 0
set 1 raid on


I create the fileset using

mkfs.ext3 -m0 /dev/sdc1
I can then mount the FS and write to it.

If I either reboot the RAID or the host, the FS disappears
ie cat

mdraid autodetect partially failing after disk replacement

Ricky Burgin — 2013-05-09T01:20:43

Hello again,

Little bit of progress since I last dropped a message in (sorry for the
duplicate, didn't think the initial one got through).

The kernel has mdraid built into it and all disks are using 0.90
superblocks, all 'fd' partitions, but only 2 or 4 disks are being
recognised and applied to the freshly created raid array which works
fine when mounted on any other OS.

Any suggestions for what could cause disks to be overlooked by mdraid
before the root device is even attempted to be mounted would be very
helpful, I'm now totally at a loss as to what to do from here.

Kind regards,
Ricky Burgin
--
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

[PATCH 0/2] Fixes for dm-raid faulty device restoration

Jonathan Brassow — 2013-05-08T22:54:57

Neil,

I've discovered a bug in the recently accepted (for 3.11) patch:
"[PATCH - v2] DM RAID: Add ability to restore transiently failed devices
on resume"

I have two follow-on patches to fix the issue:
- [PATCH 1/2] DM RAID:  Break-up untidy function
- [PATCH 2/2] DM RAID:  Fix raid_resume not reviving failed devices in
all cases

Thanks,
 brassow

--
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

Specifying a data offset?

Tregaron Bayly — 2013-05-08T20:17:54

We have lots of mirrors all over our network and over time this means
arrays created by different versions of mdadm.  In turn this means that
we have all sorts of data offsets, including a 2.3.5 mdadm version that
offset the data 262,144 sectors.  I can't fathom why I need my data to
start 128M from the beginning of the disk, but whatever.

Inevitably an admin decided that doing a --create over the top of an
existing array was a good and necessary thing and when finished we
couldn't find the filesystem.  Bringing it back online was simply a case
of finding the correct offset, locating an mdadm version that would
specify it properly and doing another create.  Through the whole
exercise I found myself wondering why there isn't a command line
argument to specify the data offset if something other than the default
is desired.  I think that implementing the argument and reading the
value in init_super wouldn't be terribly difficult so I must be missing
an obvious reason.  Can someone explain to me why this featur

0.90 vs 1.X - Differing behavior for device # during fail/remove/add operation

Dusty Mabe — 2013-05-08T17:39:24

CentOS 6.3
2.6.32-279.19.1
mdadm-3.2.3-9.el6.x86_64


I have noticed that the device number printed in the mdstat file gets
changed if you fail->remove->add a member device of a 1.X metadata
array, but for a 0.90 metadata array the device will go back to the
original value once recovery has finished.

This means after recovery has finished I end up with the following
outputs for 1.1 and 0.90 metadata:

1.1 METADATA /proc/mdstat (trimmed)
md50 : active raid1 loop0[2] loop1[1]
      32760 blocks super 1.1 [2/2] [UU]

1.1 METADATA mdadm --detail (trimmed)
    Number   Major   Minor   RaidDevice State
       2       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1

0.90 METADATA /proc/mdstat (trimmed)
md50 : active raid1 loop0[0] loop1[1]
      32704 blocks [2/2] [UU]

0.90 METADATA mdadm --detail (trimmed)
    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1

New RAID

Andras Fekete — 2013-05-08T12:55:38

Hello,

I'm trying to learn how the mdadm software works. I've been looking at the
downloaded source for mdadm-3.2. My question is if I want to create a new
kind of a RAID, how can I expand the code to do so? Is there some code
overview/documentation page that I can look at? Perhaps a forum for asking
questions about the source?

Thanks,
-Andras
--
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