headers
Multicom Systems | 17 May 2013 16:02
Picon

Genuine Cruzer Blade USB flash drive 8GB Flash Disk

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
majianpeng | 17 May 2013 09:29
Picon

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

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 RCX: 0000000000000002
[  355.784571] RDX: ffffffff812afab0 RSI: ffff8800b5d75178 RDI: ffff880036e1a000
[  355.784593] RBP: ffff8800bd203c58 R08: ffff8800b5d74738 R09: 0000000000000001
[  355.784593] R10: 0000000000000000 R11: 0000000000012a00 R12: ffff8800b5d75178
[  355.784593] R13: ffff880036e1a000 R14: ffff8800b583a800 R15: 0000000000040000
[  355.784593] FS:  0000000000000000(0000) GS:ffff8800bd200000(0000) knlGS:0000000000000000
[  355.784593] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  355.784593] CR2: 0000000001dfa008 CR3: 00000000b6d11000 CR4: 00000000000407f0
[  355.784593] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  355.784593] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  355.784593] Stack:
[  355.784593]  ffff8800b5d75178 ffff8800b58f0000 ffff8800bd203ca8 ffffffff81439453
[  355.784593]  ffffffff821f2100 000000010000d993 ffff880000080000 ffff8800b58f0000
[  355.784593]  ffff8800b5d75178 ffffffff81c01fd8 ffffffff81c01fd8 ffff880036e1a000
[  355.784593] Call Trace:
[  355.784593]  <IRQ>
(Continue reading)

Permalink | Reply | 0 comments |
headers
den RDC | 16 May 2013 21:24
Picon

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

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
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ole Tange | 15 May 2013 15:51
Picon
Favicon

SpareMissing event, but spare not missing

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mo, Moore | 15 May 2013 14:11

Re: Kernel crash at md_seq_show of drivers/md/md.c

Dear Neil,

	Thank you for your clue. I make deeper trace after that and found another suspicion point. Kernel maybe
wakeup a mdk_thread which was kfree in failed case of mddev->pers->run(mddev).

	For make sure my guess, I add some printk in order to get more info. It seems that md_seq_show try to wake up a
mdk_thread in mddev_unlock() before md_seq_show return, but the thread was kfree already by
"out_free_conf" case of run() function in drivers/md/raid10.c.

	The Oops report as attached.

----------------- Patch of my debug code ---------------------------
Index: drivers/md/md.c
===================================================================
--- drivers/md/md.c     (revision 1911)
+++ drivers/md/md.c     (working copy)
 <at>  <at>  -675,6 +675,8  <at>  <at> 
        } else
                mutex_unlock(&mddev->reconfig_mutex);
 
+       if(mddev->thread)
+               printk("%s:%d Try to md_wakeup_thread(%p) of dev(%p)\n", __func__, __LINE__, mddev->thread, mddev);
        md_wakeup_thread(mddev->thread);
 }
 
 <at>  <at>  -4531,7 +4533,7  <at>  <at> 
 
        err = mddev->pers->run(mddev);
        if (err)
-               printk(KERN_ERR "md: pers->run() failed ...\n");
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Doebbler | 15 May 2013 00:07
Picon

Fwd: Corruption during RAID5->RAID6 migration

Roman,

Thank you very much, I hadn't seen those reports.  I had searched
through the Newegg reviews for linux/ubuntu and saw good
support/reviews.  Now searching more generally I see several
corruption reports in the feedback.  Wow, that's really bad.  I'll
definitely be leaving some reviews there of my own to warn others.

I have on hand a HighPoint Rocket 640L 4-port SATAIII card (Marvell
88SE9235 chipset) which I can use.  I will do some research, but do
you know of any issues with this card/chipset?  If so, can you
recommend a reliable, inexpensive card or cards?  I have one each
PCI-Express 1x and 16x slots available and would like a total of 6 or
more SATAII or SATAIII ports.

It is interesting that I was still seeing problems after only having
one drive active across the two cards.  I'll be avoiding using even
one port at a time on these cards.

Based on my high-level understanding, the reshape shouldn't read any
data from the two new drives during the reshape, just write to them.
All read data should obviously have come from the original 6 RAID5
drives.  Hopefully this means all my original data is still valid
across the 6 original drives.

I'm hopeful that I can fail and remove both new drives, leaving a
degraded, partially-reshaped RAID6.  Then, re-add the new drives on a
reliable controller (after wiping, clearing superblocks?) and
rebuild/reshape from there.  I'd expect only the data written to the
drive after the migration started would potentially be corrupt, which
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niclas Arndt | 15 May 2013 00:10
Picon

GRUB2 MBR/GPT sizing question

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 converting to MBR+GPT),
but in this case it might still work with 4kB sectors. (But I'm not sure
if this advanced format drive is actually using 4kB addressing rather than
512B emulation.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Doebbler | 14 May 2013 21:56
Picon

Corruption during RAID5->RAID6 migration

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 to the array (as spares) and started the
reshape/grow. I've appended the commands used and mdadm output to the
end of this email.

The reshape seemed to be going along as expected except I was only
getting ~5MB/s instead of the ~40MB/s I usually see.  Several hours
later I noticed that some of my recent downloads were corrupt when
extracting from archives.  I created some files from data in
/dev/urandom and calculated the md5sum.  A minute or so later I
recalculated the sum, and it was different.  Similarly, copying the
file resulted in another md5sum that was not the same as the previous
(Continue reading)

Permalink | Reply | 3 comments |
headers
Chris Finley | 13 May 2013 02:01
Picon
Gravatar

Raid5 double failure recovery

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 assembly
(Continue reading)

Permalink | Reply | 3 comments |
headers
Roy Sigurd Karlsbakk | 12 May 2013 22:30
Favicon
Gravatar

test

Just sending a test messge…

-- 
Vennlige hilsener / Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy <at> karlsbakk.net
http://blogg.karlsbakk.net/
GPG Public key: http://karlsbakk.net/roysigurdkarlsbakk.pubkey.txt
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ
for alle pedagoger å unngå eksessiv anvendelse av idiomer med xenotyp etymologi. I de fleste tilfeller
eksisterer adekvate og relevante synonymer på norsk.
--
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
Permalink | Reply | 0 comments |
headers
Mr. Wayne Scott | 6 May 2013 21:18
Picon
Favicon

Investment Placement

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
Permalink | Reply | 0 comments |

Gmane