* [PATCH] mdadm/grow: reshape would be stuck from raid1 to raid5
From: Zhilong Liu @ 2017-03-20 5:20 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid, Zhilong Liu
it would be stuck at the beginning of reshape progress
when grows array from raid1 to raid5, correct the name
of mdadm-grow-continue@.service in continue_via_systemd.
reproduce steps:
./mdadm -CR /dev/md0 -l1 -b internal -n2 /dev/loop[0-1]
./mdadm --grow /dev/md0 -l5 -n3 -a /dev/loop2
Signed-off-by: Zhilong Liu <zlliu@suse.com>
---
Grow.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Grow.c b/Grow.c
index 455c5f9..10c02a1 100755
--- a/Grow.c
+++ b/Grow.c
@@ -2808,13 +2808,11 @@ static int continue_via_systemd(char *devnm)
*/
close(2);
open("/dev/null", O_WRONLY);
- snprintf(pathbuf, sizeof(pathbuf), "mdadm-grow-continue@%s.service",
- devnm);
+ snprintf(pathbuf, sizeof(pathbuf), "mdadm-grow-continue@.service");
status = execl("/usr/bin/systemctl", "systemctl",
"start",
pathbuf, NULL);
- status = execl("/bin/systemctl", "systemctl", "start",
- pathbuf, NULL);
+ pr_err("/usr/bin/systemctl %s got failure\n", pathbuf);
exit(1);
case -1: /* Just do it ourselves. */
break;
--
2.6.6
^ permalink raw reply related
* [PATCH] mdadm:fixed some trivial typos in comments of mdadm.h
From: Zhilong Liu @ 2017-03-20 5:20 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid, Zhilong Liu
mdadm.h: fixed some trivial typos in comments
Signed-off-by: Zhilong Liu <zlliu@suse.com>
---
mdadm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mdadm.h b/mdadm.h
index 71b8afb..91fd9eb 100644
--- a/mdadm.h
+++ b/mdadm.h
@@ -552,7 +552,7 @@ struct mdstat_ent {
char devnm[32];
int active;
char *level;
- char *pattern; /* U or up, _ for down */
+ char *pattern; /* U for up, _ for down */
int percent; /* -1 if no resync */
int resync; /* 3 if check, 2 if reshape, 1 if resync, 0 if recovery */
int devcnt;
@@ -742,7 +742,7 @@ struct reshape {
unsigned long long new_size; /* New size of array in sectors */
};
-/* A superswitch provides entry point the a metadata handler.
+/* A superswitch provides entry point to a metadata handler.
*
* The superswitch primarily operates on some "metadata" that
* is accessed via the 'supertype'.
--
2.6.6
^ permalink raw reply related
* [PATCH] mdadm:checking --level once mode has been set
From: Zhilong Liu @ 2017-03-20 5:17 UTC (permalink / raw)
To: jes.sorensen; +Cc: linux-raid, Zhilong Liu
mdadm: it would be better to check --level ealier,
because it would fall to different prompt if user
forgets to specify the --level. such as:
./mdadm --build /dev/md0 -n2 /dev/loop[0-1]
Signed-off-by: Zhilong Liu <zlliu@suse.com>
---
Create.c | 4 ----
mdadm.c | 6 ++++++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Create.c b/Create.c
index 2721884..50ec85e 100644
--- a/Create.c
+++ b/Create.c
@@ -125,10 +125,6 @@ int Create(struct supertype *st, char *mddev,
memset(&info, 0, sizeof(info));
if (s->level == UnSet && st && st->ss->default_geometry)
st->ss->default_geometry(st, &s->level, NULL, NULL);
- if (s->level == UnSet) {
- pr_err("a RAID level is needed to create an array.\n");
- return 1;
- }
if (s->raiddisks < 4 && s->level == 6) {
pr_err("at least 4 raid-devices needed for level 6\n");
return 1;
diff --git a/mdadm.c b/mdadm.c
index d6ad8dc..fcb33d1 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -349,6 +349,12 @@ int main(int argc, char *argv[])
pr_err("Must give -a/--add for devices to add: %s\n", optarg);
exit(2);
}
+ if (devs_found > 0 && s.level == UnSet && !devmode) {
+ if (mode == CREATE || mode == BUILD) {
+ pr_err("a RAID level is needed to create or build an array.\n");
+ exit(2);
+ }
+ }
dv = xmalloc(sizeof(*dv));
dv->devname = optarg;
dv->disposition = devmode;
--
2.6.6
^ permalink raw reply related
* Re: strange mirror write perf
From: Roman Mamedov @ 2017-03-20 5:07 UTC (permalink / raw)
To: Youenn Gestin; +Cc: Adam Goryachev, linux-raid
In-Reply-To: <91d1857a35f0c659387a409cc147ac92@grim-is-a-geek.fr>
On Mon, 20 Mar 2017 01:44:09 +0100
Youenn Gestin <youenn.gestin@grim-is-a-geek.fr> wrote:
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to
> conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,5074 s, 146 MB/s
>
> I'll check about this function to see if i'll need it or not tomorow,
Instead of disabling it you can alter the bitmap chunk size, and at larger
chunk sizes it does not affect the performance as much.
http://tgharold.blogspot.fr/2013/01/mdadm-using-bitmaps-to-speed-up-rebuilds.html
For 6TB drives try 256 or even 512MB for the size.
--
With respect,
Roman
^ permalink raw reply
* Re: [PATCH V1] md/raid10: refactor some codes from raid10_write_request
From: kbuild test robot @ 2017-03-20 5:05 UTC (permalink / raw)
Cc: kbuild-all, linux-raid, shli, neilb, Guoqing Jiang
In-Reply-To: <1489743917-10895-1-git-send-email-gqjiang@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hi Guoqing,
[auto build test ERROR on next-20170310]
[also build test ERROR on v4.11-rc3]
[cannot apply to md/for-next v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Guoqing-Jiang/md-raid10-refactor-some-codes-from-raid10_write_request/20170320-124148
config: x86_64-randconfig-x004-201712 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/md/raid10.c: In function 'raid10_write_one_disk':
>> drivers/md/raid10.c:1203:29: error: 'i' undeclared (first use in this function)
int devnum = r10_bio->devs[i].devnum;
^
drivers/md/raid10.c:1203:29: note: each undeclared identifier is reported only once for each function it appears in
vim +/i +1203 drivers/md/raid10.c
1197 const unsigned long do_fua = (bio->bi_opf & REQ_FUA);
1198 unsigned long flags;
1199 struct blk_plug_cb *cb;
1200 struct raid10_plug_cb *plug = NULL;
1201 struct r10conf *conf = mddev->private;
1202 struct md_rdev *rdev;
> 1203 int devnum = r10_bio->devs[i].devnum;
1204 struct bio *mbio;
1205
1206 if (replacement) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26911 bytes --]
^ permalink raw reply
* Re: strange mirror write perf
From: Peter Grandi @ 2017-03-20 0:53 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <c0981a7c8b13facace1228ed0f99efdc@grim-is-a-geek.fr>
[ ... ]
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdd conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,1238 s, 150 MB/s
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdc conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,7046 s, 144 MB/s
[ ... ]
> mdadm: automatically enabling write-intent bitmap on large array
[ ... ]
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 21,1528 s, 100 MB/s
[ ... ]
This is not about "performance" but raw speed in a very
particular situation. The difference is not large and could be
meaningless for a variety of reasons:
* Had the initial 6TB sync finished (would take 15-17 hours)?
* Internal bitmaps can steal a fair bit of speed.
* For whatever weirdness is related to the appalling
implementation of the Linux page cache, IO reading (but less
so writing) an MD block device is often slower than to a file
on a filetree on that block device, plus writing via the page
cache costs a lot of CPU time.
Replication of the experiment on similar smaller disks:
soft# mdadm --create --verbose /dev/md/md6to --level=1 --raid-devices=2 /dev/sde3 /dev/sdf3
mdadm: size set to 243269440K
mdadm: array /dev/md/md6to started.
soft# grep -A2 'sd[ef]3' /proc/mdstat
md127 : active raid1 sdf3[1] sde3[0]
243269440 blocks super 1.0 [2/2] [UU]
[====>................] resync = 20.5% (49954880/243269440) finish=19.5min speed=164445K/sec
soft# grep -A2 'sd[ef]3' /proc/mdstat; dd bs=1M count=2024 if=/dev/zero of=/dev
/md/md6to conv=fdatasync
md127 : active raid1 sdf3[1] sde3[0]
243269440 blocks super 1.0 [2/2] [UU]
2024+0 records in
2024+0 records out
2122317824 bytes (2.1 GB) copied, 13.8561 s, 153 MB/s
^ permalink raw reply
* Re: strange mirror write perf
From: Youenn Gestin @ 2017-03-20 0:44 UTC (permalink / raw)
To: Adam Goryachev; +Cc: linux-raid
In-Reply-To: <3a5e061d-696d-f331-87a5-411edc514ada@websitemanagers.com.au>
Le 2017-03-20 00:42, Adam Goryachev a écrit :
> On 20/03/17 02:14, Youenn Gestin wrote:
>> Hello,
>>
>> I'm encountering a drop of write performance after creating a mirror
>> with two whole disk ( sdc and sdd ) and i'm not able to find where it
>> come from:
>>
>> Perf before :
>> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdd conv=fdatasync
>> 2024+0 records in
>> 2024+0 records out
>> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,1238 s, 150 MB/s
>> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdc conv=fdatasync
>> 2024+0 records in
>> 2024+0 records out
>> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,7046 s, 144 MB/s
>>
>> Creating the mirror :
>> abyss ~ # mdadm --create --verbose /dev/md/md6to --level=1
>> --raid-devices=2 /dev/sdc /dev/sdd
>> mdadm: Note: this array has metadata at the start and
>> may not be suitable as a boot device. If you plan to
>> store '/boot' on this device please ensure that
>> your boot-loader understands md/v1.x metadata, or use
>> --metadata=0.90
>> mdadm: size set to 5860391488K
>> mdadm: automatically enabling write-intent bitmap on large array
>> Continue creating array? y
>> mdadm: Defaulting to version 1.2 metadata
>> mdadm: array /dev/md/md6to started.
>>
>> Perf after :
>> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to
>> conv=fdatasync
>> 2024+0 records in
>> 2024+0 records out
>> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 21,1528 s, 100 MB/s
>
> Two possible thoughts:
> 1) Did you wait until the two drives had completed the initial sync
> before testing? "cat /proc/mdstat" will show this.
> 2) As noted, "mdadm: automatically enabling write-intent bitmap on
> large array" try to disable this to see if you get the results you
> were expecting.
>
> Other than that, I'm not sure, but please reply, and if it isn't so
> simple, then someone else might jump in.
>
> Regards,
> Adam
Hello,
You got it right on your 2nd tought !
Took a look at
https://raid.wiki.kernel.org/index.php/Write-intent_bitmap , disabled it
( mdadm --grow --bitmap=none /dev/md/md6to ) ang here we go :
abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to
conv=fdatasync
2024+0 records in
2024+0 records out
2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,5074 s, 146 MB/s
I'll check about this function to see if i'll need it or not tomorow,
Thank you !
^ permalink raw reply
* Re: strange mirror write perf
From: Adam Goryachev @ 2017-03-19 23:42 UTC (permalink / raw)
To: Youenn Gestin, linux-raid
In-Reply-To: <c0981a7c8b13facace1228ed0f99efdc@grim-is-a-geek.fr>
On 20/03/17 02:14, Youenn Gestin wrote:
> Hello,
>
> I'm encountering a drop of write performance after creating a mirror
> with two whole disk ( sdc and sdd ) and i'm not able to find where it
> come from:
>
> Perf before :
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdd conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,1238 s, 150 MB/s
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdc conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,7046 s, 144 MB/s
>
> Creating the mirror :
> abyss ~ # mdadm --create --verbose /dev/md/md6to --level=1
> --raid-devices=2 /dev/sdc /dev/sdd
> mdadm: Note: this array has metadata at the start and
> may not be suitable as a boot device. If you plan to
> store '/boot' on this device please ensure that
> your boot-loader understands md/v1.x metadata, or use
> --metadata=0.90
> mdadm: size set to 5860391488K
> mdadm: automatically enabling write-intent bitmap on large array
> Continue creating array? y
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md/md6to started.
>
> Perf after :
> abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to
> conv=fdatasync
> 2024+0 records in
> 2024+0 records out
> 2122317824 bytes (2,1 GB, 2,0 GiB) copied, 21,1528 s, 100 MB/s
Two possible thoughts:
1) Did you wait until the two drives had completed the initial sync
before testing? "cat /proc/mdstat" will show this.
2) As noted, "mdadm: automatically enabling write-intent bitmap on large
array" try to disable this to see if you get the results you were expecting.
Other than that, I'm not sure, but please reply, and if it isn't so
simple, then someone else might jump in.
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* stripe_cache_size, some info
From: Gandalf Corvotempesta @ 2017-03-19 18:35 UTC (permalink / raw)
To: linux-raid
Hi to all,
I need some info about stripe_cache_size
Is that a sort of "writeback" cache? Higher the number, higher the
amount of data to be cached in ram before writing to disks, right?
Some questions:
1) any upper limit for that value ? Can I set it near 1GB like most
hardware controller?
2) why on my RAID-6 I don't have /sys/block/md0/md/stripe_cache_size ?
As I would like to replace most of our HW raid controller with mdadm,
any suggestion on how to improve RAID-6 speed ?
Modern CPU aren't an issue, I don't think that double-parity
calculation could create any bottleneck on a modern CPU.
The real advantages of a raid controller are mostly 2:
1) the writeback cache (1GB or 2GB)
2) the ability to automatically replace a disk by hotswapping it.
Any solution to this ? For the "2", i've tried by configuring the
POLICY in mdadm.conf but new disk is never reconized and I always have
to manually add the new disk to the array.
^ permalink raw reply
* strange mirror write perf
From: Youenn Gestin @ 2017-03-19 15:14 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <6ec5f2dbefa2b7489d9f39d4833d5113@grim-is-a-geek.fr>
Hello,
I'm encountering a drop of write performance after creating a mirror
with two whole disk ( sdc and sdd ) and i'm not able to find where it
come from:
Perf before :
abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdd conv=fdatasync
2024+0 records in
2024+0 records out
2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,1238 s, 150 MB/s
abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/sdc conv=fdatasync
2024+0 records in
2024+0 records out
2122317824 bytes (2,1 GB, 2,0 GiB) copied, 14,7046 s, 144 MB/s
Creating the mirror :
abyss ~ # mdadm --create --verbose /dev/md/md6to --level=1
--raid-devices=2 /dev/sdc /dev/sdd
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: size set to 5860391488K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/md6to started.
Perf after :
abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/md/md6to
conv=fdatasync
2024+0 records in
2024+0 records out
2122317824 bytes (2,1 GB, 2,0 GiB) copied, 21,1528 s, 100 MB/s
I've also tried with a mirror created on two partition and the result
was the same.
I tried with a LVM mirror, the drop of performance was not so important
:
abyss ~ # vgcreate data_vg /dev/sdc
Physical volume "/dev/sdc" successfully created.
Volume group "data_vg" successfully created
abyss ~ # vgextend data_vg /dev/sdd
Physical volume "/dev/sdd" successfully created.
Volume group "data_vg" successfully extended
abyss ~ # vgs
VG #PV #LV #SN Attr VSize VFree
data_vg 2 0 0 wz--n- 10,92t 10,92t
abyss ~ # lvcreate -L 50G -m1 -n lv_mirror data_vg
Logical volume "lv_mirror" created.
abyss ~ # dd bs=1M count=2024 if=/dev/zero of=/dev/data_vg/lv_mirror
conv=fdatasync
2024+0 records in
2024+0 records out
2122317824 bytes (2,1 GB, 2,0 GiB) copied, 16,3757 s, 130 MB/s
I didn't notice anything wrong while launching the dd test and watching
top.
Here are the information from asked
https://raid.wiki.kernel.org/index.php/Asking_for_help
abyss lsdrv # smartctl --xall /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.10.2-gentoo] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD60EFRX-68L0BN1
Serial Number: WD-WX11D76EPFJV
LU WWN Device Id: 5 0014ee 2b88cbb3d
Firmware Version: 82.00A82
User Capacity: 6 001 175 126 016 bytes [6,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5700 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Fri Mar 17 14:41:32 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Unavailable
APM feature is: Unavailable
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection:
Disabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test
has ever
been run.
Total time to complete Offline
data collection: ( 8144) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection
on/off support.
Suspend Offline collection upon
new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging
supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 735) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303d) SCT Status supported.
SCT Error Recovery Control
supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-K 200 200 051 - 0
3 Spin_Up_Time POS--K 208 208 021 - 8558
4 Start_Stop_Count -O--CK 100 100 000 - 12
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
7 Seek_Error_Rate -OSR-K 200 200 000 - 0
9 Power_On_Hours -O--CK 100 100 000 - 274
10 Spin_Retry_Count -O--CK 100 253 000 - 0
11 Calibration_Retry_Count -O--CK 100 253 000 - 0
12 Power_Cycle_Count -O--CK 100 100 000 - 12
192 Power-Off_Retract_Count -O--CK 200 200 000 - 6
193 Load_Cycle_Count -O--CK 200 200 000 - 25
194 Temperature_Celsius -O---K 119 111 000 - 33
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
197 Current_Pending_Sector -O--CK 200 200 000 - 0
198 Offline_Uncorrectable ----CK 100 253 000 - 0
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0
200 Multi_Zone_Error_Rate ---R-- 100 253 000 - 0
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning
General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
Address Access R/W Size Description
0x00 GPL,SL R/O 1 Log Directory
0x01 SL R/O 1 Summary SMART error log
0x02 SL R/O 5 Comprehensive SMART error log
0x03 GPL R/O 6 Ext. Comprehensive SMART error log
0x06 SL R/O 1 SMART self-test log
0x07 GPL R/O 1 Extended self-test log
0x09 SL R/W 1 Selective self-test log
0x10 GPL R/O 1 SATA NCQ Queued Error log
0x11 GPL R/O 1 SATA Phy Event Counters log
0x21 GPL R/O 1 Write stream error log
0x22 GPL R/O 1 Read stream error log
0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log
0x80-0x9f GPL,SL R/W 16 Host vendor specific log
0xa0-0xa7 GPL,SL VS 16 Device vendor specific log
0xa8-0xb6 GPL,SL VS 1 Device vendor specific log
0xb7 GPL,SL VS 54 Device vendor specific log
0xbd GPL,SL VS 1 Device vendor specific log
0xc0 GPL,SL VS 1 Device vendor specific log
0xc1 GPL VS 93 Device vendor specific log
0xe0 GPL,SL R/W 1 SCT Command/Status
0xe1 GPL,SL R/W 1 SCT Data Transfer
SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
No Errors Logged
SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute
delay.
SCT Status Version: 3
SCT Version (vendor specific): 258 (0x0102)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 33 Celsius
Power Cycle Min/Max Temperature: 32/41 Celsius
Lifetime Min/Max Temperature: 17/41 Celsius
Under/Over Temperature Limit Count: 0/0
Vendor specific:
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SCT Temperature History Version: 2
Temperature Sampling Period: 1 minute
Temperature Logging Interval: 1 minute
Min/Max recommended Temperature: 0/60 Celsius
Min/Max Temperature Limit: -41/85 Celsius
Temperature History Size (Index): 478 (193)
Index Estimated Time Temperature Celsius
194 2017-03-17 06:44 32 *************
... ..(464 skipped). .. *************
181 2017-03-17 14:29 32 *************
182 2017-03-17 14:30 33 **************
... ..( 10 skipped). .. **************
193 2017-03-17 14:41 33 **************
SCT Error Recovery Control:
Read: 70 (7,0 seconds)
Write: 70 (7,0 seconds)
Device Statistics (GP/SMART Log 0x04) not supported
SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x0001 2 0 Command failed due to ICRC error
0x0002 2 13 R_ERR response for data FIS
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 13 R_ERR response for host-to-device data FIS
0x0005 2 0 R_ERR response for non-data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
0x0008 2 0 Device-to-host non-data FIS retries
0x0009 2 15 Transition from drive PhyRdy to drive PhyNRdy
0x000a 2 30 Device-to-host register FISes sent due to a
COMRESET
0x000b 2 8 CRC errors within host-to-device FIS
0x000d 2 5 Non-CRC errors within host-to-device FIS
0x000f 2 8 R_ERR response for host-to-device data FIS, CRC
0x0012 2 0 R_ERR response for host-to-device non-data FIS,
CRC
0x8000 4 318448 Vendor specific
-------------------------------------------------------------------------------
abyss lsdrv # smartctl --xall /dev/sdd
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.10.2-gentoo] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke,
www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD60EFRX-68L0BN1
Serial Number: WD-WX41D964EZK9
LU WWN Device Id: 5 0014ee 263752a6e
Firmware Version: 82.00A82
User Capacity: 6 001 175 126 016 bytes [6,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5700 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Mar 17 14:41:57 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Unavailable
APM feature is: Unavailable
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection:
Disabled.
Self-test execution status: ( 0) The previous self-test routine
completed
without error or no self-test
has ever
been run.
Total time to complete Offline
data collection: ( 9344) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection
on/off support.
Suspend Offline collection upon
new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging
supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 746) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303d) SCT Status supported.
SCT Error Recovery Control
supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-K 200 200 051 - 0
3 Spin_Up_Time POS--K 100 253 021 - 0
4 Start_Stop_Count -O--CK 100 100 000 - 5
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
7 Seek_Error_Rate -OSR-K 100 253 000 - 0
9 Power_On_Hours -O--CK 100 100 000 - 246
10 Spin_Retry_Count -O--CK 100 253 000 - 0
11 Calibration_Retry_Count -O--CK 100 253 000 - 0
12 Power_Cycle_Count -O--CK 100 100 000 - 5
192 Power-Off_Retract_Count -O--CK 200 200 000 - 1
193 Load_Cycle_Count -O--CK 200 200 000 - 19
194 Temperature_Celsius -O---K 121 116 000 - 31
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
197 Current_Pending_Sector -O--CK 200 200 000 - 0
198 Offline_Uncorrectable ----CK 100 253 000 - 0
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0
200 Multi_Zone_Error_Rate ---R-- 100 253 000 - 0
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning
General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
Address Access R/W Size Description
0x00 GPL,SL R/O 1 Log Directory
0x01 SL R/O 1 Summary SMART error log
0x02 SL R/O 5 Comprehensive SMART error log
0x03 GPL R/O 6 Ext. Comprehensive SMART error log
0x04 GPL,SL R/O 8 Device Statistics log
0x06 SL R/O 1 SMART self-test log
0x07 GPL R/O 1 Extended self-test log
0x09 SL R/W 1 Selective self-test log
0x0c GPL R/O 2048 Pending Defects log
0x10 GPL R/O 1 SATA NCQ Queued Error log
0x11 GPL R/O 1 SATA Phy Event Counters log
0x21 GPL R/O 1 Write stream error log
0x22 GPL R/O 1 Read stream error log
0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log
0x80-0x9f GPL,SL R/W 16 Host vendor specific log
0xa0-0xa7 GPL,SL VS 16 Device vendor specific log
0xa8-0xb6 GPL,SL VS 1 Device vendor specific log
0xb7 GPL,SL VS 54 Device vendor specific log
0xbd GPL,SL VS 1 Device vendor specific log
0xc0 GPL,SL VS 1 Device vendor specific log
0xc1 GPL VS 93 Device vendor specific log
0xe0 GPL,SL R/W 1 SCT Command/Status
0xe1 GPL,SL R/W 1 SCT Data Transfer
SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
No Errors Logged
SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute
delay.
SCT Status Version: 3
SCT Version (vendor specific): 258 (0x0102)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 31 Celsius
Power Cycle Min/Max Temperature: 30/36 Celsius
Lifetime Min/Max Temperature: 16/36 Celsius
Under/Over Temperature Limit Count: 0/0
Vendor specific:
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SCT Temperature History Version: 2
Temperature Sampling Period: 1 minute
Temperature Logging Interval: 1 minute
Min/Max recommended Temperature: 0/60 Celsius
Min/Max Temperature Limit: -41/85 Celsius
Temperature History Size (Index): 478 (434)
Index Estimated Time Temperature Celsius
435 2017-03-17 06:44 30 ***********
... ..(463 skipped). .. ***********
421 2017-03-17 14:28 30 ***********
422 2017-03-17 14:29 31 ************
... ..( 11 skipped). .. ************
434 2017-03-17 14:41 31 ************
SCT Error Recovery Control:
Read: 70 (7,0 seconds)
Write: 70 (7,0 seconds)
Device Statistics (GP Log 0x04)
Page Offset Size Value Flags Description
0x01 ===== = = === == General Statistics (rev 2) ==
0x01 0x008 4 5 --- Lifetime Power-On Resets
0x01 0x010 4 246 --- Power-on Hours
0x01 0x018 6 23708519208 --- Logical Sectors Written
0x01 0x020 6 24687968 --- Number of Write Commands
0x01 0x028 6 11729201720 --- Logical Sectors Read
0x01 0x030 6 22155003 --- Number of Read Commands
0x03 ===== = = === == Rotating Media Statistics (rev
1) ==
0x03 0x008 4 246 --- Spindle Motor Power-on Hours
0x03 0x010 4 43 --- Head Flying Hours
0x03 0x018 4 21 --- Head Load Events
0x03 0x020 4 0 --- Number of Reallocated Logical
Sectors
0x03 0x028 4 0 --- Read Recovery Attempts
0x03 0x030 4 0 --- Number of Mechanical Start Failures
0x04 ===== = = === == General Errors Statistics (rev
1) ==
0x04 0x008 4 0 --- Number of Reported Uncorrectable
Errors
0x04 0x010 4 0 --- Resets Between Cmd Acceptance and
Completion
0x05 ===== = = === == Temperature Statistics (rev 1)
==
0x05 0x008 1 31 --- Current Temperature
0x05 0x010 1 30 --- Average Short Term Temperature
0x05 0x018 1 - --- Average Long Term Temperature
0x05 0x020 1 36 --- Highest Temperature
0x05 0x028 1 19 --- Lowest Temperature
0x05 0x030 1 33 --- Highest Average Short Term
Temperature
0x05 0x038 1 30 --- Lowest Average Short Term
Temperature
0x05 0x040 1 - --- Highest Average Long Term
Temperature
0x05 0x048 1 - --- Lowest Average Long Term
Temperature
0x05 0x050 4 0 --- Time in Over-Temperature
0x05 0x058 1 60 --- Specified Maximum Operating
Temperature
0x05 0x060 4 0 --- Time in Under-Temperature
0x05 0x068 1 0 --- Specified Minimum Operating
Temperature
0x06 ===== = = === == Transport Statistics (rev 1) ==
0x06 0x008 4 22 --- Number of Hardware Resets
0x06 0x010 4 3 --- Number of ASR Events
0x06 0x018 4 0 --- Number of Interface CRC Errors
|||_ C monitored condition met
||__ D supports DSN
|___ N normalized value
SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x0001 2 0 Command failed due to ICRC error
0x0002 2 0 R_ERR response for data FIS
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 0 R_ERR response for host-to-device data FIS
0x0005 2 0 R_ERR response for non-data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
0x0008 2 0 Device-to-host non-data FIS retries
0x0009 2 2 Transition from drive PhyRdy to drive PhyNRdy
0x000a 2 4 Device-to-host register FISes sent due to a
COMRESET
0x000b 2 0 CRC errors within host-to-device FIS
0x000d 2 0 Non-CRC errors within host-to-device FIS
0x000f 2 0 R_ERR response for host-to-device data FIS, CRC
0x0012 2 0 R_ERR response for host-to-device non-data FIS,
CRC
0x8000 4 318477 Vendor specific
abyss lsdrv # mdadm --examine /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 183ad93e:c604b817:7099c950:12d36bab
Name : abyss:md6to (local to host abyss)
Creation Time : Mon Mar 13 22:11:47 2017
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 11720783024 (5588.90 GiB 6001.04 GB)
Array Size : 5860391488 (5588.90 GiB 6001.04 GB)
Used Dev Size : 11720782976 (5588.90 GiB 6001.04 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=48 sectors
State : clean
Device UUID : b55a87f4:15d145d1:19979cc5:e1eafc32
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Mar 17 14:24:32 2017
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : b949b844 - correct
Events : 9925
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
-----------------------------------------------------------------------------
abyss lsdrv # mdadm --examine /dev/sdd
/dev/sdd:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 183ad93e:c604b817:7099c950:12d36bab
Name : abyss:md6to (local to host abyss)
Creation Time : Mon Mar 13 22:11:47 2017
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 11720783024 (5588.90 GiB 6001.04 GB)
Array Size : 5860391488 (5588.90 GiB 6001.04 GB)
Used Dev Size : 11720782976 (5588.90 GiB 6001.04 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=48 sectors
State : clean
Device UUID : ddbae969:eae9cb91:fb7fa642:1932781a
Internal Bitmap : 8 sectors from superblock
Update Time : Fri Mar 17 14:24:32 2017
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : 53b76159 - correct
Events : 9925
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
-----------------------------------------------------------------------------
abyss lsdrv # mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Mon Mar 13 22:11:47 2017
Raid Level : raid1
Array Size : 5860391488 (5588.90 GiB 6001.04 GB)
Used Dev Size : 5860391488 (5588.90 GiB 6001.04 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Fri Mar 17 14:24:32 2017
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : abyss:md6to (local to host abyss)
UUID : 183ad93e:c604b817:7099c950:12d36bab
Events : 9925
Number Major Minor RaidDevice State
0 8 48 0 active sync /dev/sdd
1 8 32 1 active sync /dev/sdc
-----------------------------------------------------------------------------
abyss lsdrv # python2.7 lsdrv
PCI [hptiop] 01:00.0 RAID bus controller: HighPoint Technologies, Inc.
Device 3520 (rev 09)
└scsi 0:0:0:0 HPT VD0-0 {}
└sda 8.19t [8:0] Partitioned (gpt)
└sda1 8.19t [8:1] ext4 {7262b140-e026-4b53-bc6b-2ac1c1cc4538}
└Mounted as /dev/sda1 @ /mnt
PCI [ahci] 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD]
FCH SATA Controller [AHCI mode] (rev 40)
├scsi 1:0:0:0 ATA OCZ-VERTEX4 {OCZ-9NYS802X56U11736}
│└sdb 238.47g [8:16] Partitioned (dos)
│ └sdb1 238.47g [8:17] ext4 {6de79b5d-dc44-4362-86af-b483fbbe1c65}
│ └Mounted as /dev/sdb1 @ /
├scsi 2:0:0:0 ATA WDC WD60EFRX-68L {WD-WX11D76EPFJV}
│└sdc 5.46t [8:32] MD raid1 (1/2) (w/ sdd) in_sync 'abyss:md6to'
{183ad93e-c604-b817-7099-c95012d36bab}
│ └md127 5.46t [9:127] MD v1.2 raid1 (2) clean
{183ad93e:c604b817:7099c950:12d36bab}
│ Empty/Unknown
├scsi 3:0:0:0 ATA WDC WD60EFRX-68L {WD-WX41D964EZK9}
│└sdd 5.46t [8:48] MD raid1 (0/2) (w/ sdc) in_sync 'abyss:md6to'
{183ad93e-c604-b817-7099-c95012d36bab}
│ └md127 5.46t [9:127] MD v1.2 raid1 (2) clean
{183ad93e:c604b817:7099c950:12d36bab}
│ Empty/Unknown
├scsi 4:x:x:x [Empty]
-----------------------------------------------------------------------------
abyss lsdrv # cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4]
md127 : active raid1 sdd[0] sdc[1]
5860391488 blocks super 1.2 [2/2] [UU]
bitmap: 0/44 pages [0KB], 65536KB chunk
unused devices: <none>
-----------------------------------------------------------------------------
abyss lsdrv # mdadm --version
mdadm - v4.0 - 2017-01-09
-----------------------------------------------------------------------------
abyss lsdrv # uname -a
Linux abyss 4.10.2-gentoo #2 SMP Mon Mar 13 21:46:37 CET 2017 x86_64
AMD A8-5600K APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
Thanks for your help.
Youenn.
^ permalink raw reply
* Fwd: component device mismatches found
From: Gandalf Corvotempesta @ 2017-03-19 10:42 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <CAJH6TXhYYuh3v8FDDUisCpTZqVJ3WHEb_W0Ky=jkQHm1Y-fR4w@mail.gmail.com>
/cc linux-raid
---------- Forwarded message ----------
From: Gandalf Corvotempesta <gandalf.corvotempesta@gmail.com>
Date: 2017-03-19 11:42 GMT+01:00
Subject: Re: component device mismatches found
To: Wols Lists <antlists@youngman.org.uk>
2017-03-19 11:21 GMT+01:00 Wols Lists <antlists@youngman.org.uk>:
> mdadm --detail /dev/md/0
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Jul 25 12:55:48 2016
Raid Level : raid1
Array Size : 488382841 (465.76 GiB 500.10 GB)
Used Dev Size : 488382841 (465.76 GiB 500.10 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Sun Mar 19 11:38:53 2017
State : clean, recovering
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Rebuild Status : 83% complete
Name : x:0 (local to host x)
UUID : b2a5ed53:42890b73:dc6de22a:1ac12524
Events : 29170
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
keep in mind that:
1) i've done a check this morning, after seeing the mismatch error in syslog
2) even this check has triggered a rebuild, probably due to the same mismatch.
3) SMART doesn't report any errors,
4) disks are "new", 5600 hours.
5) swap is still unused
^ permalink raw reply
* Re: component device mismatches found
From: Wols Lists @ 2017-03-19 10:21 UTC (permalink / raw)
To: Gandalf Corvotempesta, linux-raid
In-Reply-To: <CAJH6TXgA-5-PXmFdY7b1J8eYc3zbmb7ui8Fa8k+ihMKd7nQ8vw@mail.gmail.com>
On 19/03/17 10:00, Gandalf Corvotempesta wrote:
> I've seen this in my log:
>
> Mar 19 00:57:01 x /USR/SBIN/CRON[17832]: (root) CMD (if [ -x
> /usr/share/mdadm/checkarray ]; then /usr/share/mdadm/checkarray --cron
> --all --idle --quiet; fi)
> Mar 19 00:57:01 x mdadm[1576]: RebuildStarted event detected on md
> device /dev/md/0
> Mar 19 01:30:21 x mdadm[1576]: Rebuild24 event detected on md device /dev/md/0
> Mar 19 02:03:41 x mdadm[1576]: Rebuild47 event detected on md device /dev/md/0
> Mar 19 02:37:02 x mdadm[1576]: Rebuild68 event detected on md device /dev/md/0
> Mar 19 03:10:22 x mdadm[1576]: Rebuild87 event detected on md device /dev/md/0
> Mar 19 03:38:00 x mdadm[1576]: RebuildFinished event detected on md
> device /dev/md/0, component device mismatches found: 4608
>
> This is a 3way mirror.
>
> I've tought that swap was the culpit, but swap isn't used:
>
> # free -m
> total used free shared buffers cached
> Mem: 32230 31844 386 0 1679 26026
> -/+ buffers/cache: 4137 28092
> Swap: 8191 0 8191
>
> and IIRC, linux never clean the swap usage up to 0.
>
> Are my data safe ? Is something to be worried about ?
mdadm --detail /dev/md/0
I think we need a bit more info - it's not ringing any alarm bells for
me, but I'm not an expert.
Cheers,
Wol
^ permalink raw reply
* Re: Read data from disk that was part of RAID1 array
From: Wols Lists @ 2017-03-19 10:18 UTC (permalink / raw)
To: Peter Sangas, linux-raid
In-Reply-To: <000c01d29f74$ae85c230$0b914690$@wnsdev.com>
On 17/03/17 23:17, Peter Sangas wrote:
>
>
>> From: Peter Sangas [mailto:pete@wnsdev.com]
>> I have only one disk from a RAID1 array and I would like to read data from
> one of the
>> partitions. This there a way to mount this and read the data?
>
> This worked for me:
>
> mdadm --create /dev/md10 -l 1 -n 2 /dev/sda missing md10 is chosen to
> avoid conflicts with existing RAID1
>
> mount /dev/md10 /mnt
>
NEVER NEVER NEVER use --create !!!
YOU WERE LUCKY !!!
Use something like --assemble --force, which will set up a working array
if it can. If that had been an old array, with a different offset or
superblock or the like, you would have trashed the superblock and
created a new array, which thought that the data in the array was
somewhere other than where it really was.
At which point, it would have been "go to your backups" or a major
forensic recovery.
Cheers,
Wol
^ permalink raw reply
* component device mismatches found
From: Gandalf Corvotempesta @ 2017-03-19 10:00 UTC (permalink / raw)
To: linux-raid
I've seen this in my log:
Mar 19 00:57:01 x /USR/SBIN/CRON[17832]: (root) CMD (if [ -x
/usr/share/mdadm/checkarray ]; then /usr/share/mdadm/checkarray --cron
--all --idle --quiet; fi)
Mar 19 00:57:01 x mdadm[1576]: RebuildStarted event detected on md
device /dev/md/0
Mar 19 01:30:21 x mdadm[1576]: Rebuild24 event detected on md device /dev/md/0
Mar 19 02:03:41 x mdadm[1576]: Rebuild47 event detected on md device /dev/md/0
Mar 19 02:37:02 x mdadm[1576]: Rebuild68 event detected on md device /dev/md/0
Mar 19 03:10:22 x mdadm[1576]: Rebuild87 event detected on md device /dev/md/0
Mar 19 03:38:00 x mdadm[1576]: RebuildFinished event detected on md
device /dev/md/0, component device mismatches found: 4608
This is a 3way mirror.
I've tought that swap was the culpit, but swap isn't used:
# free -m
total used free shared buffers cached
Mem: 32230 31844 386 0 1679 26026
-/+ buffers/cache: 4137 28092
Swap: 8191 0 8191
and IIRC, linux never clean the swap usage up to 0.
Are my data safe ? Is something to be worried about ?
^ permalink raw reply
* Re: on assembly and recovery of a hardware RAID
From: Alfred Matthews @ 2017-03-18 18:08 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <CAAZLhTdn6xnB6Kuuhf8+VaSd5u6gekUSDSMnK+w5obZNxvNg8A@mail.gmail.com>
I've switched to the backup drives which are clones of the first, now,
so destructive operations are ok if necessary. Also signatures will
have changed.
0. Hm. Evidently the system is JHFS instead of HFS+, per the output
below. Unsure if there is separate tooling in Debian.
1. Mount via
mdadm --build /dev/md0 --level=0 -n2 --chunk=512K /dev/sdc2 /dev/sdb2
works just fine. Thanks!
2. I'm still sticking with the non-destructive, non-mount edits for
now. So I can report the following:
hpfsck -v /dev/md0 | cat >> hpfsck_output.txt
yields some stuff probably more enlightening than prior.
*** Checking Volume Header:
This HFS+ volume is not wrapped.
signature : +H
version : 4
attributes : 0X80002100
last_mount_vers : JSFH
reserved : 11178
create_date : Mon Oct 15 05:03:21 2012
modify_date : Sat Mar 4 15:53:51 2017
backup_date : Thu Dec 31 19:00:00 1903
checked_date : Sun Oct 14 22:03:21 2012
file_count : 961818
folder_count : 192894
blocksize : 2000
total_blocks : 732482664
free_blocks : 30231127
next_alloc : 517947667
rsrc_clump_sz : 65536
data_clump_sz : 65536
next_cnid : 1885617
write_count : 348970204
encodings_bmp : 0X200008B
Allocation file
total_size : 0X5752000
clump_size : 0X5752000
total_blocks : 0X2BA9
extents : (0X1+0X2BA9) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0)
Extension file
total_size : 0X1400000
clump_size : 0X1400000
total_blocks : 0XA00
extents : (0X10BAB+0XA00) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0)
Catalog file
total_size : 0X30800000
clump_size : 0X18400000
total_blocks : 0X18400
extents : (0X96BAB+0XC200) (0X15586D+0XC200) (0+0) (0+0)
(0+0) (0+0) (0+0) (0+0)
Attribute file
total_size : 0X18400000
clump_size : 0X18400000
total_blocks : 0XC200
extents : (0X115AB+0XC200) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0)
Start file
total_size : 0
clump_size : 0
total_blocks : 0
extents : (0+0) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0) (0+0)
Reserved attribute in use: 2000
Reserved attribute in use: 80000000
Volume was last Mounted by unknnown implemenatation:
JSFH
Invalid total blocks 2BA8CC68, expected 0 Done ***
*** Checking Backup Volume Header:
Unexpected Volume signature ' ' expected 'H+'
There is also the following on stderr
hpfsck: hpfsck: error writing to medium (Bad file descriptor)
Al.
On 18 March 2017 at 13:11, Alfred Matthews <asm13243546@gmail.com> wrote:
> Sorry for the delay. Thanks for the reply.
>
> You're correct, there is no hardware RAID in the available lsdrv; I've
> removed each drive from its housing in the controller because it's
> Thunderbolt-only, Thundderbolt is borked on OSX here, and I'm rescuing
> on Linux. I appreciate your diagnosis and will try, and will write
> back.
>
> On 14 March 2017 at 22:56, NeilBrown <neilb@suse.com> wrote:
>> On Tue, Mar 14 2017, Alfred Matthews wrote:
>>
>>>> Does
>>>> dmraid -b /dev/sda /dev/sdb /dev/sdc
>>>> tell you anything useful?
>>>>
>>>
>>> # dmraid -b /dev/sdb /dev/sdc
>>> /dev/sdc: 5860533168 total, "WD-WCAWZ2927144"
>>> /dev/sdb: 5860533168 total, "WD-WCAWZ2939730"
>>
>>
>> No, not useful.
>>
>> Your other output also doesn't show anything interesting.
>> I had another look at the lsdrv output you showed before and I'm
>> wondering if there really is anything "hardware RAID" here at all.
>>
>> Both drives (sdb and sdc) are partitioned into a 200MB EFI partition, a
>> 2.75TB hfsplus (Apple file system) / unknown partition, and a 128M
>> hfsplus boot partition.
>>
>> Maybe the two 2.75TB paritions were raided together.
>> sdc looks like the "first" device if this were the case.
>> Try:
>>
>> mdadm --build /dev/md0 --level=0 -n2 --chunk=512M /dev/sdc2 /dev/sdb2
>>
>> Then try fsck.hfs of hpfsck ... in the "hfsplus" package on Debian.
>> hpfsck /dev/md0
>> maybe.
>>
>> NeilBrown
>
>
>
> --
>
> Alfred S. Matthews
>
> Software, Visuals, Music
>
> Atlanta, Georgia, US
>
> +1.337.214.4688
--
Alfred S. Matthews
Software, Visuals, Music
Atlanta, Georgia, US
+1.337.214.4688
^ permalink raw reply
* Re: on assembly and recovery of a hardware RAID
From: Alfred Matthews @ 2017-03-18 17:11 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <87d1djdz8y.fsf@notabene.neil.brown.name>
Sorry for the delay. Thanks for the reply.
You're correct, there is no hardware RAID in the available lsdrv; I've
removed each drive from its housing in the controller because it's
Thunderbolt-only, Thundderbolt is borked on OSX here, and I'm rescuing
on Linux. I appreciate your diagnosis and will try, and will write
back.
On 14 March 2017 at 22:56, NeilBrown <neilb@suse.com> wrote:
> On Tue, Mar 14 2017, Alfred Matthews wrote:
>
>>> Does
>>> dmraid -b /dev/sda /dev/sdb /dev/sdc
>>> tell you anything useful?
>>>
>>
>> # dmraid -b /dev/sdb /dev/sdc
>> /dev/sdc: 5860533168 total, "WD-WCAWZ2927144"
>> /dev/sdb: 5860533168 total, "WD-WCAWZ2939730"
>
>
> No, not useful.
>
> Your other output also doesn't show anything interesting.
> I had another look at the lsdrv output you showed before and I'm
> wondering if there really is anything "hardware RAID" here at all.
>
> Both drives (sdb and sdc) are partitioned into a 200MB EFI partition, a
> 2.75TB hfsplus (Apple file system) / unknown partition, and a 128M
> hfsplus boot partition.
>
> Maybe the two 2.75TB paritions were raided together.
> sdc looks like the "first" device if this were the case.
> Try:
>
> mdadm --build /dev/md0 --level=0 -n2 --chunk=512M /dev/sdc2 /dev/sdb2
>
> Then try fsck.hfs of hpfsck ... in the "hfsplus" package on Debian.
> hpfsck /dev/md0
> maybe.
>
> NeilBrown
--
Alfred S. Matthews
Software, Visuals, Music
Atlanta, Georgia, US
+1.337.214.4688
^ permalink raw reply
* Re: dm crypt: remove an impossible condition
From: Dan Carpenter @ 2017-03-18 4:14 UTC (permalink / raw)
To: Mike Snitzer
Cc: kernel-janitors, linux-raid, dm-devel, Shaohua Li, Milan Broz,
Alasdair Kergon
In-Reply-To: <20170317213819.GC6475@redhat.com>
On Fri, Mar 17, 2017 at 05:38:19PM -0400, Mike Snitzer wrote:
> On Fri, Mar 17 2017 at 4:46pm -0400,
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> > Static checkers complain that it doesn't make sense to check if "sval"
> > is NULL. The intention was to check if strchr() returned NULL, but in
> > that situation "sval" would be "NULL + 1" so the check doesn't work. We
> > know from the sscanf() that there is a ':' character in the string so
> > the check is unnecessary and can be removed.
> >
> > Now that the check doesn't depend on "sval" it can be moved earlier
> > for readability.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Thanks Dan, I've folded this fix into the original commit, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.12&id=cf22cd5f3afe7335afee5659f7450000e8fa2a15
>
> I didn't add your Signed-off-by though, I can backfill that if you
> like.. it is just I didn't want to taint you with all the extensive
> changes in that commit.
That's fine, thanks. Sign-off isn't really the appropriate tag anyway...
regards,
dan carpenter
^ permalink raw reply
* [PATCH 2/2] mdadm: Forced type conversion to avoid truncation
From: Xiao Ni @ 2017-03-18 2:33 UTC (permalink / raw)
To: jes.sorensen; +Cc: ncroxon, artur.paszkiewicz, linux-raid
In-Reply-To: <1489804425-4949-1-git-send-email-xni@redhat.com>
Gcc reports it needs 19 bytes to right to disk->serial. Because the type of argument i
is int. But the meaning of i is failed disk number. So it doesn't need to use 19 bytes.
Just add a type conversion to avoid this building error
Signed-off-by: Xiao Ni <xni@redhat.com>
---
super-intel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/super-intel.c b/super-intel.c
index 343f20d..e1618f1 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -5228,7 +5228,7 @@ static int init_super_imsm_volume(struct supertype *st, mdu_array_info_t *info,
disk->status = CONFIGURED_DISK | FAILED_DISK;
disk->scsi_id = __cpu_to_le32(~(__u32)0);
snprintf((char *) disk->serial, MAX_RAID_SERIAL_LEN,
- "missing:%d", i);
+ "missing:%d", (__u8)i);
}
find_missing(super);
} else {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] Replace snprintf with strncpy at some places to avoid truncation
From: Xiao Ni @ 2017-03-18 2:33 UTC (permalink / raw)
To: jes.sorensen; +Cc: ncroxon, artur.paszkiewicz, linux-raid
In gcc7 there are some building errors like:
directive output may be truncated writing up to 31 bytes into a region of size 24
snprintf(str, MPB_SIG_LEN, %s, mpb->sig);
It just need to copy one string to target. So use strncpy to replace it.
For this line code: snprintf(str, MPB_SIG_LEN, %s, mpb->sig);
Because mpb->sig has the content of version after magic, so
it's better to use strncpy to replace snprintf too.
Signed-off-by: Xiao Ni <xni@redhat.com>
---
super-intel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index d5e9517..343f20d 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -1811,7 +1811,8 @@ static void examine_super_imsm(struct supertype *st, char *homehost)
__u32 reserved = imsm_reserved_sectors(super, super->disks);
struct dl *dl;
- snprintf(str, MPB_SIG_LEN, "%s", mpb->sig);
+ strncpy(str, (char *)mpb->sig, MPB_SIG_LEN);
+ str[MPB_SIG_LEN-1] = '\0';
printf(" Magic : %s\n", str);
snprintf(str, strlen(MPB_VERSION_RAID0), "%s", get_imsm_version(mpb));
printf(" Version : %s\n", get_imsm_version(mpb));
@@ -7142,14 +7143,16 @@ static int update_subarray_imsm(struct supertype *st, char *subarray,
u->type = update_rename_array;
u->dev_idx = vol;
- snprintf((char *) u->name, MAX_RAID_SERIAL_LEN, "%s", name);
+ strncpy((char *) u->name, name, MAX_RAID_SERIAL_LEN);
+ u->name[MAX_RAID_SERIAL_LEN-1] = '\0';
append_metadata_update(st, u, sizeof(*u));
} else {
struct imsm_dev *dev;
int i;
dev = get_imsm_dev(super, vol);
- snprintf((char *) dev->volume, MAX_RAID_SERIAL_LEN, "%s", name);
+ strncpy((char *) dev->volume, name, MAX_RAID_SERIAL_LEN);
+ dev->volume[MAX_RAID_SERIAL_LEN-1] = '\0';
for (i = 0; i < mpb->num_raid_devs; i++) {
dev = get_imsm_dev(super, i);
handle_missing(super, dev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] mdadm: Replace snprintf with strncpy at some places to avoid truncation
From: Xiao Ni @ 2017-03-18 1:02 UTC (permalink / raw)
To: jes sorensen; +Cc: linux-raid, ncroxon, artur paszkiewicz
In-Reply-To: <wrfjh92rk79c.fsf@gmail.com>
----- Original Message -----
> From: "jes sorensen" <jes.sorensen@gmail.com>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: linux-raid@vger.kernel.org, ncroxon@redhat.com, "artur paszkiewicz" <artur.paszkiewicz@intel.com>
> Sent: Saturday, March 18, 2017 3:55:43 AM
> Subject: Re: [PATCH 1/3] mdadm: Replace snprintf with strncpy at some places to avoid truncation
>
> Xiao Ni <xni@redhat.com> writes:
> > In gcc7 there are some building errors like:
> > directive output may be truncated writing up to 31 bytes into a region of
> > size 24
> > snprintf(str, MPB_SIG_LEN, %s, mpb->sig);
> >
> > It just need to copy one string to target. So use strncpy to replace it.
> >
> > Signed-off-by: Xiao Ni <xni@redhat.com>
> > ---
> > super-intel.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/super-intel.c b/super-intel.c
> > index d5e9517..e1618f1 100644
> > --- a/super-intel.c
> > +++ b/super-intel.c
> > @@ -1811,7 +1811,8 @@ static void examine_super_imsm(struct supertype *st,
> > char *homehost)
> > __u32 reserved = imsm_reserved_sectors(super, super->disks);
> > struct dl *dl;
> >
> > - snprintf(str, MPB_SIG_LEN, "%s", mpb->sig);
> > + strncpy(str, (char *)mpb->sig, MPB_SIG_LEN);
> > + str[MPB_SIG_LEN-1] = '\0';
> > printf(" Magic : %s\n", str);
> > snprintf(str, strlen(MPB_VERSION_RAID0), "%s", get_imsm_version(mpb));
> > printf(" Version : %s\n", get_imsm_version(mpb));
>
> Given str is defined as 'char str[MAX_SIGNATURE_LENGTH]', it would be
> more correct to use MAX_SIGNATURE_LENGTH as the size limit here.
I talked with Artur about this. It should use MPB_SIG_LEN, because the mpb->sig
has version after the signature. It will print more if use MAX_SIGNATURE_LENGTH.
>
> > @@ -5227,7 +5228,7 @@ static int init_super_imsm_volume(struct supertype
> > *st, mdu_array_info_t *info,
> > disk->status = CONFIGURED_DISK | FAILED_DISK;
> > disk->scsi_id = __cpu_to_le32(~(__u32)0);
> > snprintf((char *) disk->serial, MAX_RAID_SERIAL_LEN,
> > - "missing:%d", i);
> > + "missing:%d", (__u8)i);
> > }
> > find_missing(super);
> > } else {
>
> This is unrelated to the commit message.
I'll re-send this patch later.
Regards
Xiao
>
> > @@ -7142,14 +7143,16 @@ static int update_subarray_imsm(struct supertype
> > *st, char *subarray,
> >
> > u->type = update_rename_array;
> > u->dev_idx = vol;
> > - snprintf((char *) u->name, MAX_RAID_SERIAL_LEN, "%s", name);
> > + strncpy((char *) u->name, name, MAX_RAID_SERIAL_LEN);
> > + u->name[MAX_RAID_SERIAL_LEN-1] = '\0';
> > append_metadata_update(st, u, sizeof(*u));
> > } else {
> > struct imsm_dev *dev;
> > int i;
> >
> > dev = get_imsm_dev(super, vol);
> > - snprintf((char *) dev->volume, MAX_RAID_SERIAL_LEN, "%s", name);
> > + strncpy((char *) dev->volume, name, MAX_RAID_SERIAL_LEN);
> > + dev->volume[MAX_RAID_SERIAL_LEN-1] = '\0';
> > for (i = 0; i < mpb->num_raid_devs; i++) {
> > dev = get_imsm_dev(super, i);
> > handle_missing(super, dev);
>
> These two look fine.
>
> Jes
> --
> 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 6/7] md/raid10, LLVM: get rid of variable length array
From: Fengguang Wu @ 2017-03-18 0:41 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Borislav Petkov, Alexander Potapenko, Peter Zijlstra,
Michael Davidson, Michal Marek, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Herbert Xu, David S. Miller, Shaohua Li,
Matthias Kaehlcke, x86@kernel.org, open list:KERNEL BUILD + fi...,
LKML, linux-crypto, linux-raid, kbuild-all
In-Reply-To: <CACT4Y+bybdpqB71=inx8amwr188Mb2QyBeRTDdWZ3AFyDwVX0A@mail.gmail.com>
Hi Dmitry,
On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:
>On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov <bp@alien8.de> wrote:
>> On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:
>>> This problem is more general and is not specific to clang. It equally
>>> applies to different versions of gcc, different arches and different
>>> configs (namely, anything else than what a developer used for
>>> testing).
>>
>> I guess. We do carry a bunch of gcc workarounds along with the cc-*
>> macros in scripts/Kbuild.include.
>>
>>> A known, reasonably well working solution to this problem is
>>> a system of try bots that test patches before commit with different
>>> compilers/configs/archs. We already have such system in the form of
>>> 0-day bots. It would be useful to extend it with clang as soon as
>>> kernel builds.
>>
>> Has someone actually already talked to Fengguang about it?
>
>+Fengguang
I've actually tried clang long time ago. It quickly fails the build
for vanilla kernel. So it really depends on when the various clang
build fix patches can be accepted into mainline kernel.
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses
From: hpa @ 2017-03-17 23:50 UTC (permalink / raw)
To: Michael Davidson, Michal Marek, Thomas Gleixner, Ingo Molnar,
Herbert Xu, David S. Miller, Shaohua Li
Cc: Alexander Potapenko, Dmitry Vyukov, Matthias Kaehlcke, x86,
linux-kbuild, linux-kernel, linux-crypto, linux-raid
In-Reply-To: <20170317001520.85223-4-md@google.com>
On March 16, 2017 5:15:16 PM PDT, Michael Davidson <md@google.com> wrote:
>Suppress clang warnings about potential unaliged accesses
>to members in packed structs. This gets rid of almost 10,000
>warnings about accesses to the ring 0 stack pointer in the TSS.
>
>Signed-off-by: Michael Davidson <md@google.com>
>---
> arch/x86/Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
>
>diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>index 894a8d18bf97..7f21703c475d 100644
>--- a/arch/x86/Makefile
>+++ b/arch/x86/Makefile
>@@ -128,6 +128,11 @@ endif
> KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args)
> endif
>
>+ifeq ($(cc-name),clang)
>+# Suppress clang warnings about potential unaligned accesses.
>+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
>+endif
>+
> ifdef CONFIG_X86_X32
> x32_ld_ok := $(call try-run,\
> /bin/echo -e '1: .quad 1b' | \
Why conditional on clang?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH v3] mdadm/r5cache: allow adding journal to array without journal
From: Song Liu @ 2017-03-17 23:31 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
In-Reply-To: <20170317233111.2452831-1-songliubraving@fb.com>
Currently, --add-journal can be only used to recreate broken journal
for arrays with journal since creation. As the kernel code getting
more mature, this constraint is no longer necessary.
This patch allows --add-journal to add journal to array without
journal.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
Manage.c | 9 ---------
mdadm.8.in | 5 ++---
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/Manage.c b/Manage.c
index 5c3d2b9..d038b68 100644
--- a/Manage.c
+++ b/Manage.c
@@ -946,7 +946,6 @@ int Manage_add(int fd, int tfd, struct mddev_dev *dv,
/* only add journal to array that supports journaling */
if (dv->disposition == 'j') {
- struct mdinfo mdi;
struct mdinfo *mdp;
mdp = sysfs_read(fd, NULL, GET_ARRAY_STATE);
@@ -960,14 +959,6 @@ int Manage_add(int fd, int tfd, struct mddev_dev *dv,
pr_err("%s is not readonly, cannot add journal.\n", devname);
return -1;
}
-
- sysfs_free(mdp);
-
- tst->ss->getinfo_super(tst, &mdi, NULL);
- if (mdi.journal_device_required == 0) {
- pr_err("%s does not support journal device.\n", devname);
- return -1;
- }
disc.raid_disk = 0;
}
diff --git a/mdadm.8.in b/mdadm.8.in
index df1d460..9e5e896 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -1474,9 +1474,8 @@ the device is found or <slot>:missing in case the device is not found.
.TP
.BR \-\-add-journal
-Recreate journal for RAID-4/5/6 array that lost a journal device. In the
-current implementation, this command cannot add a journal to an array
-that had a failed journal. To avoid interrupting on-going write opertions,
+Add journal to an existing array, or recreate journal for RAID-4/5/6 array
+that lost a journal device. To avoid interrupting on-going write opertions,
.B \-\-add-journal
only works for array in Read-Only state.
--
2.9.3
^ permalink raw reply related
* [PATCH v3] mdadm: change in add-journal support
From: Song Liu @ 2017-03-17 23:31 UTC (permalink / raw)
To: linux-raid
Cc: shli, neilb, kernel-team, dan.j.williams, hch, jes.sorensen,
Song Liu
I have made some confusion with previous versions of the change set, so
I would like to resend and clarify.
The very first version of this set has two patches, one for changes
in --add-journal the other for new option of --remove-journal:
http://marc.info/?l=linux-raid&m=148960265129793
http://marc.info/?l=linux-raid&m=148960267329810
After getting feedback from Shaohua, I realized that there is issue
with the add-journal patch, and the remove-journal patch is not
necessary. Therefore, I sent the second version of this set:
http://marc.info/?l=linux-raid&m=148978754820615
However, I forgot to make it clear that the first set should be discarded,
which caused confusion.
To make it clear, please discard all the patches above, and only apply the
following patch.
Thanks,
Song
Song Liu (1):
mdadm/r5cache: allow adding journal to array without journal
Manage.c | 9 ---------
mdadm.8.in | 5 ++---
2 files changed, 2 insertions(+), 12 deletions(-)
--
2.9.3
^ permalink raw reply
* RE: Read data from disk that was part of RAID1 array
From: Peter Sangas @ 2017-03-17 23:17 UTC (permalink / raw)
To: linux-raid, pete
In-Reply-To: <008801d29ea3$3e858000$bb908000$@warren-selbert.com>
> From: Peter Sangas [mailto:pete@wnsdev.com]
> I have only one disk from a RAID1 array and I would like to read data from
one of the
> partitions. This there a way to mount this and read the data?
This worked for me:
mdadm --create /dev/md10 -l 1 -n 2 /dev/sda missing md10 is chosen to
avoid conflicts with existing RAID1
mount /dev/md10 /mnt
^ 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