* Re: [PATCH 06/32] xen blkback: prepare for bi_rw split
From: Christoph Hellwig @ 2015-11-07 10:17 UTC (permalink / raw)
To: mchristi-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA, Konrad Rzeszutek Wilk,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1446674909-5371-7-git-send-email-mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
A little offtopic for this patch, but can some explain this whole
mess about bios in Xen blkfront? We can happily do partial completions
at the request later.
Also since the blk-mq conversion the call to blk_end_request_all is
completely broken, so it doesn't look like this code path is exactly
well tested.
^ permalink raw reply
* Re: [dm-devel] [PATCH 19/32] block: add helper to get data dir from op
From: Christoph Hellwig @ 2015-11-07 10:19 UTC (permalink / raw)
To: Mike Christie
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA, device-mapper development,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <563B930F.7040705-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Nov 05, 2015 at 11:34:07AM -0600, Mike Christie wrote:
> I can do that. You are right in how they are used. I just did the above,
> to follow the other *_data_dir calls.
I think the *_data_dir calls are horrible interfaces. But your series
already is huge, so if it makes your life easier I'd say keep it as-is
for now. But in the long run we should have the interfaces that Bart
suggested, and one that gives you a dma_data_direction from a request,
as that's what a lot of the driver ultimatively want.
^ permalink raw reply
* Re: [PATCH 32/32] block: remove __REQ op defs and reduce bi_op/bi_rw sizes
From: Christoph Hellwig @ 2015-11-07 10:21 UTC (permalink / raw)
To: mchristi-H+wXaHxf7aLQT0dZR+AlfA
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <1446674909-5371-33-git-send-email-mchristi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
I love this series!
Also I think it's very good that we finally split the ioprio out to it's
own field.
Thanks a lot for doing this work.
> I was not sure if or how much or where people wanted to stick things.
> There also appears to be room in the bi_flags field. If bi_flags is
> only using 13 bits and there are only 16 REQ_XYZs bits related bios,
> I could put them all in one variable if we wanted to go wild with trying
> to shrink the bio while I am at it..
This sounds interesting, but I'd rather do it as a separate project
later.
^ permalink raw reply
* Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs
From: Christoph Hellwig @ 2015-11-07 10:23 UTC (permalink / raw)
To: Mike Christie
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-raid-u79uwXL29TY76Z2rM5mHXA, device-mapper development,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <563A3813.5010604-hcNo3dDEHLuVc3sceRu5cw@public.gmane.org>
On Wed, Nov 04, 2015 at 10:53:39AM -0600, Mike Christie wrote:
> > If you have to touch submit_bio() and submit_bio_wait(), how about
> > requiring the callers of these functions to set the cmd and flags
> > arguments in the bio structure and to leave out the cmd and flags
> > arguments from the submit_bio() and submit_bio_wait() functions ? A
> > (compile tested only) patch that implements this idea is available at
> > https://lkml.org/lkml/2014/6/2/173.
> >
>
> Yeah, I can do that.
I think this would be useful to do at the beginning of the series.
While this will have a huge trickle effect through the series it should
make thing a bit simpler overall. By leaving op 0 undefined it should
also help to create a nice error trap for unconverted code.
^ permalink raw reply
* Re: [PATCH 06/32] xen blkback: prepare for bi_rw split
From: Konrad Rzeszutek Wilk @ 2015-11-07 14:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-scsi, linux-kernel, linux-raid, dm-devel, mchristi,
linux-fsdevel, xen-devel, drbd-dev
In-Reply-To: <20151107101713.GB12117@infradead.org>
On Sat, Nov 07, 2015 at 02:17:13AM -0800, Christoph Hellwig wrote:
> A little offtopic for this patch, but can some explain this whole
> mess about bios in Xen blkfront? We can happily do partial completions
> at the request later.
Not sure I follow. There are a couple of patches that are touching
Xen block code right now - the multi-queue, the ones in xen-tip
(which look to have be merged on Wednesday) and this one.
And oddly enough I never got copied on this original patch.
>
> Also since the blk-mq conversion the call to blk_end_request_all is
> completely broken, so it doesn't look like this code path is exactly
> well tested.
^ permalink raw reply
* RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-07 17:05 UTC (permalink / raw)
To: linux-raid
Hello,
I’m not sure if this is the right way to go about it, so let me give you my story. I had a 7 x 3TB RAID array (12TB in total), 6 drives in the array and 1 spare that was also part of the array but simply a spare waiting at the ready in case of a drive failure, is what I had running before my array broke. I added two new arrays to my system last night, in order to back up my current RAID 6. The first array was a 3 x 3TB RAID 0, for a total of 9TB. Then a 2 x 1TB RAID 0 array, for a total of 2TB. 9+2 = 11 and although I’m 1TB shy, I knew I had a bunch of crap and redundancy to get rid of, I just really needed a solid backup after I was going to clean up.
After creating the new arrays, I started transferring from my 12TB array, 2TB worth of data to the 2TB RAID 0 array. At some point during the transfer, rsync complained of an I/O error. It seemed to have transferred 500GB worth of data before this mishap. The following morning, I noticed that error, and saw that I couldn’t mount my 12TB array anymore. Mind you, I didn’t touch this original array, but I think what happened was that the I/O error blew 2 of my drives.
What I’m thinking of doing is the following, but I’m just looking for some advice in case I’m missing anything:
sudo mdadm create --assume-clean --level=6 --raid-devices=7 --size=2930135040 /dev/md127 /dev/sde /dev/sdf /dev/sdg /dev/sdh missing missing /dev/sdd
Here is the output of mdadm examination:
=======================================================================
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : active
Device UUID : b4f8af9e:5d486bf7:d86fba0d:0af9e3a5
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 03:14:41 2015
Checksum : 3c08c930 - correct
Events : 58344
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : active
Device UUID : 822e5181:1c731970:3ae49e25:06a93621
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 03:14:41 2015
Checksum : 2a8f4e1b - correct
Events : 58344
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdd
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : active
Device UUID : d8c57aac:91fb811c:eab9e82d:a60ca6bf
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 03:14:41 2015
Checksum : a8daa737 - correct
Events : 58344
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sde
/dev/sde:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : active
Device UUID : 46ae26e3:8fc7b451:548951c6:44426755
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 03:14:41 2015
Checksum : 42e360a7 - correct
Events : 58344
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdf
/dev/sdf:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : clean
Device UUID : 9dc9106f:3a491437:d01b1b49:c7637240
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 04:11:15 2015
Checksum : 21f7bef6 - correct
Events : 58362
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : .AA... ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdg
/dev/sdg:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : clean
Device UUID : cd8e1df7:b6a8a95e:a744b6f0:27c6fa00
Internal Bitmap : 8 sectors from superblock
Update Time : Wed Nov 4 04:11:15 2015
Checksum : 39bd6edb - correct
Events : 58362
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : .AA... ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sdh
/dev/sdh:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 4259892e:2291b1be:a1cac81d:81d59c9d
Name : Rex:en1
Creation Time : Mon Apr 20 19:11:03 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=944 sectors
State : clean
Device UUID : a130d2b7:77f8fe81:48203bc8:d2413cae
Update Time : Sun Nov 1 01:00:56 2015
Checksum : a2939695 - expected a2939694
Events : 58339
Layout : left-symmetric
Chunk Size : 512K
Device Role : spare
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sd[b-h] |grep "Array State"
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
Array State : .AA... ('A' == active, '.' == missing, 'R' == replacing)
Array State : .AA... ('A' == active, '.' == missing, 'R' == replacing)
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sd[b-h] |grep "Events"
Events : 58344
Events : 58344
Events : 58344
Events : 58344
Events : 58362
Events : 58362
Events : 58339
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sd[b-h] |grep "raid.status"
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sd[b-h] |grep "Role"
Device Role : Active device 3
Device Role : Active device 4
Device Role : Active device 5
Device Role : Active device 0
Device Role : Active device 1
Device Role : Active device 2
Device Role : spare
cisco@DoctorBanner:~$ sudo mdadm --examine /dev/sd[b-h] |grep "Used"
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
=======================================================================
Thanks for your help in advance, I’m hoping to be able to find something, but so far this is all I’ve got.
Much appreciated!
Cisco--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-07 18:49 UTC (permalink / raw)
To: Francisco Parada, linux-raid
In-Reply-To: <BD358508-33D4-4463-99AB-118019C2EB06@abitofthisabitofthat.com>
On 11/07/2015 12:05 PM, Francisco Parada wrote:
> Hello,
>
> I’m not sure if this is the right way to go about it, so let me give
> you my story. I had a 7 x 3TB RAID array (12TB in total), 6 drives
> in the array and 1 spare that was also part of the array but simply a
> spare waiting at the ready in case of a drive failure, is what I had
> running before my array broke. I added two new arrays to my system
> last night, in order to back up my current RAID 6. The first array
> was a 3 x 3TB RAID 0, for a total of 9TB. Then a 2 x 1TB RAID 0
> array, for a total of 2TB. 9+2 = 11 and although I’m 1TB shy, I knew
> I had a bunch of crap and redundancy to get rid of, I just really
> needed a solid backup after I was going to clean up.
Yes, this is the right way to go about it. Missed just a few items that
would help. Good report.
> After creating the new arrays, I started transferring from my 12TB
> array, 2TB worth of data to the 2TB RAID 0 array. At some point
> during the transfer, rsync complained of an I/O error. It seemed to
> have transferred 500GB worth of data before this mishap. The
> following morning, I noticed that error, and saw that I couldn’t
> mount my 12TB array anymore. Mind you, I didn’t touch this original
> array, but I think what happened was that the I/O error blew 2 of my
> drives.
>
> What I’m thinking of doing is the following, but I’m just looking for
> some advice in case I’m missing anything:
>
> sudo mdadm create --assume-clean --level=6 --raid-devices=7 --size=2930135040 /dev/md127 /dev/sde /dev/sdf /dev/sdg /dev/sdh missing
missing /dev/sdd
Absolutely not!
Your array went from running to dead in minutes, so the variation of
event counts doesn't matter that much. You should forcibly re-assemble
with all devices.
However, before you do *anything*, you need to figure out why so many
devices were ejected from your array. Was it a controller glitch? A
power supply failure? Or, most likely, Unrecoverable Read Errors being
exposed by your first-ever backup, combined with timeout mismatch?
Any attempt to reassemble/recreate/recovery will simply blow up again if
the root cause isn't addressed.
In your next reply, please paste:
1) the dmesg from the time around the event, +/- a few minutes.
2) the output of the following drive diagnostics:
for x in /dev/sd[a-z] ; do echo $x ; smartctl -i -A -l scterc $x ; done
Do *not* perform any --create operation on your array.
*Do* read the list archives linked below -- if any part of it is
unclear, please ask in your next reply.
Phil
[1] http://marc.info/?l=linux-raid&m=139050322510249&w=2
[2] http://marc.info/?l=linux-raid&m=135863964624202&w=2
[3] http://marc.info/?l=linux-raid&m=135811522817345&w=1
[4] http://marc.info/?l=linux-raid&m=133761065622164&w=2
[5] http://marc.info/?l=linux-raid&m=132477199207506
[6] http://marc.info/?l=linux-raid&m=133665797115876&w=2
[7] http://marc.info/?l=linux-raid&m=142487508806844&w=3
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-07 19:17 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <563E479E.50409@turmel.org>
Hi Phil,
First, I want to thank you for taking the time to reply to me, I truly appreciate it. Secondly, I must correct my statement “I added two new arrays to my system last night” … I had started writing this email a few nights ago, and shut down the system in order to prevent me from getting frustrated and doing something stupid. So I walked away from all of it, and just forgot to amend my original email. So the system was off for a few days, and I turned it back on a few minutes before sending my email, and dmesg only shows today’s output, and interestingly enough, no timestamps are on there.
> 1) the dmesg from the time around the event, +/- a few minutes.
Having said that, dmesg isn’t showing me anything from that day either, and I just found out that /var/log/messages doesn’t even exist in my Ubuntu Server 15.04. It seems I have to enable that, so that’s one more thing I’m about to do now. Are there any other ways I could possibly retrieve that? I’m afraid the answer will be a solid “no”, but worth asking.
> 2) the output of the following drive diagnostics:
>
> for x in /dev/sd[a-z] ; do echo $x ; smartctl -i -A -l scterc $x ; done
==========================================================================================
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Blue Serial ATA
Device Model: WDC WD2500AAJS-00VTA0
Serial Number: WD-WMART0793031
LU WWN Device Id: 5 0014ee 0ab2d3f8e
Firmware Version: 01.01B01
User Capacity: 250,059,350,016 bytes [250 GB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 177 177 021 Pre-fail Always - 2125
4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6885
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x000e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 4641
10 Spin_Retry_Count 0x0012 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 226
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 163
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 226
194 Temperature_Celsius 0x0022 116 082 000 Old_age Always - 27
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 4
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00MMMB0
Serial Number: WD-WCAWZ2971763
LU WWN Device Id: 5 0014ee 2b2105a3c
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 1
3 Spin_Up_Time 0x0027 153 148 021 Pre-fail Always - 9350
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 122
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 22291
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 106
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 60
193 Load_Cycle_Count 0x0032 094 094 000 Old_age Always - 318888
194 Temperature_Celsius 0x0022 118 090 000 Old_age Always - 34
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 176 000 Old_age Always - 14946
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00D8PB0
Serial Number: WD-WMC4N0H5ZZ3V
LU WWN Device Id: 5 0014ee 6afd6e011
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 4
3 Spin_Up_Time 0x0027 181 178 021 Pre-fail Always - 5933
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 42
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 3994
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 35
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 13
193 Load_Cycle_Count 0x0032 172 172 000 Old_age Always - 86564
194 Temperature_Celsius 0x0022 118 110 000 Old_age Always - 32
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 895
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00MMMB0
Serial Number: WD-WCAWZ2957084
LU WWN Device Id: 5 0014ee 25cb87409
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 148 144 021 Pre-fail Always - 9600
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 117
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 22299
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 100
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 57
193 Load_Cycle_Count 0x0032 096 096 000 Old_age Always - 314144
194 Temperature_Celsius 0x0022 116 092 000 Old_age Always - 36
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 188 000 Old_age Always - 17745
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00MMMB0
Serial Number: WD-WCAWZ2968521
LU WWN Device Id: 5 0014ee 2b20fc98b
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 148 142 021 Pre-fail Always - 9583
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 123
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 22302
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 104
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 52
193 Load_Cycle_Count 0x0032 092 092 000 Old_age Always - 326940
194 Temperature_Celsius 0x0022 116 096 000 Old_age Always - 36
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 199 000 Old_age Always - 14499
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00SPEB0
Serial Number: WD-WCC4E0437242
LU WWN Device Id: 5 0014ee 25e91d5af
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 6
3 Spin_Up_Time 0x0027 176 172 021 Pre-fail Always - 8200
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 97
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 081 081 000 Old_age Always - 14450
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 81
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 47
193 Load_Cycle_Count 0x0032 159 159 000 Old_age Always - 124845
194 Temperature_Celsius 0x0022 118 099 000 Old_age Always - 34
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 199 000 Old_age Always - 12706
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00MMMB0
Serial Number: WD-WCAWZ2963057
LU WWN Device Id: 5 0014ee 20762f880
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 177 147 021 Pre-fail Always - 8108
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 124
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 070 070 000 Old_age Always - 22301
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 108
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 62
193 Load_Cycle_Count 0x0032 090 090 000 Old_age Always - 330837
194 Temperature_Celsius 0x0022 117 096 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 179 000 Old_age Always - 27256
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.19.0-31-generic] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model: WDC WD30EZRX-00D8PB0
Serial Number: WD-WMC4N1816663
LU WWN Device Id: 5 0014ee 0592d9c0a
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 7 14:03:27 2015 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 165 165 021 Pre-fail Always - 6733
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 36
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2716
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 32
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 11
193 Load_Cycle_Count 0x0032 192 192 000 Old_age Always - 24669
194 Temperature_Celsius 0x0022 122 112 000 Old_age Always - 28
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 182 000 Old_age Always - 1640
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SCT Error Recovery Control command not supported
==========================================================================================
> Do *not* perform any --create operation on your array.
No worries, I’m not touching that. Thank you for your input.
> *Do* read the list archives linked below -- if any part of it is
> unclear, please ask in your next reply.
>
> Phil
>
> [1] http://marc.info/?l=linux-raid&m=139050322510249&w=2
> [2] http://marc.info/?l=linux-raid&m=135863964624202&w=2
> [3] http://marc.info/?l=linux-raid&m=135811522817345&w=1
> [4] http://marc.info/?l=linux-raid&m=133761065622164&w=2
> [5] http://marc.info/?l=linux-raid&m=132477199207506
> [6] http://marc.info/?l=linux-raid&m=133665797115876&w=2
> [7] http://marc.info/?l=linux-raid&m=142487508806844&w=3
Much appreciated, giving those a look now.
Thank you,
Cisco--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-07 21:08 UTC (permalink / raw)
To: Francisco Parada; +Cc: linux-raid
In-Reply-To: <6AC4B7C0-0AE8-4E0A-9B25-049025C386C3@abitofthisabitofthat.com>
On 11/07/2015 02:17 PM, Francisco Parada wrote:
> Hi Phil,
>
> First, I want to thank you for taking the time to reply to me, I truly appreciate it. Secondly, I must correct my statement “I added two new arrays to my system last night” … I had started writing this email a few nights ago, and shut down the system in order to prevent me from getting frustrated and doing something stupid. So I walked away from all of it, and just forgot to amend my original email. So the system was off for a few days, and I turned it back on a few minutes before sending my email, and dmesg only shows today’s output, and interestingly enough, no timestamps are on there.
That's ok. I was looking at the last update times on your mdadm -E reports.
>> 1) the dmesg from the time around the event, +/- a few minutes.
>
> Having said that, dmesg isn’t showing me anything from that day either, and I just found out that /var/log/messages doesn’t even exist in my Ubuntu Server 15.04. It seems I have to enable that, so that’s one more thing I’m about to do now. Are there any other ways I could possibly retrieve that? I’m afraid the answer will be a solid “no”, but worth asking.
Hmm. Did Ubuntu switch to systemd for that version? If so, you'll need to use journalctl. I'm only now learning that, so you'll have to research the options you need yourself. Or others here on the list will chime in :-)
>> 2) the output of the following drive diagnostics:
>>
>> for x in /dev/sd[a-z] ; do echo $x ; smartctl -i -A -l scterc $x ; done
You cut off the "echo $x" part. I very much wanted that to document which drives were which serial numbers.
If you want to be pedantic, combine mdadm -E and smartctl instead:
for x in /dev/sd[a-z] ; do mdadm -E $x ; smartctl -i -A -l scterc $x ; done
However, it is clear from these reports that you are in fact suffering from timeout mismatch:
> SCT Error Recovery Control:
> Read: Disabled
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
> SCT Error Recovery Control command not supported
You will need to apply the workarounds for these drives. The one with scterc disabled is a raid-capable drive that just powers up in desktop mode. Add "smartctl -l scterc,70,70 /dev/sdX" to your boot scripts for that one. For the others, you will need to set a long timeout. For now, before any more mdadm operations, just use the blanket work-around script:
for x in /sys/block/*/device/timeout ; do echo 180 > $x ; done
Now, I didn't see any "Current Pending Sector" counts, so I don't think you are suffering from UREs. In fact, with four of your drives dying together, I suspect you overloaded your power supply(ies) with the extra arrays, either electrically or thermally. The power was OK for idle and trivial operations but couldn't handle the load while copying.
Backup across a gigabit lan if you can't get all the necessary drives into the main case.
> ==========================================================================================
>
>> Do *not* perform any --create operation on your array.
> No worries, I’m not touching that. Thank you for your input.
At this point, I'm confident that your complete set of original drives should just be forcibly assembled:
mdadm -Afv /dev/mdX /dev/sd[b-h]
Replace the device letters if they've changed since your mdadm -E reports.
There might be minor filesystem damage if any blocks were in flight to the array when it died. fsck, then mount.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-07 23:07 UTC (permalink / raw)
To: Francisco Parada; +Cc: linux-raid
In-Reply-To: <C57F2260-D20C-4688-93F6-CB3CE8CF9F30@abitofthisabitofthat.com>
On 11/07/2015 05:18 PM, Francisco Parada wrote:
> So it looks like /var/log/syslog is where it’s storing those values,
> I’ve included the full log for that day (gzip attached), but for
> completion, here are the times I see dropped drives first start happening:
[trim /]
Ok. Those four drives cut out within a few milliseconds of each other.
>> However, it is clear from these reports that you are in fact suffering
>> from timeout mismatch:
> Thanks, I didn’t realize that. Here is my command, because your’s
> wasn’t giving me the mdadm portion for some reason:
Because I do all such maintenance as root. In an ubuntu system, use
"sudo su -" to get a full root console.
[trim /]
Also, in the future, turn off word wrap when pasting. :-)
> Thanks, I’ll mount those and circle back. I’m going to head out due to
> a family dinner, so I’ll circle back once I’m done. Once again, thank
> you kindly for your insight!!!
No hurry. And you're welcome.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID6 reshape stalls immediately
From: Peter Chubb @ 2015-11-08 4:18 UTC (permalink / raw)
To: Anugraha Sinha; +Cc: Peter Chubb, linux-raid
In-Reply-To: <563CAFC1.2080708@gmail.com>
>>>>> "Anugraha" == Anugraha Sinha <asinha.mailinglist@gmail.com> writes:
Anugraha> Dear Peter, What happening on the root partition where you
Anugraha> are trying to take a backup?
Anugraha> Any I/O, filesize etc?
ls -l /root/raid5-backup
-rw------- 1 root root 6295552 Nov 4 12:04 raid5-backup
It hasn't changed since the first write when the reshape started.
Anugraha> Also could you share the output of mdadm --examine <all of
Anugraha> your 6 raid members individually?
Here:
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : 4f5d0861:9a512ce8:d4233208:5bd1e094
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : d1f1a56f - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : fbd91407:208c66cc:1020f996:d7b1cd5d
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : b3ec395a - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : 074e15ab:5508d37d:931e4e42:ecb6476e
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : c5282d36 - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : 785d7bee:4bd7939c:8303ba47:64f40faf
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 6d832e04 - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x5
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : a473e815:4efb6be4:45db7fe4:c3f5dce2
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : ad5b4157 - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 5
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x7
Array UUID : 6ff23c3d:01042464:77338dc6:710dfaee
Name : lemma:0 (local to host lemma)
Creation Time : Tue Oct 27 11:52:53 2015
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 3906748416 (1862.88 GiB 2000.26 GB)
Array Size : 7813496832 (7451.53 GiB 8001.02 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Recovery Offset : 0 sectors
Unused Space : before=262056 sectors, after=0 sectors
State : clean
Device UUID : 46872307:b4a769e3:38ebf84c:a031d4dd
Internal Bitmap : 8 sectors from superblock
Reshape pos'n : 0
Delta Devices : 1 (5->6)
New Layout : left-symmetric
Update Time : Sun Nov 8 15:12:08 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 1044d32 - correct
Events : 48094
Layout : left-symmetric-6
Chunk Size : 512K
Device Role : Active device 4
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
And /proc/mdstat is still:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdi1[6] sdh1[5] sdd1[4] sde1[2] sdb1[1] sda1[0]
5860122624 blocks super 1.2 level 6, 512k chunk, algorithm 18 [6/5] [UUUU_U]
[>....................] reshape = 0.0% (0/1953374208) finish=5766.8min speed=5469K/sec
bitmap: 0/15 pages [0KB], 65536KB chunk
unused devices: <none>
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-08 5:59 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <563E843E.5060108@turmel.org>
> Ok. Those four drives cut out within a few milliseconds of each other.
So I checked the enclosure’s PSU voltages, and it looks like the +5V rail was running at around +3V and the +12V rail at almost +8V under load. So I think your original theory of there being a power issue is correct. It’s a bummer, because I have 2 of these Rosewill 8-bay enclosures, and they both show that same issue. This is very likely why they’ve been discontinued. Granted the speed on them is 1.5Gbps total per channel, but it’s really just for movies, so I’m not concerned about high speed read and writes. I’ll just have to McGuyver it and use different PSUs than the ones they came with. I would imagine, that after about 500GB worth of data being transferred, all the writing caused those drives to get pretty hot, making the PSU that much more likely to cut power.
http://www.newegg.com/Product/Product.aspx?Item=N82E16816132016
> Because I do all such maintenance as root. In an ubuntu system, use
> "sudo su -" to get a full root console.
Ah, gotcha!
> Also, in the future, turn off word wrap when pasting. :-)
Boom! Done deal, there was a setting in my Apple Mail application under Mail -> Preferences -> Fonts & Colors -> “Use fixed-width font for plain text messages”. I think this might fix this word wrap issue, so my apologies. It’s either that, or the fact that I copied and pasted directly from my Terminal application, and it converted the email to HTML, which changed the format.
Now, onto the butter. I tried what you told me, and it showed that the devices were busy:
====================================================
cisco@DoctorBanner:~$ sudo mdadm -Afv /dev/md127 /dev/sd[b-h]
mdadm: looking for devices for /dev/md127
mdadm: /dev/sdb is busy - skipping
mdadm: /dev/sdc is busy - skipping
mdadm: /dev/sdd is busy - skipping
mdadm: /dev/sde is busy - skipping
mdadm: /dev/sdf is busy - skipping
mdadm: /dev/sdg is busy - skipping
mdadm: /dev/sdh is busy - skipping
====================================================
So I continued to stop the array:
====================================================
cisco@DoctorBanner:~$ sudo mdadm --stop /dev/md127
mdadm: stopped /dev/md127
====================================================
Then I tried it once again, but it seems that because they’re displaying that the Events are out of sync, that it’s not able to start the array. Any ideas?
====================================================
cisco@DoctorBanner:~$ sudo mdadm -Afv /dev/md127 /dev/sd[b-h]
mdadm: looking for devices for /dev/md127
mdadm: /dev/sdb is identified as a member of /dev/md127, slot 3.
mdadm: /dev/sdc is identified as a member of /dev/md127, slot 4.
mdadm: /dev/sdd is identified as a member of /dev/md127, slot 5.
mdadm: /dev/sde is identified as a member of /dev/md127, slot 0.
mdadm: /dev/sdf is identified as a member of /dev/md127, slot 1.
mdadm: /dev/sdg is identified as a member of /dev/md127, slot 2.
mdadm: /dev/sdh is identified as a member of /dev/md127, slot -1.
mdadm: added /dev/sdf to /dev/md127 as 1
mdadm: added /dev/sdg to /dev/md127 as 2
mdadm: added /dev/sdb to /dev/md127 as 3 (possibly out of date)
mdadm: added /dev/sdc to /dev/md127 as 4 (possibly out of date)
mdadm: added /dev/sdd to /dev/md127 as 5 (possibly out of date)
mdadm: added /dev/sdh to /dev/md127 as -1
mdadm: added /dev/sde to /dev/md127 as 0
mdadm: /dev/md127 assembled from 3 drives and 1 spare - not enough to start the array.
====================================================
Thanks again,
Cisco----
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-08 14:20 UTC (permalink / raw)
To: Francisco Parada; +Cc: linux-raid
In-Reply-To: <251B709D-3310-433E-8817-E875194A69F9@abitofthisabitofthat.com>
On 11/08/2015 12:59 AM, Francisco Parada wrote:
>
>> Ok. Those four drives cut out within a few milliseconds of each other.
> So I checked the enclosure’s PSU voltages, and it looks like the +5V rail was running at around +3V and the +12V rail at almost +8V under load. So I think your original theory of there being a power issue is correct. It’s a bummer, because I have 2 of these Rosewill 8-bay enclosures, and they both show that same issue. This is very likely why they’ve been discontinued. Granted the speed on them is 1.5Gbps total per channel, but it’s really just for movies, so I’m not concerned about high speed read and writes. I’ll just have to McGuyver it and use different PSUs than the ones they came with. I would imagine, that after about 500GB worth of data being transferred, all the writing caused those drives to get pretty hot, making the PSU that much more likely to cut power.
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132016
I consider this *good* news :-)
>> Also, in the future, turn off word wrap when pasting. :-)
> Boom! Done deal, there was a setting in my Apple Mail application under Mail -> Preferences -> Fonts & Colors -> “Use fixed-width font for plain text messages”. I think this might fix this word wrap issue, so my apologies. It’s either that, or the fact that I copied and pasted directly from my Terminal application, and it converted the email to HTML, which changed the format.
Apple Mail? Eeeewwww! :-)
In Thunderbird, word wrap is a separate setting. You might want to
experiment a bit.
> Now, onto the butter. I tried what you told me, and it showed that the devices were busy:
Yeah, that's normal with partial successes. Also, consider not using
md127. That's mdadm's "I don't know what number to use" default.
(Followed by 126, then 125, as so on.)
> Then I tried it once again, but it seems that because they’re displaying that the Events are out of sync, that it’s not able to start the array. Any ideas?
The --force option is supposed to override that. I suspect since you
are running an old kernel, 3.19, you are also runnning an old mdadm. I
recall some assemble bugs being fixed in the past few years. Boot your
system temporarily with a rescue CD -- I recommend the one at
www.sysrescuecd.org -- that has current kernels and mdadm. That'll let
you complete the assembly. After that, with the array idle, a normal
shutdown will let your old kernel assemble it.
Consider upgrading your system when all is safe.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-08 14:48 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <563F5A1B.30506@turmel.org>
> Apple Mail? Eeeewwww! :-)
Hah! Jerk! ;-) Just kidding
> Yeah, that's normal with partial successes. Also, consider not using
> md127. That's mdadm's "I don't know what number to use" default.
> (Followed by 126, then 125, as so on.)
Just want to clarify this bit. Are you saying I should use a number as such to mount it now instead the 127 that it was called until the failure? Or in the future? For the two newer arrays, I had called them 500 and 400, just to be safe so there was no overlap.
[trim /]
> Consider upgrading your system when all is safe.
OK, I wasn't too sure how safe it was to upgrade the kernel to something that Canonical wasn't even using on 15.04 ... But I'll do some more research.
I'll use the recovery media option to give that a shot, and report back shortly.
You're a rockstar!
Thank you,
Cisco--
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-08 16:32 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <31D02BFE-239B-42BE-9176-10DF20A78A9C@abitofthisabitofthat.com>
Phil,
You fucking rock, dude! Systemrescd did the trick. I had to force the assembly twice, but after that, it worked like a charm. I want to thank you from the bottom of my geek's heart! I was struggling to find an answer online, and everyone pointed to recreating the array. I'm so happy I found this mailing list, but further more, I thank my lucky stars that I came across YOU during this treacherous endeavor. My friend, you're a gentlemen and a scholar, nay ... A fucking Viking Berserker, is what you are! You have no idea how much of a big help you were to me, thank you ever so much.
I really can't thank you enough. I have certainly met my match with mdadm, and was truly humbled by this experience.
Thank you, thank you, thank you!!!!!
Cisco
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-08 17:25 UTC (permalink / raw)
To: Francisco Parada; +Cc: linux-raid
In-Reply-To: <6ACBF682-29BA-4AE7-827C-7D6C93566C7D@abitofthisabitofthat.com>
On 11/08/2015 11:32 AM, Francisco Parada wrote:
> Phil,
>
> You f***ing rock, dude! Systemrescd did the trick. I had to force
> the assembly twice, but after that, it worked like a charm. I want to
> thank you from the bottom of my geek's heart! I was struggling to
> find an answer online, and everyone pointed to recreating the array.
> I'm so happy I found this mailing list, but further more, I thank my
> lucky stars that I came across YOU during this treacherous endeavor.
> My friend, you're a gentlemen and a scholar, nay ... A f***ing Viking
> Berserker, is what you are! You have no idea how much of a big help
> you were to me, thank you ever so much.
Viking Berserker? Cool! Although, with my ancestry, Brittany Pirate
might be more appropriate.
{ I had to share this with my wife... She is amused, btw. }
> I really can't thank you enough. I have certainly met my match with
> mdadm, and was truly humbled by this experience.
>
> Thank you, thank you, thank you!!!!!
You're very welcome. Glad to help.
Phil
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Francisco Parada @ 2015-11-08 17:32 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <563F859B.9010708@turmel.org>
> Viking Berserker? Cool! Although, with my ancestry, Brittany Pirate
> might be more appropriate.
You deserve whatever title you want to give yourself! I knight you, Sir Brittany Pirate of Tortuga
> { I had to share this with my wife... She is amused, btw. }
Haha!! I'm happy to return the joy you've given me as well.
Thanks!!!!!!
Cisco
^ permalink raw reply
* Re: RAID 6 Not Mounting (Block device is empty)
From: Phil Turmel @ 2015-11-08 17:48 UTC (permalink / raw)
To: Francisco Parada; +Cc: linux-raid
In-Reply-To: <31D02BFE-239B-42BE-9176-10DF20A78A9C@abitofthisabitofthat.com>
Forgot to answer this one.
On 11/08/2015 09:48 AM, Francisco Parada wrote:
>
>> Apple Mail? Eeeewwww! :-)
> Hah! Jerk! ;-) Just kidding
I'm a Linux enthusiast all the way -- servers, desktops, laptop, android
phone, ddwrt routers, etc. I suffer to run Windows for some work
applications, but only in a VM.
>> Yeah, that's normal with partial successes. Also, consider not using
>> md127. That's mdadm's "I don't know what number to use" default.
>> (Followed by 126, then 125, as so on.)
> Just want to clarify this bit. Are you saying I should use a number as such to mount it now instead the 127 that it was called until the failure? Or in the future? For the two newer arrays, I had called them 500 and 400, just to be safe so there was no overlap.
You need an mdadm.conf file that calls out your arrays by name and uuid.
Your distro probably put a template in either /etc/ or /etc/mdadm/.
You can append your current running setup with:
mdadm -Es >>/etc/mdadm/mdadm.conf
Then trim the ARRAY lines to just:
ARRAY /dev/md1 UUID=......
Then use 'update-initramfs' or whatever ubuntu is using in 15.10 to
install that into your early boot environment.
Don't forget to fix your timeout mismatch problem.
Phil
^ permalink raw reply
* Re:linux-raid在?！(AD)
From: nxhz2010 @ 2015-11-08 19:13 UTC (permalink / raw)
To: linux-raid
linux-raid
欢迎加入爱奇艺vip分享QQ群：5650047 每天发放好几波爱奇艺vip会员，看蜀山战纪，灵魂摆渡2等热门大片不要钱！限时开放！验证码511
偏置管！时筑偃湖未成；通玄先生“火系掌门，金相观察“男式羊毛？岁暮采芳菲：长廊朝雨毕：客车特种车，枯查卷拔树？万士和“旋复花粉？元羽墓志。温努斯“蓝色美酒帽！九口乡；羽月仁美“碳化硅辐射管“创伤性眼睑异物“拉什鸦巢法阵。一半是春冰？鼓山！胃出血经导管栓塞“靛羽風蓮，七九五五年！人遂倚门情；虚空间。康乐福传统菜馆。马记食府；滇沙针？时见疏星渡河汉！
^ permalink raw reply
* [GIT PULL REQUET] on config fix for md
From: NeilBrown @ 2015-11-08 22:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arnd Bergmann, linux-raid, LKML
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
The following changes since commit 69234acee54407962a20bedf90ef9c96326994b5:
Merge branch 'for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2015-11-05 14:51:32 -0800)
are available in the git repository at:
git://neil.brown.name/md tags/md/4.4-rc0-fix
for you to fetch changes up to 14f09e2f9b85076133b795a2d2615f635482de1b:
raid5-cache: add crc32c Kconfig dependency (2015-11-09 09:09:52 +1100)
----------------------------------------------------------------
config fix for md
config dependency needed as md/raid5 now uses crc32c
----------------------------------------------------------------
Arnd Bergmann (1):
raid5-cache: add crc32c Kconfig dependency
drivers/md/Kconfig | 1 +
1 file changed, 1 insertion(+)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* European Union
From: Eurpean, Union @ 2015-11-08 23:59 UTC (permalink / raw)
To: ME
I am Zurlinden Thomas, European Union Payout Officer in switzerland in charge of processing and remitting payment to all Beneficiaries of the European Union Compensation Scheme.We have £4,000,000.00.of your compensation funds from the European Union Government.
Please be informed that the funds are coming directly from the European Union, It is a Compensation from the European Union to all Victims of Global financial,Scammed Victims and Economic Meltdown and your email has been randomly selected as one of the lucky beneficiaries.
we have been authorize to Transfer your full compensation payment of £4,000,000.00.You are required to provide these details to enable us proceed with your transfer:
Full Names.
Country
Direct Phone Number.
Regards
EU Board.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/8] zram: handle add_disk() & blk_register_region() return value
From: Sergey Senozhatsky @ 2015-11-09 1:07 UTC (permalink / raw)
To: Vishnu Pratap Singh
Cc: axboe, akpm, linux-kernel, jmoyer, minchan, ngupta,
sergey.senozhatsky.work, davem, neilb, ulf.hansson, tiwai, hare,
ming.lei, jarod, viro, tj, adrian.hunter, jonathanh, grundler,
linux-ide, linux-raid, linux-mmc, cpgs, vishu13285, pintu.k,
rohit.kr
In-Reply-To: <1446812535-10567-5-git-send-email-vishnu.ps@samsung.com>
On (11/06/15 17:52), Vishnu Pratap Singh wrote:
> This patch adds error handling for blk_register_region(),
> register_disk(), add_disk(), disk_alloc_events() & disk_add_events().
> add_disk() & register_disk() functions error handling is very much
> needed as this is used mainly by many modules like mmc, zram, mtd, scsi etc.
> But there is no error handling and it may cause stability issues also.
hm... I came across "FIXME: error handling" comment in add_disk() some
time ago and after a quick google search I found this:
https://lkml.org/lkml/2007/7/24/207
>> The attached patch fixes the problem by changing the prototype of
>> add_disk() and register_disk() to return errors.
Al Viro wrote:
> This is bogus. Just what would callers do with these error values?
> Ignore them silently? Bail out? Can't do - at that point disk just
> might have been opened already. add_disk() is the point of no return;
> we are already past the last point where we could bail out.
> drivers/block/z2ram.c | 12 ++++++++++--
> drivers/block/zram/zram_drv.c | 9 ++++++---
those are different drivers, split the patches (well, if add_disk()
change actually makes sense).
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
> index 968f9e5..85e841f 100644
> --- a/drivers/block/z2ram.c
> +++ b/drivers/block/z2ram.c
> @@ -364,12 +364,20 @@ z2_init(void)
> sprintf(z2ram_gendisk->disk_name, "z2ram");
>
> z2ram_gendisk->queue = z2_queue;
> - add_disk(z2ram_gendisk);
> - blk_register_region(MKDEV(Z2RAM_MAJOR, 0), Z2MINOR_COUNT, THIS_MODULE,
> + ret = add_disk(z2ram_gendisk);
> + if (ret)
> + goto out_add_disk;
> +
> + ret = blk_register_region(MKDEV(Z2RAM_MAJOR, 0), Z2MINOR_COUNT, THIS_MODULE,
> z2_find, NULL, NULL);
> + if (ret)
> + goto out_blk_reg;
A separate nitpick. z2_init() coding styles need to be 'fixed'. So the
patch will not violate the kernel coding styles.
./scripts/checkpatch.pl
WARNING: please, no spaces at the start of a line
#113: FILE: drivers/block/z2ram.c:367:
+ ret = add_disk(z2ram_gendisk);$
WARNING: please, no spaces at the start of a line
#114: FILE: drivers/block/z2ram.c:368:
+ if (ret)$
WARNING: please, no spaces at the start of a line
#117: FILE: drivers/block/z2ram.c:371:
+ ret = blk_register_region(MKDEV(Z2RAM_MAJOR, 0), Z2MINOR_COUNT,
THIS_MODULE,$
WARNING: please, no spaces at the start of a line
#119: FILE: drivers/block/z2ram.c:373:
+ if (ret)$
total: 0 errors, 4 warnings, 50 lines checked
>
> return 0;
>
> +out_blk_reg:
> + del_gendisk(z2ram_gendisk);
> +out_add_disk:
> out_queue:
Hm... a fall-through empty `out_add_disk' label?
-ss
> put_disk(z2ram_gendisk);
> out_disk:
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 81a557c..f3d7a49 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1261,14 +1261,16 @@ static int zram_add(void)
> zram->disk->queue->limits.discard_zeroes_data = 0;
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, zram->disk->queue);
>
> - add_disk(zram->disk);
> + ret = add_disk(zram->disk);
> + if (ret)
> + goto out_free_disk;
>
> ret = sysfs_create_group(&disk_to_dev(zram->disk)->kobj,
> &zram_disk_attr_group);
> if (ret < 0) {
> pr_err("Error creating sysfs group for device %d\n",
> device_id);
> - goto out_free_disk;
> + goto out_del_disk;
> }
> strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
> zram->meta = NULL;
> @@ -1277,8 +1279,9 @@ static int zram_add(void)
> pr_info("Added device: %s\n", zram->disk->disk_name);
> return device_id;
>
> -out_free_disk:
> +out_del_disk:
> del_gendisk(zram->disk);
> +out_free_disk:
> put_disk(zram->disk);
> out_free_queue:
> blk_cleanup_queue(queue);
> --
> 1.9.1
>
^ permalink raw reply
* Offline array, events count mismatch
From: Guillaume Paumier @ 2015-11-09 2:49 UTC (permalink / raw)
To: linux-raid
Hello folks,
I reached out to you a few months ago when a --grow went awry. In the end I
managed to restore my array thanks to this mailing list and the invaluable
help of IRC user frostschutz.
I'm now facing another issue and I'm hoping you can help me again.
Today I found out that my RAID6, 9-disk array was offline. When looking at the
machine, two disks seemed to have disappeared; they didn't show in fdisk or
anything. And a third one was marked as "faulty" in mdadm.
At first, I was puzzled because it seemed improbable that three disks had
failed at the same time. I removed the array from fstab and rebooted. The two
vanished disks re-appeared (in fdisk too), and when examining the partitions,
I noticed the following events count:
/dev/sdb1:
Events : 198477
/dev/sdc1:
Events : 198477
/dev/sdd1:
Events : 198477
/dev/sde1:
Events : 54264
/dev/sdf1:
Events : 54264
/dev/sdg1:
Events : 198477
/dev/sdh1:
Events : 198477
/dev/sdi1:
Events : 198477
/dev/sdj1:
Events : 198473
Looking at those event counts, my understanding is this:
* Two of the disks (sde, sdf) were dropped from the array for some reason.
* I didn't notice this immediately (an issue I'm addressing separately).
* A third disk (sdj) encountered a small issue today.
* The array went offline because it didn't have enough disks to function
cleanly any more.
If I understand the documentation [1] correctly, since the event count for sdj
is very close to the event count of sd[b,c,d,g,h,i], I should be able to re-
assemble the array with these 7 disks using --force, leaving sde and sdf
aside. Once the array is assembled, I should be able to re-add sde and sdf,
and they will be re-sync'd.
[1]
https://raid.wiki.kernel.org/index.php/RAID_Recovery#Trying_to_assemble_using_--force
I prefer to be cautious and ask here before doing anything that could make
things worse. It would be great if you could confirm that my understanding is
correct, and tell me if this plan is sound.
I'm including some more detailed information below. Let me know if there's any
other information that would be useful.
Many thanks,
===========================================================
Before the reboot: mdadm -D
-----------------------------------------------------------
# mdadm -D /dev/md0
/dev/md0:
Version : 1.0
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 3907016448 (3726.02 GiB 4000.78 GB)
Raid Devices : 9
Total Devices : 8
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Sun Nov 8 06:36:50 2015
State : clean, FAILED
Active Devices : 6
Working Devices : 6
Failed Devices : 2
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 128K
UUID : eea59047:120a0365:353da182:6787e030
Events : 198477
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
2 8 97 2 active sync /dev/sdg1
3 8 113 3 active sync /dev/sdh1
4 8 129 4 active sync /dev/sdi1
10 0 0 10 removed
12 0 0 12 removed
14 0 0 14 removed
8 8 17 8 active sync /dev/sdb1
5 8 145 - faulty /dev/sdj1
6 8 65 - faulty /dev/sde1
===========================================================
Before the reboot: mdadm --examine
-----------------------------------------------------------
# mdadm --examine /dev/sd[b-j]1
/dev/sdb1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033128 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 91b187fd:f416880a:f5e81e49:92615e07
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 30050dee - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 8
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : e1b689b5:b4a2c5a7:56057b69:a9101af0
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 8e546a7e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 1d8e74d3:9abd37f8:f2cf0ab8:02fdcfd6
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 31f71397 - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
mdadm: No md superblock detected on /dev/sde1.
/dev/sdg1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : b24758e6:042412c5:9b5a3c06:f167aedf
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 68c5292e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 00e47d82:b49c3905:3ed961fe:40a5f259
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : b77bfa1e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : a7e34040:fa12382f:c2ef3d85:9c95b1d0
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 9cd876ec - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdj1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 9d89c55d:9f4a2181:6b87922f:0681d580
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:38 2015
Checksum : 66c5dfd2 - correct
Events : 198473
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA..A ('A' == active, '.' == missing, 'R' == replacing)
===========================================================
After the reboot: mdadm --examine
-----------------------------------------------------------
# mdadm --examine /dev/sd[b-j]1
/dev/sdb1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033128 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 91b187fd:f416880a:f5e81e49:92615e07
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : 30050dee - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 8
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : e1b689b5:b4a2c5a7:56057b69:a9101af0
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 8e546a7e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 0
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 1d8e74d3:9abd37f8:f2cf0ab8:02fdcfd6
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 31f71397 - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 1
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : ddf17d3d:ea944bfb:6886cc91:3366f55f
Internal Bitmap : -16 sectors from superblock
Update Time : Wed Oct 7 10:17:35 2015
Checksum : 1dd30b1 - correct
Events : 54264
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 7
Array State : AAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 38675f59:ea412b1f:67d6ed9a:a33fc5dd
Internal Bitmap : -16 sectors from superblock
Update Time : Wed Oct 7 10:17:35 2015
Checksum : c88f7c7b - correct
Events : 54264
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 6
Array State : AAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdg1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : b24758e6:042412c5:9b5a3c06:f167aedf
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 68c5292e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 2
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 00e47d82:b49c3905:3ed961fe:40a5f259
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : b77bfa1e - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 3
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : a7e34040:fa12382f:c2ef3d85:9c95b1d0
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:50 2015
Checksum : 9cd876ec - correct
Events : 198477
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 4
Array State : AAAAA...A ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdj1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : eea59047:120a0365:353da182:6787e030
Creation Time : Thu Aug 1 12:23:07 2013
Raid Level : raid6
Raid Devices : 9
Avail Dev Size : 7814033136 (3726.02 GiB 4000.78 GB)
Array Size : 27349115136 (26082.15 GiB 28005.49 GB)
Used Dev Size : 7814032896 (3726.02 GiB 4000.78 GB)
Super Offset : 7814033392 sectors
Unused Space : before=0 sectors, after=480 sectors
State : clean
Device UUID : 9d89c55d:9f4a2181:6b87922f:0681d580
Internal Bitmap : -16 sectors from superblock
Update Time : Sun Nov 8 06:36:38 2015
Checksum : 66c5dfd2 - correct
Events : 198473
Layout : left-symmetric
Chunk Size : 128K
Device Role : Active device 5
Array State : AAAAAA..A ('A' == active, '.' == missing, 'R' == replacing)
===========================================================
--
Guillaume Paumier
^ permalink raw reply
* Re: Offline array, events count mismatch
From: Phil Turmel @ 2015-11-09 3:35 UTC (permalink / raw)
To: Guillaume Paumier, linux-raid
In-Reply-To: <1903758.3ih4aa4jR2@carbon.lepommierdujardin.fr>
Hi Guillaume,
On 11/08/2015 09:49 PM, Guillaume Paumier wrote:
[trim /]
> Looking at those event counts, my understanding is this:
> * Two of the disks (sde, sdf) were dropped from the array for some reason.
> * I didn't notice this immediately (an issue I'm addressing separately).
> * A third disk (sdj) encountered a small issue today.
> * The array went offline because it didn't have enough disks to function
> cleanly any more.
>
> If I understand the documentation [1] correctly, since the event count for sdj
> is very close to the event count of sd[b,c,d,g,h,i], I should be able to re-
> assemble the array with these 7 disks using --force, leaving sde and sdf
> aside. Once the array is assembled, I should be able to re-add sde and sdf,
> and they will be re-sync'd.
Yes, that is the correct response.
Your situation is common. Please see the thread this weekend started by
Franscisco Parada.
https://marc.info/?t=144691643300001&r=1&w=2&n=12
You should provide "smartctl -i -A -l scterc /dev/sdX" reports for your
drives. If you can find an old syslog for when your two worst drives
fell out, it might help.
Phil
^ permalink raw reply
* Re: [PATCH 06/32] xen blkback: prepare for bi_rw split
From: Bob Liu @ 2015-11-09 4:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-scsi, linux-kernel, linux-raid, dm-devel, mchristi,
linux-fsdevel, xen-devel, drbd-dev
In-Reply-To: <20151107101713.GB12117@infradead.org>
On 11/07/2015 06:17 PM, Christoph Hellwig wrote:
> A little offtopic for this patch, but can some explain this whole
> mess about bios in Xen blkfront? We can happily do partial completions
> at the request later.
>
> Also since the blk-mq conversion the call to blk_end_request_all is
This will be fixed after my next blk-mq patch series which also modified the recover path.
> completely broken, so it doesn't look like this code path is exactly
> well tested.
>
Thanks,
-Bob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox