* [mdadm PATCH 1/1] Fix some type comparison problems
From: Xiao Ni @ 2016-02-06 1:18 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen, deepa.kernel, maxin.john
As 26714713cd2bad9e0bf7f4669f6cc4659ceaab6c said, 32 bit signed
timestamps will overflow in the year 2038. It already changed the
utime and ctime in struct mdu_array_info_s from int to unsigned
int. So we need to change the values that compared with them to
unsigned int too.
Signed-off-by : Xiao Ni <xni@redhat.com>
---
Monitor.c | 2 +-
util.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Monitor.c b/Monitor.c
index f19c2e5..6df80f9 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -33,7 +33,7 @@
struct state {
char *devname;
char devnm[32]; /* to sync with mdstat info */
- long utime;
+ unsigned int utime;
int err;
char *spare_group;
int active, working, failed, spare, raid;
diff --git a/util.c b/util.c
index 970d484..6e7d3fb 100644
--- a/util.c
+++ b/util.c
@@ -1267,7 +1267,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
*/
struct superswitch *ss;
struct supertype *st;
- time_t besttime = 0;
+ unsigned int besttime = 0;
int bestsuper = -1;
int i;
--
2.4.3
^ permalink raw reply related
* Re: [PATCH 3/3][mdadm] Monitor.c: fix compiler error with x32 toolchain
From: Xiao Ni @ 2016-02-06 1:17 UTC (permalink / raw)
To: Maxin B. John; +Cc: linux-raid, Maxin B. John
In-Reply-To: <1454711298-32524-3-git-send-email-maxin.john@gmail.com>
----- Original Message -----
> From: "Maxin B. John" <maxin.john@gmail.com>
> To: linux-raid@vger.kernel.org
> Cc: "Maxin B. John" <maxin.john@intel.com>
> Sent: Saturday, February 6, 2016 6:28:18 AM
> Subject: [PATCH 3/3][mdadm] Monitor.c: fix compiler error with x32 toolchain
>
> From: "Maxin B. John" <maxin.john@intel.com>
>
> With x32 toolchain, this code caused the below listed error:
>
> | Monitor.c: In function 'check_array':
> | Monitor.c:545:16: error: comparison between signed and unsigned
> integer expressions [-Werror=sign-compare]
> | if (st->utime == array.utime &&
>
> Signed-off-by: Maxin B. John <maxin.john@intel.com>
> ---
> Monitor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Monitor.c b/Monitor.c
> index f19c2e5..748d61b 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -542,7 +542,7 @@ static int check_array(struct state *st, struct
> mdstat_ent *mdstat,
> alert("NewArray", st->devname, NULL, ainfo);
> }
>
> - if (st->utime == array.utime &&
> + if ((unsigned long)st->utime == array.utime &&
> st->failed == array.failed_disks &&
> st->working == array.working_disks &&
> st->spare == array.spare_disks &&
Hi Maxin
I sent the patch some days ago and I think it's not what Jes wanted. You can
see the mails in the list. I'll send the patch again.
Best Regards
Xiao
^ permalink raw reply
* [PATCH 3/3][mdadm] Monitor.c: fix compiler error with x32 toolchain
From: Maxin B. John @ 2016-02-05 22:28 UTC (permalink / raw)
To: linux-raid; +Cc: Maxin B. John
In-Reply-To: <1454711298-32524-1-git-send-email-maxin.john@gmail.com>
From: "Maxin B. John" <maxin.john@intel.com>
With x32 toolchain, this code caused the below listed error:
| Monitor.c: In function 'check_array':
| Monitor.c:545:16: error: comparison between signed and unsigned
integer expressions [-Werror=sign-compare]
| if (st->utime == array.utime &&
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
Monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Monitor.c b/Monitor.c
index f19c2e5..748d61b 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
alert("NewArray", st->devname, NULL, ainfo);
}
- if (st->utime == array.utime &&
+ if ((unsigned long)st->utime == array.utime &&
st->failed == array.failed_disks &&
st->working == array.working_disks &&
st->spare == array.spare_disks &&
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3][mdadm] mdadm.h: bswap is already defined in uclibc
From: Maxin B. John @ 2016-02-05 22:28 UTC (permalink / raw)
To: linux-raid; +Cc: Maxin B. John
In-Reply-To: <1454711298-32524-1-git-send-email-maxin.john@gmail.com>
From: "Maxin B. John" <maxin.john@intel.com>
Fixes this build error:
| In file included from mdadm.c:28:0:
| mdadm.h:142:0: error: "bswap_16" redefined [-Werror]
| #define bswap_16(x) (((x) & 0x00ffU) << 8 | \
| ^
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
mdadm.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mdadm.h b/mdadm.h
index dd02be7..230e60f 100755
--- a/mdadm.h
+++ b/mdadm.h
@@ -139,12 +139,20 @@ struct dlm_lksb {
* and there is no standard conversion function so... */
/* And dietlibc doesn't think byteswap is ok, so.. */
/* #include <byteswap.h> */
+
+#ifndef bswap_16
#define bswap_16(x) (((x) & 0x00ffU) << 8 | \
((x) & 0xff00U) >> 8)
+#endif
+
+#ifndef bswap_32
#define bswap_32(x) (((x) & 0x000000ffU) << 24 | \
((x) & 0xff000000U) >> 24 | \
((x) & 0x0000ff00U) << 8 | \
((x) & 0x00ff0000U) >> 8)
+#endif
+
+#ifndef bswap_64
#define bswap_64(x) (((x) & 0x00000000000000ffULL) << 56 | \
((x) & 0xff00000000000000ULL) >> 56 | \
((x) & 0x000000000000ff00ULL) << 40 | \
@@ -153,6 +161,7 @@ struct dlm_lksb {
((x) & 0x0000ff0000000000ULL) >> 24 | \
((x) & 0x00000000ff000000ULL) << 8 | \
((x) & 0x000000ff00000000ULL) >> 8)
+#endif
#if !defined(__KLIBC__)
#if BYTE_ORDER == LITTLE_ENDIAN
--
2.1.4
^ permalink raw reply related
* [PATCH 1/3][mdadm] util.c: include poll.h instead of sys/poll.h
From: Maxin B. John @ 2016-02-05 22:28 UTC (permalink / raw)
To: linux-raid; +Cc: Maxin B. John
From: "Maxin B. John" <maxin.john@intel.com>
This fixes a compile warning when building with musl:
In file included from util.c:27:0:
|
qemux86-64/usr/include/sys/poll.h:1:2:
error: #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
[-Werror=cpp]
| #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^
Signed-off-by: Maxin B. John <maxin.john@intel.com>
---
util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util.c b/util.c
index 970d484..3e6d293 100644
--- a/util.c
+++ b/util.c
@@ -24,7 +24,6 @@
#include "mdadm.h"
#include "md_p.h"
-#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/utsname.h>
#include <sys/wait.h>
@@ -32,6 +31,7 @@
#include <sys/resource.h>
#include <sys/vfs.h>
#include <linux/magic.h>
+#include <poll.h>
#include <ctype.h>
#include <dirent.h>
#include <signal.h>
--
2.1.4
^ permalink raw reply related
* Re: [SOLVED] Re: Raid 1 needs repair
From: Phil Turmel @ 2016-02-05 16:54 UTC (permalink / raw)
To: Stefan Lamby, linux-raid@vger.kernel.org
In-Reply-To: <1543635690.543147.1454691080103.JavaMail.open-xchange@app03.ox.hosteurope.de>
On 02/05/2016 11:51 AM, Stefan Lamby wrote:
> Hi.
> I have it up and synced again.
> A simple mdadm --manage /dev/md0 --add /dev/sda1 did it, without
> anything else. No --fail no --remove no --zero-metadata needed.
> After that I "grub-install /dev/sda" and now grub is installed at both
> array members.
>
> Thank you for your support.
Yes, that would have been my suggestion if I had caught up on my
e-mails. I'm in the middle of a kernel bisection :-(
Phil
^ permalink raw reply
* mdadm raid5 dropped 2 disks
From: André Teichert @ 2016-02-05 10:30 UTC (permalink / raw)
To: linux-raid
Hi,
I had a raid5 (mdadm V. 3.2.5) with 3 disks. Within an hour 2 disks dropped.
Both disks show smart error 184, but I can still read them.
First I did a full dd-copy of each disk to imagefile image[123] and
wrote it back to a large 4tb disk with 3 partitions.
mdadm -E /dev/sda1
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 8bf0a3b8:a98e95fd:6a0884e6:fbe6ab09
Name : server:0 (local to host server)
Creation Time : Sun Nov 24 04:21:09 2013
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1953262961 (931.39 GiB 1000.07 GB)
Array Size : 1953262592 (1862.78 GiB 2000.14 GB)
Used Dev Size : 1953262592 (931.39 GiB 1000.07 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : 6f793025:415d8c8b:e7d37bbb:19524380
Update Time : Wed Feb 3 10:16:27 2016
Checksum : 74a4a730 - correct
Events : 311
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : .AA ('A' == active, '.' == missing)
mdadm -E /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 8bf0a3b8:a98e95fd:6a0884e6:fbe6ab09
Name : server:0 (local to host server)
Creation Time : Sun Nov 24 04:21:09 2013
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1953262961 (931.39 GiB 1000.07 GB)
Array Size : 1953262592 (1862.78 GiB 2000.14 GB)
Used Dev Size : 1953262592 (931.39 GiB 1000.07 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : fc963d80:307b6345:c95b6d94:162c7c7c
Update Time : Wed Feb 3 10:16:40 2016
Checksum : 5eaf449a - correct
Events : 314
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : .A. ('A' == active, '.' == missing)
mdadm -E /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 8bf0a3b8:a98e95fd:6a0884e6:fbe6ab09
Name : server:0 (local to host server)
Creation Time : Sun Nov 24 04:21:09 2013
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 1953262961 (931.39 GiB 1000.07 GB)
Array Size : 1953262592 (1862.78 GiB 2000.14 GB)
Used Dev Size : 1953262592 (931.39 GiB 1000.07 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : active
Device UUID : 73b1275f:8600a6b4:51234150:e035eef3
Update Time : Wed Feb 3 09:37:09 2016
Checksum : e024ac15 - correct
Events : 217
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAA ('A' == active, '.' == missing)
Seems like sda3 dropped first and big difference in events so I started
only sda1+sda2
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sda2
Seemed to work and assembled the raid with 2/3 disks clean.
The filesystem is ext4.
Runnung "fsck -y /dev/md0" with lots of errors.
mount -t ext4 /dev/md0 /mnt didnt recognize the filesystem
Should I try --create --assmume-clean sda1 sda2 missing?
I try to stay calm and pray for help.
thx a lot
^ permalink raw reply
* Re: Raid 1 needs repair
From: Stefan Lamby @ 2016-02-05 10:02 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <56B3C311.5060407@turmel.org>
> Please show lsdrv results after you add the proper utilities to the
> environment you run lsdrv from. At least install lvm utilities and
> mdadm utilities.
This is the current output from the running system. sda is not the same any
more, it has been changed to a new disk.
Hope it makes sense.
lsdrv
PCI [ata_generic] 00:16.2 IDE interface: Intel Corporation 8 Series/C220 Series
Chipset Family IDE-r Controller (rev 04)
├scsi 0:x:x:x [Empty]
└scsi 1:x:x:x [Empty]
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series
Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
├scsi 2:0:0:0 ATA WDC WD1003FZEX-0 {WD-WCC3F4PNVSLF}
│└sda 931.51g [8:0] Partitioned (dos)
│ └sda1 931.51g [8:1] Empty/Unknown
├scsi 3:0:0:0 ATA WDC WD10EARS-00Y {WD-WCAV5D907687}
│└sdb 931.51g [8:16] Partitioned (dos)
│ └sdb1 931.51g [8:17] MD raid1 (1/2) in_sync 'speernix15:0'
{68c0c9ad-82ed-e879-2110-f4279f31c140}
│ └md0 931.39g [9:0] MD v1.2 raid1 (2) active DEGRADED
{68c0c9ad:82ede879:2110f427:9f31c140}
│ │ PV LVM2_member 288,70g used, 642,68g free
{hHvrtB-7XOz-L6j6-AnXd-Q3Wh-uHqw-bQ3RQS}
│ └VG vg_raid1 931,38g 642,68g free {mopUew-B2i4-9fmo-mlXP-Z8C3-nPYO-XM56AY}
│ ├dm-2 186.26g [252:2] LV home ext4 {8ee8d203-f306-4846-93fe-225b018f2965}
│ │└Mounted as /dev/mapper/vg_raid1-home @ /home
│ ├dm-0 93.13g [252:0] LV root ext4 {9f9568cf-d48a-4690-97a8-14576d724daf}
│ │└Mounted as /dev/mapper/vg_raid1-root @ /
│ └dm-1 9.31g [252:1] LV swap swap {9fbbac0f-0d49-47b0-a50b-d293f19f23ef}
├scsi 4:x:x:x [Empty]
├scsi 5:0:0:0 ATA SAMSUNG HD103UJ {S13PJ9BQ900571}
│└sdc 931.51g [8:32] Partitioned (dos)
│ └sdc1 931.51g [8:33] MD raid1 (0/2) (w/ sdd1) in_sync 'speernix15:1'
{a9a43761-8148-b29e-5db4-9d7ac4d0a219}
│ └md1 931.39g [9:1] MD v1.2 raid1 (2) clean
{a9a43761:8148b29e:5db49d7a:c4d0a219}
│ │ PV LVM2_member 500,00g used, 431,38g free
{JIUAPd-MMX8-k2UK-1NDY-h2Od-iBHk-a1QvgX}
│ └VG vg_backup_raid1 931,38g 431,38g free
{esKsCr-quUI-ckjF-Q6jc-wYYZ-eKL4-MRas87}
│ └dm-3 500.00g [252:3] LV lv_backup ext4
{e3600494-308f-4874-9083-ecd31a66e68a}
│ └Mounted as /dev/mapper/vg_backup_raid1-lv_backup @ /backup
├scsi 6:0:0:0 ATA SAMSUNG HD103UJ {S13PJ9BQA17616}
│└sdd 931.51g [8:48] Partitioned (dos)
│ └sdd1 931.51g [8:49] MD raid1 (1/2) (w/ sdc1) in_sync 'speernix15:1'
{a9a43761-8148-b29e-5db4-9d7ac4d0a219}
│ └md1 931.39g [9:1] MD v1.2 raid1 (2) clean
{a9a43761:8148b29e:5db49d7a:c4d0a219}
│ PV LVM2_member 500,00g used, 431,38g free
{JIUAPd-MMX8-k2UK-1NDY-h2Od-iBHk-a1QvgX}
└scsi 7:x:x:x [Empty]
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4]
[raid10]
md1 : active raid1 sdd1[1] sdc1[0]
976630336 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[1]
976629568 blocks super 1.2 [2/1] [_U]
unused devices: <none>
pvs
PV VG Fmt Attr PSize PFree
/dev/md0 vg_raid1 lvm2 a-- 931,38g 642,68g
/dev/md1 vg_backup_raid1 lvm2 a-- 931,38g 431,38g
lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy%
Convert
lv_backup vg_backup_raid1 -wi-ao--- 500,00g
home vg_raid1 -wi-ao--- 186,26g
root vg_raid1 -wi-ao--- 93,13g
swap vg_raid1 -wi-ao--- 9,31g
--
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 1 needs repair
From: Phil Turmel @ 2016-02-04 21:30 UTC (permalink / raw)
To: Stefan Lamby, linux-raid@vger.kernel.org
In-Reply-To: <43098506.459602.1454607669214.JavaMail.open-xchange@app01.ox.hosteurope.de>
On 02/04/2016 12:41 PM, Stefan Lamby wrote:
>
>> You may also need "mdadm --zero-superblock /dev/sda1" before the add
>> command.
>>
>> But if it's currently active in the array, why do you need to fail it?
>
> So this is the right way?
>
> mdadm --manage /dev/md0 --remove /dev/sda1 # remove failed disk from array
> mdadm --zero-superblock /dev/sda1
> mdadm --manage /dev/md0 --add /dev/sda1 # add new disk to array (assumed same or
> greater space for partition)
Your mdstat and your lsdrv output disagree on the status of /dev/sdb1.
If mdstat is current, what belongs to what? Your --examine results
suggest sda1 and sdb1 go together, but mdstat shows sdc1 running with
sdb1 in another array and sda1 all alone. If sda1 is all alone in an
array you can't remove it.
Your device names are probably changing between boots (not unusual) and
it is confusing your report.
Please show lsdrv results after you add the proper utilities to the
environment you run lsdrv from. At least install lvm utilities and
mdadm utilities.
Phil
^ permalink raw reply
* Re: Raid 1 needs repair
From: Stefan Lamby @ 2016-02-04 17:41 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <56B38012.5020404@turmel.org>
> You may also need "mdadm --zero-superblock /dev/sda1" before the add
> command.
>
> But if it's currently active in the array, why do you need to fail it?
So this is the right way?
mdadm --manage /dev/md0 --remove /dev/sda1 # remove failed disk from array
mdadm --zero-superblock /dev/sda1
mdadm --manage /dev/md0 --add /dev/sda1 # add new disk to array (assumed same or
greater space for partition)
^ permalink raw reply
* Re: Raid 1 needs repair
From: Phil Turmel @ 2016-02-04 16:45 UTC (permalink / raw)
To: Stefan Lamby, linux-raid@vger.kernel.org
In-Reply-To: <1161942166.457494.1454601803851.JavaMail.open-xchange@app01.ox.hosteurope.de>
On 02/04/2016 11:03 AM, Stefan Lamby wrote:
> Good morning Phil.
> I was hoping you are around - thanks for answering.
> The distro is a ubuntu lts server version 14.04.
>
> I was able to chroot und grub-install /dev/sdb.
> The system is booting again. The md0-Array needs to be fixed now.
>
> My docu for doing so is
> mdadm --manage /dev/md0 --fail /dev/sda1 # mark as failed
> mdadm --manage /dev/md0 --remove /dev/sda1 # remove failed disk from array
> mdadm --manage /dev/md0 --add /dev/sda1 # add new disk to array (assumed
> same or greater space for partition)
>
> Can you confirm this?
You may also need "mdadm --zero-superblock /dev/sda1" before the add
command.
But if it's currently active in the array, why do you need to fail it?
Phil
^ permalink raw reply
* Re: Raid 1 needs repair
From: Stefan Lamby @ 2016-02-04 16:03 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <56B36577.2030902@turmel.org>
Good morning Phil.
I was hoping you are around - thanks for answering.
The distro is a ubuntu lts server version 14.04.
I was able to chroot und grub-install /dev/sdb.
The system is booting again. The md0-Array needs to be fixed now.
My docu for doing so is
mdadm --manage /dev/md0 --fail /dev/sda1 # mark as failed
mdadm --manage /dev/md0 --remove /dev/sda1 # remove failed disk from array
mdadm --manage /dev/md0 --add /dev/sda1 # add new disk to array (assumed
same or greater space for partition)
Can you confirm this?
Thanks for your help.
> Phil Turmel <philip@turmel.org> hat am 4. Februar 2016 um 15:51 geschrieben:
>
>
> Good morning Stefan,
>
> On 02/04/2016 09:21 AM, Stefan Lamby wrote:
> > Hi.
> > My md0 is broken because of a damaged sda.
> > It was simple to find out which on it is thanks to lsdrv by Mr Turmel.
>
> You're welcome. Side note: It looks like lsdrv couldn't find the pvs
> and lvs utilities to fully document your LVM setup. I'd be interested
> in knowing which distro and version that environment was.
>
> > Now I have a new disk, same size, as sda with sda1 partition - same size -
> > formatted as Linux raid autodetect.
> > In the end I like to end up with the new sda1 as member of md0 and I need to
> > put
> > my boot information there, since sdb1, also member of md0, seems to no have
> > no
> > such info because the system wasn't booting with a missing sda1.
>
> >From what I can see from your report, you probably only need to do
> grub-install /dev/sda and grub-install /dev/sdb
>
> The boot partition is mirrored for the bulk of grub's data, which means
> normal upgrades and config changes "just work", but a new drive needs a
> bootloader. That is outside the array in the space before the first
> partition.
>
> > I am afraid of loosing data, so I prefer asking, what to do next.
> > Please guide, I have the system up and running on a sysrescd live distro.
>
> I presume that means you booted a rescue CD and then used chroot to get
> a command prompt in your installed system. If not, grub-install
> probably won't work. Note that some distros use grub2-install.
>
> If the above doesn't work, let us know what it says.
>
> Phil
>
>
^ permalink raw reply
* Re: Raid 1 needs repair
From: Phil Turmel @ 2016-02-04 14:51 UTC (permalink / raw)
To: Stefan Lamby, linux-raid@vger.kernel.org
In-Reply-To: <285536573.454192.1454595669809.JavaMail.open-xchange@app01.ox.hosteurope.de>
Good morning Stefan,
On 02/04/2016 09:21 AM, Stefan Lamby wrote:
> Hi.
> My md0 is broken because of a damaged sda.
> It was simple to find out which on it is thanks to lsdrv by Mr Turmel.
You're welcome. Side note: It looks like lsdrv couldn't find the pvs
and lvs utilities to fully document your LVM setup. I'd be interested
in knowing which distro and version that environment was.
> Now I have a new disk, same size, as sda with sda1 partition - same size -
> formatted as Linux raid autodetect.
> In the end I like to end up with the new sda1 as member of md0 and I need to put
> my boot information there, since sdb1, also member of md0, seems to no have no
> such info because the system wasn't booting with a missing sda1.
From what I can see from your report, you probably only need to do
grub-install /dev/sda and grub-install /dev/sdb
The boot partition is mirrored for the bulk of grub's data, which means
normal upgrades and config changes "just work", but a new drive needs a
bootloader. That is outside the array in the space before the first
partition.
> I am afraid of loosing data, so I prefer asking, what to do next.
> Please guide, I have the system up and running on a sysrescd live distro.
I presume that means you booted a rescue CD and then used chroot to get
a command prompt in your installed system. If not, grub-install
probably won't work. Note that some distros use grub2-install.
If the above doesn't work, let us know what it says.
Phil
^ permalink raw reply
* Raid 1 needs repair
From: Stefan Lamby @ 2016-02-04 14:21 UTC (permalink / raw)
To: linux-raid@vger.kernel.org
Hi.
My md0 is broken because of a damaged sda.
It was simple to find out which on it is thanks to lsdrv by Mr Turmel.
Now I have a new disk, same size, as sda with sda1 partition - same size -
formatted as Linux raid autodetect.
In the end I like to end up with the new sda1 as member of md0 and I need to put
my boot information there, since sdb1, also member of md0, seems to no have no
such info because the system wasn't booting with a missing sda1.
I am afraid of loosing data, so I prefer asking, what to do next.
Please guide, I have the system up and running on a sysrescd live distro.
Thank you very much.
-fuz
Here is some further information.
----------------- /sbin/lsdrv specific information
------------------------------------------
PCI [ahci] 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series
Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
├scsi 0:0:0:0 ATA WDC WD1001FALS-0 {WD-WMATV0444833}
│└sda 931.51g [8:0] Empty/Unknown
│ └sda1 931.51g [8:1] Empty/Unknown
│ └md0 931.39g [9:0] MD v1.2 raid1 (2) active {None}
│ │ Empty/Unknown
│ ├dm-1 93.13g [252:1] Empty/Unknown
│ │└Mounted as /dev/mapper/vg_raid1-root @ /
│ ├dm-2 9.31g [252:2] Empty/Unknown
│ └dm-3 186.26g [252:3] Empty/Unknown
│ └Mounted as /dev/mapper/vg_raid1-home @ /home
├scsi 1:0:0:0 ATA WDC WD10EARS-00Y {WD-WCAV5D907687}
│└sdb 931.51g [8:16] Empty/Unknown
│ └sdb1 931.51g [8:17] Empty/Unknown
│ └md0 931.39g [9:0] MD v1.2 raid1 (2) active {None}
│ Empty/Unknown
├scsi 2:x:x:x [Empty]
├scsi 3:0:0:0 ATA SAMSUNG HD103UJ {S13PJ9BQ900571}
│└sdc 931.51g [8:32] Empty/Unknown
│ └sdc1 931.51g [8:33] Empty/Unknown
│ └md1 931.39g [9:1] MD v1.2 raid1 (2) clean {None}
│ │ Empty/Unknown
│ └dm-0 500.00g [252:0] Empty/Unknown
│ └Mounted as /dev/mapper/vg_backup_raid1-lv_backup @ /backup
├scsi 4:0:0:0 ATA SAMSUNG HD103UJ {S13PJ9BQA17616}
│└sdd 931.51g [8:48] Empty/Unknown
│ └sdd1 931.51g [8:49] Empty/Unknown
│ └md1 931.39g [9:1] MD v1.2 raid1 (2) clean {None}
│ Empty/Unknown
└scsi 5:x:x:x [Empty]
Other Block Devices
├loop0 0.00k [7:0] Empty/Unknown
├loop1 0.00k [7:1] Empty/Unknown
├loop2 0.00k [7:2] Empty/Unknown
├loop3 0.00k [7:3] Empty/Unknown
├loop4 0.00k [7:4] Empty/Unknown
├loop5 0.00k [7:5] Empty/Unknown
├loop6 0.00k [7:6] Empty/Unknown
├loop7 0.00k [7:7] Empty/Unknown
├ram0 64.00m [1:0] Empty/Unknown
├ram1 64.00m [1:1] Empty/Unknown
├ram2 64.00m [1:2] Empty/Unknown
├ram3 64.00m [1:3] Empty/Unknown
├ram4 64.00m [1:4] Empty/Unknown
├ram5 64.00m [1:5] Empty/Unknown
├ram6 64.00m [1:6] Empty/Unknown
├ram7 64.00m [1:7] Empty/Unknown
├ram8 64.00m [1:8] Empty/Unknown
├ram9 64.00m [1:9] Empty/Unknown
├ram10 64.00m [1:10] Empty/Unknown
├ram11 64.00m [1:11] Empty/Unknown
├ram12 64.00m [1:12] Empty/Unknown
├ram13 64.00m [1:13] Empty/Unknown
├ram14 64.00m [1:14] Empty/Unknown
└ram15 64.00m [1:15] Empty/Unknown
----------------- RAID specific information (mdadm --examine /dev/sdXY)
---------------------
/dev/sda1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 68c0c9ad:82ede879:2110f427:9f31c140
Name : speernix15:0
Creation Time : Sun Nov 30 18:15:35 2014
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 1953259520 (931.39 GiB 1000.07 GB)
Array Size : 976629568 (931.39 GiB 1000.07 GB)
Used Dev Size : 1953259136 (931.39 GiB 1000.07 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=384 sectors
State : clean
Device UUID : 94a0a338:7876e6f4:f8eaa27c:05a34dfa
Update Time : Thu Feb 4 05:38:26 2016
Checksum : 7fe3fbef - correct
Events : 700
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : a9a43761:8148b29e:5db49d7a:c4d0a219
Name : speernix15:1
Creation Time : Sun Dec 21 10:18:05 2014
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 1953260976 (931.39 GiB 1000.07 GB)
Array Size : 976630336 (931.39 GiB 1000.07 GB)
Used Dev Size : 1953260672 (931.39 GiB 1000.07 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262064 sectors, after=304 sectors
State : clean
Device UUID : 8150c54e:3b72da54:4544c33d:36372195
Update Time : Thu Feb 4 11:58:22 2016
Checksum : 56cbbb8d - correct
Events : 571
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
----------------- disk specific information (ls -l /dev/disk/by-id/)
-----------------------
insgesamt 0
lrwxrwxrwx 1 root root 9 Apr 9 09:36 ata-SAMSUNG_HD103UJ_S13PJ9BQ900571 ->
../../sdc
lrwxrwxrwx 1 root root 10 Apr 9 09:36 ata-SAMSUNG_HD103UJ_S13PJ9BQ900571-part1
-> ../../sdc1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 ata-SAMSUNG_HD103UJ_S13PJ9BQA17616 ->
../../sdd
lrwxrwxrwx 1 root root 10 Apr 9 09:36 ata-SAMSUNG_HD103UJ_S13PJ9BQA17616-part1
-> ../../sdd1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 ata-WDC_WD1001FALS-00J7B0_WD-WMATV0444833
-> ../../sda
lrwxrwxrwx 1 root root 10 Apr 9 09:36
ata-WDC_WD1001FALS-00J7B0_WD-WMATV0444833-part1 -> ../../sda1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 ata-WDC_WD10EARS-00Y5B1_WD-WCAV5D907687
-> ../../sdb
lrwxrwxrwx 1 root root 10 Apr 9 09:36
ata-WDC_WD10EARS-00Y5B1_WD-WCAV5D907687-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Apr 9 09:36 dm-name-vg_backup_raid1-lv_backup ->
../../dm-0
lrwxrwxrwx 1 root root 10 Apr 9 09:36 dm-name-vg_raid1-home -> ../../dm-3
lrwxrwxrwx 1 root root 10 Apr 9 09:36 dm-name-vg_raid1-root -> ../../dm-1
lrwxrwxrwx 1 root root 10 Apr 9 09:36 dm-name-vg_raid1-swap -> ../../dm-2
lrwxrwxrwx 1 root root 10 Apr 9 09:36
dm-uuid-LVM-esKsCrquUIckjFQ6jcwYYZeKL4MRas87bdFuJuYmp3W1AwMDgzs0twPC8CLUZfV6 ->
../../dm-0
lrwxrwxrwx 1 root root 10 Apr 9 09:36
dm-uuid-LVM-mopUewB2i49fmomlXPZ8C3nPYOXM56AY3j92rd0GrGN3Ugvuxb8mlMbC36fMWbYO ->
../../dm-2
lrwxrwxrwx 1 root root 10 Apr 9 09:36
dm-uuid-LVM-mopUewB2i49fmomlXPZ8C3nPYOXM56AYplkh4xXCaC38PiDHPMyzTTs9JE5BRIHa ->
../../dm-3
lrwxrwxrwx 1 root root 10 Apr 9 09:36
dm-uuid-LVM-mopUewB2i49fmomlXPZ8C3nPYOXM56AYWBztmrFbDYLRGYdm6Eqi4oe4vvpVir3t ->
../../dm-1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 md-name-speernix15:0 -> ../../md0
lrwxrwxrwx 1 root root 9 Apr 9 09:36 md-name-speernix15:1 -> ../../md1
lrwxrwxrwx 1 root root 9 Apr 9 09:36
md-uuid-68c0c9ad:82ede879:2110f427:9f31c140 -> ../../md0
lrwxrwxrwx 1 root root 9 Apr 9 09:36
md-uuid-a9a43761:8148b29e:5db49d7a:c4d0a219 -> ../../md1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 wwn-0x50000f0007095017 -> ../../sdc
lrwxrwxrwx 1 root root 10 Apr 9 09:36 wwn-0x50000f0007095017-part1 ->
../../sdc1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 wwn-0x50000f00071a6761 -> ../../sdd
lrwxrwxrwx 1 root root 10 Apr 9 09:36 wwn-0x50000f00071a6761-part1 ->
../../sdd1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 wwn-0x50014ee0aba9f580 -> ../../sda
lrwxrwxrwx 1 root root 10 Apr 9 09:36 wwn-0x50014ee0aba9f580-part1 ->
../../sda1
lrwxrwxrwx 1 root root 9 Apr 9 09:36 wwn-0x50014ee259f4ab35 -> ../../sdb
lrwxrwxrwx 1 root root 10 Apr 9 09:36 wwn-0x50014ee259f4ab35-part1 ->
../../sdb1
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4]
[raid10]
md1 : active raid1 sdb1[0] sdc1[1]
976630336 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[1]
976629568 blocks super 1.2 [2/1] [_U]
unused devices: <none>
--
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: [mdadm PATCH 1/1] Fix some type comparison problems
From: Jes Sorensen @ 2016-02-04 13:12 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, deepa.kernel
In-Reply-To: <1454588811-3713-1-git-send-email-xni@redhat.com>
Xiao Ni <xni@redhat.com> writes:
> It complains when building on s390 and i686 platform.
>
> Signed-off-by : Xiao Ni <xni@redhat.com>
Hi Xiao,
The description needs to be a little clearer - something more like
"Change utime to unsigned int to be able to hold times until 2106."
> ---
> Monitor.c | 2 +-
> util.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Monitor.c b/Monitor.c
> index f19c2e5..9a6cf7e 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
> alert("NewArray", st->devname, NULL, ainfo);
> }
>
> - if (st->utime == array.utime &&
> + if ((unsigned int)st->utime == array.utime &&
> st->failed == array.failed_disks &&
> st->working == array.working_disks &&
> st->spare == array.spare_disks &&
Instead of the cast, please change the type in struct state.
> diff --git a/util.c b/util.c
> index 970d484..6e7d3fb 100644
> --- a/util.c
> +++ b/util.c
> @@ -1267,7 +1267,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
> */
> struct superswitch *ss;
> struct supertype *st;
> - time_t besttime = 0;
> + unsigned int besttime = 0;
> int bestsuper = -1;
> int i;
This one is fine.
Thanks,
Jes
^ permalink raw reply
* [mdadm PATCH 1/1] Fix some type comparison problems
From: Xiao Ni @ 2016-02-04 12:26 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen, deepa.kernel
It complains when building on s390 and i686 platform.
Signed-off-by : Xiao Ni <xni@redhat.com>
---
Monitor.c | 2 +-
util.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Monitor.c b/Monitor.c
index f19c2e5..9a6cf7e 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
alert("NewArray", st->devname, NULL, ainfo);
}
- if (st->utime == array.utime &&
+ if ((unsigned int)st->utime == array.utime &&
st->failed == array.failed_disks &&
st->working == array.working_disks &&
st->spare == array.spare_disks &&
diff --git a/util.c b/util.c
index 970d484..6e7d3fb 100644
--- a/util.c
+++ b/util.c
@@ -1267,7 +1267,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
*/
struct superswitch *ss;
struct supertype *st;
- time_t besttime = 0;
+ unsigned int besttime = 0;
int bestsuper = -1;
int i;
--
2.4.3
^ permalink raw reply related
* Re: Problem with array raid10 array resync on 4.4.0 (keeps reyncing each reboot)
From: Eric Valette @ 2016-02-04 6:57 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <20160204011731.GA29132@kernel.org>
On 04/02/2016 02:17, Shaohua Li wrote:
> On Mon, Feb 01, 2016 at 12:00:36AM +0100, Eric Valette wrote:
>> On 28/01/2016 20:52, Eric Valette wrote:
>>> On 28/01/2016 19:25, Shaohua Li wrote:
>>>
>>> If really needed can rebuild a 4.4 kernel and boot it. What do you mean
>>> by special config? I can send you my kernel .config once rebuild
>>> (oldconfig from 4.1.16)
>>
>> Linux nas2 4.4.1 #1 SMP Sun Jan 31 23:46:26 CET 2016 x86_64 GNU/Linux
>
> Nothing useful. Did you try stop the array and reassemble it in 4.4 and check
> if resync runs? I can only imagine the reboot script didn't clean shutdown the
> array and trigger the issue. A stop/reassemble circle will tell us if this is
> the issue.
If the issue was in the script it would happen with all the kernel
version no? Si far 3.14, 3.18, 4.1 works correctly (when upgrading).
Only 4.4 fails.
4.4 in fact seems to fails to boot the first time I boot it. As I have
no console normally, I have to shut down via power button and then it
resync. I can understand this behavior but not
1) that the resync fails each time and
2) that it fails to boot the first time I change for a 4.4 kernel.
-- eric
^ permalink raw reply
* Re: [mdadm PATCH 1/1] Fix some type comparison problems
From: Deepa Dinamani @ 2016-02-04 3:10 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Xiao Ni, linux-raid, Arnd Bergmann
In-Reply-To: <wrfjr3gth6pi.fsf@redhat.com>
On Wed, Feb 3, 2016 at 12:36 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> Xiao Ni <xni@redhat.com> writes:
>> It complains when building on s390 and i686 platform.
>>
>> Signed-off-by : Xiao Ni <xni@redhat.com>
>> ---
>> Monitor.c | 2 +-
>> util.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Monitor.c b/Monitor.c
>> index f19c2e5..928aa45 100644
>> --- a/Monitor.c
>> +++ b/Monitor.c
>> @@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
>> alert("NewArray", st->devname, NULL, ainfo);
>> }
>>
>> - if (st->utime == array.utime &&
>> + if (st->utime == (long)array.utime &&
>> st->failed == array.failed_disks &&
>> st->working == array.working_disks &&
>> st->spare == array.spare_disks &&
>
> Hi Xiao,
>
> Thanks for the patch - I think the correct fix in Monitor.c is to change
> utime in struct state from long to unsigned int, to match the change
> Deepa Dinamani introduced in 26714713cd2bad9e0bf7f4669f6cc4659ceaab6c
> utime is only ever derived from mdu_array_info_s, so it should be safe.
>
>> diff --git a/util.c b/util.c
>> index 970d484..ccbb2bc 100644
>> --- a/util.c
>> +++ b/util.c
>> @@ -1288,7 +1288,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
>> struct mdinfo info;
>> st->ss->getinfo_super(st, &info, NULL);
>> if (bestsuper == -1 ||
>> - besttime < info.array.ctime) {
>> + besttime < (time_t)info.array.ctime) {
>> bestsuper = i;
>> besttime = info.array.ctime;
>> }
>
> Here I think we should change the declaration of besttime from time_t to
> unsigned int, again to match the definition used in mdu_array_info_s.
>
> That or we should change mdu_array_info_s to use time_t instead, but I
> am not sure that would be safe.
It should be changed to unsigned int.
time_t is not long enough to hold timestamps after the year
2038(INT_MAX) as long is 32 bits on 32 bit systems.
It was changed to unsigned int to extend it until the year 2106.
-Deepa
^ permalink raw reply
* Re: RAID journal, requirements?
From: Shaohua Li @ 2016-02-04 1:25 UTC (permalink / raw)
To: Linus Lüssing; +Cc: linux-raid
In-Reply-To: <20160127001520.GH3039@otheros>
On Wed, Jan 27, 2016 at 01:15:20AM +0100, Linus Lüssing wrote:
> Hi,
>
> I am very excited about the new journaling feature for RAID in md
> and want to try it out soon.
>
> Neil's article on LWN already gave a great overview and some hints
> about it, but I am still a little unsure about the technical
> requirements for the journal device. E.g. speed, reliability and
> size-wise. And what the implications of failing them means.
>
> I want to setup a small home NAS. My personal priorities are:
> Firstly, low power-per-GB as it will be solar powered and battery
> backed. Second priority is reliability. Performance is not that
> important to me.
>
> My current plan: Tiny ARM-based computer (Odroid C1+: 4x USB (2.0,
> unfortunately) ports), 4x 2TB SATA HDDs (@0.7W idle, 1.7W max. each)
> + SATA-to-USB -> RAID5, microSD for OS + applications, an eMMC for
> a RAID journal. (later, once they hopefully get available in April,
> switch to the Turris Omnia which is ARM-based again but has
> mini-PCIe, too, where I would attach mini-PCIe-to-SATA adapters)
>
> Is it a stupid idea to use an eMMC for the journal in the first
> place? I am unsure how quickly it would wear out. And seems like I
> do not have SMART for it either... So it would probably fail badly
> at some point. Is that an issue, can I simply replace the eMMC
> then without any data loss? Will the current code at least try a
> write-through directly to the HDDs once a journal disk throws
> errors?
>
> Does MD assume that an underlying device performs some sort of wear
> leveling if necessary like SSDs do for instance - or does MD
> itself distribute writes evenly over the journaling disk?
> (Does anyone know whether eMMCs usually do some kind of wear leveling?)
>
>
> Thanks for all your work on this awesome new feature! (and special
> thanks to Neil for all the years of maintenance - it is a pitty you
> have to step down :( )
The only requirement of journal is it has a block interface. But all write IO
write to journal first, so there could be a lot of write to journal depending
on your workload. I don't know about eMMC much, but suppose it doesn't have
good wear leveling support.
If journal is broken, your data isn't lost, as data is still stored in raid
disks. Our current policy is the array becomes read-only if journal is borken,
this might be changed if necessary though.
Thanks,
Shaohua
--
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: Problem with array raid10 array resync on 4.4.0 (keeps reyncing each reboot)
From: Shaohua Li @ 2016-02-04 1:17 UTC (permalink / raw)
To: Eric Valette; +Cc: linux-raid
In-Reply-To: <56AE9214.3030206@free.fr>
On Mon, Feb 01, 2016 at 12:00:36AM +0100, Eric Valette wrote:
> On 28/01/2016 20:52, Eric Valette wrote:
> >On 28/01/2016 19:25, Shaohua Li wrote:
> >
> >If really needed can rebuild a 4.4 kernel and boot it. What do you mean
> >by special config? I can send you my kernel .config once rebuild
> >(oldconfig from 4.1.16)
>
> Linux nas2 4.4.1 #1 SMP Sun Jan 31 23:46:26 CET 2016 x86_64 GNU/Linux
Nothing useful. Did you try stop the array and reassemble it in 4.4 and check
if resync runs? I can only imagine the reboot script didn't clean shutdown the
array and trigger the issue. A stop/reassemble circle will tell us if this is
the issue.
Thanks,
Shaohua
^ permalink raw reply
* [GIT PULL] MD fix for 4.5-rc2
From: Shaohua Li @ 2016-02-04 0:49 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid, neilb, gayatri.kammela, snitzer
Hi Linus,
As you know, Neil steps down from MD. I'm looking after it. Here are some
patches queued. A build fix from Gayatri and several trival patches from me.
Please pull.
Thanks,
Shaohua
----------------------------------------------------------------
The following changes since commit b37a05c083c85c2657dca9bbe1f5d79dccf756d5:
Merge branch 'akpm' (patches from Andrew) (2016-02-03 10:10:02 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git for-linus
for you to fetch changes up to 9ea064158f4e02e64890ee1261449b01e954e594:
Merge branch 'mymd/for-next' into mymd/for-linus (2016-02-03 15:43:59 -0800)
----------------------------------------------------------------
Gayatri Kammela (1):
raid6/algos.c : bug fix : Add the missing definitions to the pq.h file
Shaohua Li (5):
MD: rename some functions
MD: add myself as MD maintainer
md-cluster: fix missing memory free
md-cluster: delete useless code
Merge branch 'mymd/for-next' into mymd/for-linus
MAINTAINERS | 1 +
drivers/md/bitmap.c | 4 ----
drivers/md/faulty.c | 18 +++++++++---------
drivers/md/md-cluster.c | 6 +++++-
drivers/md/raid1.c | 21 +++++++++++----------
drivers/md/raid10.c | 20 ++++++++++----------
drivers/md/raid5.c | 45 +++++++++++++++++++++++----------------------
include/linux/raid/pq.h | 2 ++
8 files changed, 61 insertions(+), 56 deletions(-)
^ permalink raw reply
* Re: [mdadm PATCH 1/1] Fix some type comparison problems
From: Jes Sorensen @ 2016-02-03 20:36 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, Deepa Dinamani
In-Reply-To: <1454477089-8166-1-git-send-email-xni@redhat.com>
Xiao Ni <xni@redhat.com> writes:
> It complains when building on s390 and i686 platform.
>
> Signed-off-by : Xiao Ni <xni@redhat.com>
> ---
> Monitor.c | 2 +-
> util.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Monitor.c b/Monitor.c
> index f19c2e5..928aa45 100644
> --- a/Monitor.c
> +++ b/Monitor.c
> @@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
> alert("NewArray", st->devname, NULL, ainfo);
> }
>
> - if (st->utime == array.utime &&
> + if (st->utime == (long)array.utime &&
> st->failed == array.failed_disks &&
> st->working == array.working_disks &&
> st->spare == array.spare_disks &&
Hi Xiao,
Thanks for the patch - I think the correct fix in Monitor.c is to change
utime in struct state from long to unsigned int, to match the change
Deepa Dinamani introduced in 26714713cd2bad9e0bf7f4669f6cc4659ceaab6c
utime is only ever derived from mdu_array_info_s, so it should be safe.
> diff --git a/util.c b/util.c
> index 970d484..ccbb2bc 100644
> --- a/util.c
> +++ b/util.c
> @@ -1288,7 +1288,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
> struct mdinfo info;
> st->ss->getinfo_super(st, &info, NULL);
> if (bestsuper == -1 ||
> - besttime < info.array.ctime) {
> + besttime < (time_t)info.array.ctime) {
> bestsuper = i;
> besttime = info.array.ctime;
> }
Here I think we should change the declaration of besttime from time_t to
unsigned int, again to match the definition used in mdu_array_info_s.
That or we should change mdu_array_info_s to use time_t instead, but I
am not sure that would be safe.
Cheers,
Jes
^ permalink raw reply
* [mdadm PATCH 1/1] Fix some type comparison problems
From: Xiao Ni @ 2016-02-03 5:24 UTC (permalink / raw)
To: linux-raid; +Cc: Jes.Sorensen
It complains when building on s390 and i686 platform.
Signed-off-by : Xiao Ni <xni@redhat.com>
---
Monitor.c | 2 +-
util.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Monitor.c b/Monitor.c
index f19c2e5..928aa45 100644
--- a/Monitor.c
+++ b/Monitor.c
@@ -542,7 +542,7 @@ static int check_array(struct state *st, struct mdstat_ent *mdstat,
alert("NewArray", st->devname, NULL, ainfo);
}
- if (st->utime == array.utime &&
+ if (st->utime == (long)array.utime &&
st->failed == array.failed_disks &&
st->working == array.working_disks &&
st->spare == array.spare_disks &&
diff --git a/util.c b/util.c
index 970d484..ccbb2bc 100644
--- a/util.c
+++ b/util.c
@@ -1288,7 +1288,7 @@ struct supertype *guess_super_type(int fd, enum guess_types guess_type)
struct mdinfo info;
st->ss->getinfo_super(st, &info, NULL);
if (bestsuper == -1 ||
- besttime < info.array.ctime) {
+ besttime < (time_t)info.array.ctime) {
bestsuper = i;
besttime = info.array.ctime;
}
--
2.4.3
^ permalink raw reply related
* Re: Bogus entry in mdadm bad blocks list and question about particular commit
From: Sarah Newman @ 2016-02-02 21:09 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-raid
In-Reply-To: <wrfjtwlqq1rq.fsf@redhat.com>
On 02/02/2016 12:46 PM, Jes Sorensen wrote:
> Sarah Newman <srn@prgmr.com> writes:
>> I added some more drives to a raid 1 last night where some devices had existing bad block entries. There was nothing of particular interest in
>> /var/log/messages. Afterwards there is:
>>
>> $ sudo /sbin/mdadm --examine-badblocks /dev/sdl1
>> Bad-blocks on /dev/sdl1:
>> 11986270392325491 for 51 sectors
>>
>> The total number of sectors on the drive is 3907029168.
>>
>> The start sector in the bad blocks list is 2a95730cea9573 in hex, I don't know if that string has any special significance or not.
>> I looked for differences in between 3.18.21 and stable 3.18.y and the
>> only interesting thing looked like e9206476ace "md/raid1:
>> submit_bio_wait() returns 0 on success". I don't think that's a
>> smoking gun for the bogus bad blocks entry. But without that commit,
>> mdadm with bad blocks enabled is completely broken if there are write
>> errors such that successful writes are reported as errors and vice
>> versa, is that correct?
>
> Sarah,
>
> If I remember correctly, yes then badblocks handling was pretty wedged
> without that patch since it broke the narrowing down of the problem. If
> you have to run such an old kernel, you really ought to backport
> 681ab4696062f5aa939c9e04d058732306a97176 and
> 203d27b0226a05202438ddb39ef0ef1acb14a759 if you have raid1 and/or raid10
> arrays.
Noted.
What about the bad blocks entry with the completely bogus sector, is there a plausible explanation for that?
Thanks, Sarah
^ permalink raw reply
* Re: Bogus entry in mdadm bad blocks list and question about particular commit
From: Jes Sorensen @ 2016-02-02 20:46 UTC (permalink / raw)
To: Sarah Newman; +Cc: linux-raid
In-Reply-To: <56B112F3.9010609@prgmr.com>
Sarah Newman <srn@prgmr.com> writes:
> I added some more drives to a raid 1 last night where some devices had existing bad block entries. There was nothing of particular interest in
> /var/log/messages. Afterwards there is:
>
> $ sudo /sbin/mdadm --examine-badblocks /dev/sdl1
> Bad-blocks on /dev/sdl1:
> 11986270392325491 for 51 sectors
>
> The total number of sectors on the drive is 3907029168.
>
> The start sector in the bad blocks list is 2a95730cea9573 in hex, I don't know if that string has any special significance or not.
>
> $ sudo /sbin/mdadm --examine /dev/sdl1
> /dev/sdl1:
> Magic : a92b4efc
> Version : 1.0
> Feature Map : 0x8
>
> Raid Level : raid1
> Raid Devices : 11
>
> Avail Dev Size : 20971368 (10.00 GiB 10.74 GB)
> Array Size : 10485632 (10.00 GiB 10.74 GB)
> Used Dev Size : 20971264 (10.00 GiB 10.74 GB)
> Super Offset : 20971504 sectors
> Unused Space : before=0 sectors, after=232 sectors
> State : clean
>
> Update Time : Tue Feb 2 10:50:33 2016
> Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present.
> Checksum : 4092aabf - correct
> Events : 143560
>
>
> Device Role : Active device 9
> Array State : AAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)
>
> The kernel is built from the Xen4CentOS 3.18.21-17 kernel, but there
> are no changes related to md in the code.
>
> I looked for differences in between 3.18.21 and stable 3.18.y and the
> only interesting thing looked like e9206476ace "md/raid1:
> submit_bio_wait() returns 0 on success". I don't think that's a
> smoking gun for the bogus bad blocks entry. But without that commit,
> mdadm with bad blocks enabled is completely broken if there are write
> errors such that successful writes are reported as errors and vice
> versa, is that correct?
Sarah,
If I remember correctly, yes then badblocks handling was pretty wedged
without that patch since it broke the narrowing down of the problem. If
you have to run such an old kernel, you really ought to backport
681ab4696062f5aa939c9e04d058732306a97176 and
203d27b0226a05202438ddb39ef0ef1acb14a759 if you have raid1 and/or raid10
arrays.
Jes
^ 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