* [GIT PULL] MD for 4.7-rc1
From: Shaohua Li @ 2016-05-19 18:34 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid, neilb
Hi Linus,
pleae pull MD update for 4.7. It includes several patches from Guoqing fixing
md-cluster bugs and several patches from Heinz fixing dm-raid bugs.
Thanks,
Shaohua
The following changes since commit 4810d9682971e8eee659f96e4f9d9154e3c6c0b4:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2016-05-04 11:14:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.7-rc1
for you to fetch changes up to 1fa9a1ad0a9db3c745fe0c1bfa73fd87901fd7f3:
md-cluster: check the return value of process_recvd_msg (2016-05-09 09:24:04 -0700)
----------------------------------------------------------------
Guoqing Jiang (15):
md-cluster: change resync lock from asynchronous to synchronous
md-cluser: make resync_finish only called after pers->sync_request
md-cluster: wake up thread to continue recovery
md-cluster: unregister thread if err happened
md-cluster: fix locking when node joins cluster during message broadcast
md-cluster: change array_sectors and update size are not supported
md-cluster: wakeup thread if activated a spare disk
md-cluster: always setup in-memory bitmap
md-cluster: sync bitmap when node received RESYNCING msg
md-cluster/bitmap: fix wrong calcuation of offset
md-cluster/bitmap: fix wrong page num in bitmap_file_clear_bit and bitmap_file_set_bit
md-cluster/bitmap: unplug bitmap to sync dirty pages to disk
md: set MD_CHANGE_PENDING in a atomic region
md-cluster: gather resync infos and enable recv_thread after bitmap is ready
md-cluster: check the return value of process_recvd_msg
Heinz Mauelshagen (3):
md: md.c: fix oops in mddev_suspend for raid0
md: raid10: add prerequisite to run underneath dm-raid
md: raid5: add prerequisite to run underneath dm-raid
kbuild test robot (1):
md-cluster: fix ifnullfree.cocci warnings
Documentation/md-cluster.txt | 6 +++
drivers/md/bitmap.c | 88 +++++++++++++++++++++++++++++++++++-----
drivers/md/bitmap.h | 3 ++
drivers/md/md-cluster.c | 96 ++++++++++++++++++++++++++++++++++++--------
drivers/md/md-cluster.h | 1 +
drivers/md/md.c | 86 ++++++++++++++++++++++++---------------
drivers/md/raid1.c | 4 +-
drivers/md/raid10.c | 20 +++++----
drivers/md/raid5-cache.c | 4 +-
drivers/md/raid5.c | 10 +++--
include/linux/bitops.h | 16 ++++++++
11 files changed, 257 insertions(+), 77 deletions(-)
^ permalink raw reply
* Re: [PATCH] IMSM: retry reading sync_completed during reshape
From: Jes Sorensen @ 2016-05-19 14:45 UTC (permalink / raw)
To: Pawel Baldysiak
Cc: linux-raid, artur.paszkiewicz, aleksey.obitotskiy,
tomasz.majchrzak
In-Reply-To: <146348428075.32064.12075746168157997590.stgit@gklab-154-222.intel.com>
Pawel Baldysiak <pawel.baldysiak@intel.com> writes:
> The sync_completed after restarting a reshape
> (for example - after reboot) is set to "delayed" until
> mdmon changes the state. Mdadm does not wait for that change with
> old kernels. If this condition occurs - it exits and reshape
> is not continuing. This patch adds retry of reading sync_complete
> with a delay. It gives time for mdmon to change the "delayed" state.
>
> Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
> ---
> super-intel.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
Hi Pawel,
Applied, thanks!
I have to admit I don't like this kind of fixes very much, delaying and
hoping for something to happen in time, but with the APIs we have it's
probably the best we can do.
Cheers,
Jes
^ permalink raw reply
* BLKZEROOUT not zeroing md dev on VMDK
From: Sitsofe Wheeler @ 2016-05-18 22:39 UTC (permalink / raw)
To: Shaohua Li
Cc: Jens Axboe, Darrick J. Wong, Arvind Kumar, VMware PV-Drivers,
linux-raid, linux-scsi, linux-block, linux-kernel
Hi,
With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23
4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the
BLKZEROOUT syscall can malfunction and not zero data.
When BLKZEROOUT is issued to an MD device atop a PVSCSI controller
supplied VMDK from ESXi 6.0 the call returns immediately and with a zero
return code. Unfortunately, inspecting the data on the MD device shows
that it has not been zeroed and is in fact untouched. The easiest way to
see this behaviour is to boot the VM, create an mdadm device atop
/dev/sd?, scribble some non-zero value on the disk and then use
blkdiscard --zeroout /dev/md??? . If you then inspect the MD disk (e.g.
with hexdump) you will still see the old data and using POSIX_FADV_DONTNEED
on the MD device doesn't change the outcome.
The only clue I've seen is that
/sys/block/sd?/queue/write_same_max_bytes starts out being 33553920 but
after a WRITE SAME is issued it becomes 0. If the MD device is created
after write_same_max_bytes has become 0 on the backing disk then
BLKZEROOUT seems to work correctly.
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* [PATCH 2/2] Change behavior in find_free_devnm when wrapping around.
From: Mike Lovell @ 2016-05-18 18:23 UTC (permalink / raw)
To: linux-raid; +Cc: Mike Lovell
In-Reply-To: <1463595794-17045-1-git-send-email-mlovell@bluehost.com>
Newer kernels don't allow for specifying an array larger than 511. This
makes it so find_free_devnm wraps to 511 instead of 2^20 - 1.
Signed-off-by: Mike Lovell <mlovell@bluehost.com>
---
mdopen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mdopen.c b/mdopen.c
index e71d758..f818fdf 100644
--- a/mdopen.c
+++ b/mdopen.c
@@ -439,7 +439,7 @@ char *find_free_devnm(int use_partitions)
static char devnm[32];
int devnum;
for (devnum = 127; devnum != 128;
- devnum = devnum ? devnum-1 : (1<<20)-1) {
+ devnum = devnum ? devnum-1 : (1<<9)-1) {
if (use_partitions)
sprintf(devnm, "md_d%d", devnum);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] Use dev_t for devnm2devid and devid2devnm
From: Mike Lovell @ 2016-05-18 18:23 UTC (permalink / raw)
To: linux-raid; +Cc: Mike Lovell
In-Reply-To: <1463595794-17045-1-git-send-email-mlovell@bluehost.com>
Commit 4dd2df0966ec added a trip through makedev(), major(), and minor() for
device major and minor numbers. This would cause mdadm to fail in operating
on a device with a minor number bigger than (2^19)-1 due to it changing
from dev_t to a signed int and back.
Where this was found as a problem was when a array was created with a device
specified as a name like /dev/md/raidname and there were already 128 arrays
on the system. In this case, mdadm would chose 1048575 ((2^20)-1) for the
array and minor number. This would cause the major and minor number to become
negative when generated from devnm2devid() and passed to major() and minor()
in open_dev_excl(). open_dev_excl() would then call dev_open() which would
detect the negative minor number and call open() on the *char containing the
major:minor pair which isn't a valid file.
Signed-off-by: Mike Lovell <mlovell@bluehost.com>
---
Detail.c | 4 ++--
Grow.c | 2 +-
lib.c | 2 +-
mapfile.c | 2 +-
mdadm.h | 4 ++--
mdopen.c | 4 ++--
util.c | 6 +++---
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Detail.c b/Detail.c
index 20c4553..7a984c8 100644
--- a/Detail.c
+++ b/Detail.c
@@ -130,7 +130,7 @@ int Detail(char *dev, struct context *c)
/* This is a subarray of some container.
* We want the name of the container, and the member
*/
- int devid = devnm2devid(st->container_devnm);
+ dev_t devid = devnm2devid(st->container_devnm);
int cfd, err;
member = subarray;
@@ -577,7 +577,7 @@ This is pretty boring
char path[200];
char vbuf[1024];
int nlen = strlen(sra->sys_name);
- int devid;
+ dev_t devid;
if (de->d_name[0] == '.')
continue;
sprintf(path, "/sys/block/%s/md/metadata_version",
diff --git a/Grow.c b/Grow.c
index f58c753..8f16d34 100755
--- a/Grow.c
+++ b/Grow.c
@@ -3527,7 +3527,7 @@ int reshape_container(char *container, char *devname,
int fd;
struct mdstat_ent *mdstat;
char *adev;
- int devid;
+ dev_t devid;
sysfs_free(cc);
diff --git a/lib.c b/lib.c
index 621edf3..3ee7659 100644
--- a/lib.c
+++ b/lib.c
@@ -99,7 +99,7 @@ char *fd2kname(int fd)
return NULL;
}
-char *devid2devnm(int devid)
+char *devid2devnm(dev_t devid)
{
char path[30];
char link[200];
diff --git a/mapfile.c b/mapfile.c
index 243ded1..c89d403 100644
--- a/mapfile.c
+++ b/mapfile.c
@@ -374,7 +374,7 @@ void RebuildMap(void)
char dn[30];
int dfd;
int ok;
- int devid;
+ dev_t devid;
struct supertype *st;
char *subarray = NULL;
char *path;
diff --git a/mdadm.h b/mdadm.h
index d209488..5ecdd84 100755
--- a/mdadm.h
+++ b/mdadm.h
@@ -1438,8 +1438,8 @@ extern char *find_free_devnm(int use_partitions);
extern void put_md_name(char *name);
extern char *devid2kname(int devid);
-extern char *devid2devnm(int devid);
-extern int devnm2devid(char *devnm);
+extern char *devid2devnm(dev_t devid);
+extern dev_t devnm2devid(char *devnm);
extern char *get_md_name(char *devnm);
extern char DefaultConfFile[];
diff --git a/mdopen.c b/mdopen.c
index 28410f4..e71d758 100644
--- a/mdopen.c
+++ b/mdopen.c
@@ -348,7 +348,7 @@ int create_mddev(char *dev, char *name, int autof, int trustworthy,
if (lstat(devname, &stb) == 0) {
/* Must be the correct device, else error */
if ((stb.st_mode&S_IFMT) != S_IFBLK ||
- stb.st_rdev != (dev_t)devnm2devid(devnm)) {
+ stb.st_rdev != devnm2devid(devnm)) {
pr_err("%s exists but looks wrong, please fix\n",
devname);
return -1;
@@ -452,7 +452,7 @@ char *find_free_devnm(int use_partitions)
if (!use_udev()) {
/* make sure it is new to /dev too, at least as a
* non-standard */
- int devid = devnm2devid(devnm);
+ dev_t devid = devnm2devid(devnm);
if (devid) {
char *dn = map_dev(major(devid),
minor(devid), 0);
diff --git a/util.c b/util.c
index 2bcb81f..31c407a 100644
--- a/util.c
+++ b/util.c
@@ -928,7 +928,7 @@ int get_data_disks(int level, int layout, int raid_disks)
return data_disks;
}
-int devnm2devid(char *devnm)
+dev_t devnm2devid(char *devnm)
{
/* First look in /sys/block/$DEVNM/dev for %d:%d
* If that fails, try parsing out a number
@@ -1065,7 +1065,7 @@ int dev_open(char *dev, int flags)
int open_dev_flags(char *devnm, int flags)
{
- int devid;
+ dev_t devid;
char buf[20];
devid = devnm2devid(devnm);
@@ -1083,7 +1083,7 @@ int open_dev_excl(char *devnm)
char buf[20];
int i;
int flags = O_RDWR;
- int devid = devnm2devid(devnm);
+ dev_t devid = devnm2devid(devnm);
long delay = 1000;
sprintf(buf, "%d:%d", major(devid), minor(devid));
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Fixes for lots of arrays
From: Mike Lovell @ 2016-05-18 18:23 UTC (permalink / raw)
To: linux-raid; +Cc: Mike Lovell
This patch series fixes two issues around having more than 127 arrays on a
system. The first one fixes an issue with using a dev_t as int and the
number going negative when the array number would be larger than 2<<19. This
would happen when more than 128 arrays were created on the system without
creating the arrays by name. Manually specifying the large number would also
fail.
The second patch changes find_free_devnm in mdopen.c to use go to (2<<9)-1
after 128 arrays have been created. Newer versions of the kernel don't allow
the user to specify an array number than 511 so mdadm shouldn't automatically
choose a bigger number. There was discussion about checking for new_array
in /sys/module/md_mod/parameters on the list but that parameter has been in
the kernel since 2.6.29. Any kernel from the last 7 years would still be
limited by the check so it probably isn't worth a special case.
Mike Lovell (2):
Use dev_t for devnm2devid and devid2devnm
Change behavior in find_free_devnm when wrapping around.
Detail.c | 4 ++--
Grow.c | 2 +-
lib.c | 2 +-
mapfile.c | 2 +-
mdadm.h | 4 ++--
mdopen.c | 6 +++---
util.c | 6 +++---
7 files changed, 13 insertions(+), 13 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces
From: Eric W. Biederman @ 2016-05-18 16:27 UTC (permalink / raw)
To: Seth Forshee
Cc: Alexander Viro, Greg Kroah-Hartman, Jeff Layton, J. Bruce Fields,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, linux-kernel, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux, cgroups
In-Reply-To: <20160518161618.GC129218@ubuntu-hedt>
Seth Forshee <seth.forshee@canonical.com> writes:
> On Wed, May 18, 2016 at 10:45:31AM -0500, Eric W. Biederman wrote:
>> > But if we do that it violates some of the assumptions of the patch to
>> > rework MNT_NODEV on your testing branch (and also those behind patch 2
>> > in this series). Something will need to be changed there to prevent a
>> > regression in mount behavior when a user ns tries to mount without
>> > MNT_NODEV when the mount inherited from its parent has it set.
>>
>> Thank you for pointing that out. I will look into that.
>>
>> I believe I know exactly what you are talking about. Of the choices I
>> think it is better to a minor localized change in the fs_fully_visible
>> logic than it is to cause problems elsewhere.
>
> Agreed.
>
>> >> Apologies for not catching this earlier.
>> >
>> > Actually this is a more recent patch, so you possibly hadn't seen it
>> > before.
>> >
>> >> I am looking at folding all of this into the patch that introduces
>> >> sget_userns so that even bisects won't have regresssions.
>> >
>> > That's fine with me.
>>
>> And thank you for keeping everything as separate patches. That is at
>> least helping me catch up. Even if I don't agree that these things
>> should be separate come merge time.
>
> Honestly I probably would have squashed some of them into that first
> patch myself if you hadn't already applied it to your testing branch, so
> that's all just luck.
>
> Keep in mind that I also have that patch for mqueue that isn't in this
> series, and I haven't yet checked to see if the 4.7 merges introduce
> anything which is going to require updating these patches. I was
> planning to wait and send out updates after -rc1, but if you want that
> stuff sooner just let me know.
As unfortunately I don't have anything going into -rc1 I am working on
this right now.
Let me finish sorting out the sget_userns and mnt nodev mess and I will
push something out and then we can compare notes. I think I have mqueue
covered by other changes. As it is in the set of filesystems that
should just use sget_userns.
I am sorting through the nodev corner of this now. It should just be a
day or two.
Eric
^ permalink raw reply
* Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces
From: Seth Forshee @ 2016-05-18 16:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Alexander Viro, Greg Kroah-Hartman, Jeff Layton, J. Bruce Fields,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-bcache-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
selinux-+05T5uksL2qpZYMLLGbcSA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8760ubs738.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Wed, May 18, 2016 at 10:45:31AM -0500, Eric W. Biederman wrote:
> > But if we do that it violates some of the assumptions of the patch to
> > rework MNT_NODEV on your testing branch (and also those behind patch 2
> > in this series). Something will need to be changed there to prevent a
> > regression in mount behavior when a user ns tries to mount without
> > MNT_NODEV when the mount inherited from its parent has it set.
>
> Thank you for pointing that out. I will look into that.
>
> I believe I know exactly what you are talking about. Of the choices I
> think it is better to a minor localized change in the fs_fully_visible
> logic than it is to cause problems elsewhere.
Agreed.
> >> Apologies for not catching this earlier.
> >
> > Actually this is a more recent patch, so you possibly hadn't seen it
> > before.
> >
> >> I am looking at folding all of this into the patch that introduces
> >> sget_userns so that even bisects won't have regresssions.
> >
> > That's fine with me.
>
> And thank you for keeping everything as separate patches. That is at
> least helping me catch up. Even if I don't agree that these things
> should be separate come merge time.
Honestly I probably would have squashed some of them into that first
patch myself if you hadn't already applied it to your testing branch, so
that's all just luck.
Keep in mind that I also have that patch for mqueue that isn't in this
series, and I haven't yet checked to see if the 4.7 merges introduce
anything which is going to require updating these patches. I was
planning to wait and send out updates after -rc1, but if you want that
stuff sooner just let me know.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces
From: Eric W. Biederman @ 2016-05-18 15:45 UTC (permalink / raw)
To: Seth Forshee
Cc: Alexander Viro, Greg Kroah-Hartman, Jeff Layton, J. Bruce Fields,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-bcache-u79uwXL29TY76Z2rM5mHXA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
selinux-+05T5uksL2qpZYMLLGbcSA, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160517235834.GA104031@ubuntu-hedt>
Seth Forshee <seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
> On Tue, May 17, 2016 at 05:39:33PM -0500, Eric W. Biederman wrote:
>> Seth Forshee <seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> writes:
>>
>> > Both of these filesystems already have use cases for mounting the
>> > same super block from multiple user namespaces. For sysfs this
>> > happens when using criu for snapshotting a container, where sysfs
>> > is mnounted in the containers network ns but the hosts user ns.
>> > The cgroup filesystem shares the same super block for all mounts
>> > of the same hierarchy regardless of the namespace.
>> >
>> > As a result, the restriction on mounting a super block from a
>> > single user namespace creates regressions for existing uses of
>> > these filesystems. For these specific filesystems this
>> > restriction isn't really necessary since the backing store is
>> > objects in kernel memory and thus the ids assigned from inodes
>> > is not subject to translation relative to s_user_ns.
>> >
>> > Add a new filesystem flag, FS_USERNS_SHARE_SB, which when set
>> > causes sget_userns() to skip the check of s_user_ns. Set this
>> > flag for the sysfs and cgroup filesystems to fix the
>> > regressions.
>>
>> So this one needs to be sget_userns(..., &init_user_ns, ...).
>> And not a new special case.
>
> This is actually what I wanted to do, but based on a previous discussion
> where I had suggested doing this (for a different reason) I came away
> thinking you did not want it that way. So I'm happy with that change.
Yeah. Somedays it seems like there are a lot of pieces in play here.
The security labels on sysfs seems to be a very compelling case.
> But if we do that it violates some of the assumptions of the patch to
> rework MNT_NODEV on your testing branch (and also those behind patch 2
> in this series). Something will need to be changed there to prevent a
> regression in mount behavior when a user ns tries to mount without
> MNT_NODEV when the mount inherited from its parent has it set.
Thank you for pointing that out. I will look into that.
I believe I know exactly what you are talking about. Of the choices I
think it is better to a minor localized change in the fs_fully_visible
logic than it is to cause problems elsewhere.
>> Apologies for not catching this earlier.
>
> Actually this is a more recent patch, so you possibly hadn't seen it
> before.
>
>> I am looking at folding all of this into the patch that introduces
>> sget_userns so that even bisects won't have regresssions.
>
> That's fine with me.
And thank you for keeping everything as separate patches. That is at
least helping me catch up. Even if I don't agree that these things
should be separate come merge time.
Eric
^ permalink raw reply
* Re: Two disk RAID10 inactive on boot if partition is missing
From: Peter Kay @ 2016-05-18 4:16 UTC (permalink / raw)
To: Phil Turmel; +Cc: Mikael Abrahamsson, linux-raid@vger.kernel.org
In-Reply-To: <573B1D49.6090301@turmel.org>
On 17 May 2016 at 14:31, Phil Turmel <philip@turmel.org> wrote:
> See the "Unclean Shutdown" section of "man md".
>
> The kernel parameter you need is "md_mod.start_dirty_degraded=1".
>
> Doing this is a really good way to end up with split brain. Why do you
> need to regularly boot without the devices that were present at shutdown?
Thanks for the md reference.
I don't need to regularly boot with devices that were present at
shutdown, but this is RAID! Given that it's not a boot device, and
frankly even if it was, I would expect the default to be to start up
anyway and then to be able to replace the missing device to be an
option. Otherwise it removes a lot of the point of resilience.
I'll have a look at this further later tonight. The reason it is
failing from '-v' is because /dev/sda12 is 'busy'. Looks like I need
to read the docs further, I got it to come back up by using stop and
assemble, but yes looks like split brain is a thing when I do that.
Fortunately I'm not using this for anything important yet - I'm doing
this precisely so that I know what to do when a device does fail. Once
it's all working I'm going to leave it alone.
^ permalink raw reply
* Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces
From: Seth Forshee @ 2016-05-17 23:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Alexander Viro, Greg Kroah-Hartman, Jeff Layton, J. Bruce Fields,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, linux-kernel, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux, cgroups
In-Reply-To: <87shxgxqai.fsf@x220.int.ebiederm.org>
On Tue, May 17, 2016 at 05:39:33PM -0500, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@canonical.com> writes:
>
> > Both of these filesystems already have use cases for mounting the
> > same super block from multiple user namespaces. For sysfs this
> > happens when using criu for snapshotting a container, where sysfs
> > is mnounted in the containers network ns but the hosts user ns.
> > The cgroup filesystem shares the same super block for all mounts
> > of the same hierarchy regardless of the namespace.
> >
> > As a result, the restriction on mounting a super block from a
> > single user namespace creates regressions for existing uses of
> > these filesystems. For these specific filesystems this
> > restriction isn't really necessary since the backing store is
> > objects in kernel memory and thus the ids assigned from inodes
> > is not subject to translation relative to s_user_ns.
> >
> > Add a new filesystem flag, FS_USERNS_SHARE_SB, which when set
> > causes sget_userns() to skip the check of s_user_ns. Set this
> > flag for the sysfs and cgroup filesystems to fix the
> > regressions.
>
> So this one needs to be sget_userns(..., &init_user_ns, ...).
> And not a new special case.
This is actually what I wanted to do, but based on a previous discussion
where I had suggested doing this (for a different reason) I came away
thinking you did not want it that way. So I'm happy with that change.
But if we do that it violates some of the assumptions of the patch to
rework MNT_NODEV on your testing branch (and also those behind patch 2
in this series). Something will need to be changed there to prevent a
regression in mount behavior when a user ns tries to mount without
MNT_NODEV when the mount inherited from its parent has it set.
> Apologies for not catching this earlier.
Actually this is a more recent patch, so you possibly hadn't seen it
before.
> I am looking at folding all of this into the patch that introduces
> sget_userns so that even bisects won't have regresssions.
That's fine with me.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH v4 03/21] fs: Allow sysfs and cgroupfs to share super blocks between user namespaces
From: Eric W. Biederman @ 2016-05-17 22:39 UTC (permalink / raw)
To: Seth Forshee
Cc: Alexander Viro, Greg Kroah-Hartman, Jeff Layton, J. Bruce Fields,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, linux-kernel, linux-bcache, dm-devel,
linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux, cgroups
In-Reply-To: <1461699046-30485-4-git-send-email-seth.forshee@canonical.com>
Seth Forshee <seth.forshee@canonical.com> writes:
> Both of these filesystems already have use cases for mounting the
> same super block from multiple user namespaces. For sysfs this
> happens when using criu for snapshotting a container, where sysfs
> is mnounted in the containers network ns but the hosts user ns.
> The cgroup filesystem shares the same super block for all mounts
> of the same hierarchy regardless of the namespace.
>
> As a result, the restriction on mounting a super block from a
> single user namespace creates regressions for existing uses of
> these filesystems. For these specific filesystems this
> restriction isn't really necessary since the backing store is
> objects in kernel memory and thus the ids assigned from inodes
> is not subject to translation relative to s_user_ns.
>
> Add a new filesystem flag, FS_USERNS_SHARE_SB, which when set
> causes sget_userns() to skip the check of s_user_ns. Set this
> flag for the sysfs and cgroup filesystems to fix the
> regressions.
So this one needs to be sget_userns(..., &init_user_ns, ...).
And not a new special case.
Apologies for not catching this earlier.
I am looking at folding all of this into the patch that introduces
sget_userns so that even bisects won't have regresssions.
We loose the ability to call mount -o remount and actually affect
these filesystems (which we don't have without s_user_ns) but we gain a
whole lot of simplicity, and we don't break the xattr and security label
on sysfs code.
Eric
^ permalink raw reply
* Re: mdadm - stuck reshape operation
From: Erkki Seppala @ 2016-05-17 20:01 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <22305.30340.565924.810276@quad.stoffel.home>
Hi,
"John Stoffel" <john@stoffel.org> writes:
> Are there any messages in the logs, or dmesg output after the stuff
> you showed? Can you maybe 'strace' the mdadm process, or even go grab
> the latest version using git from:
>
> git clone git://neil.brown.name/mdadm
I had a similar issue and tried to set up a reproduction in a virtual
machine - but then after trying to retry the reproduction after a
success I failed, constantly.
So I'm wondering is there some particular patch in that tree that might
affect this behavior? I'm using the mdadm 3.4 from Debian Unstable. I
would rather avoid converting my non-test array before I get some
confidence it won't stop in the middle :).
Thanks for insight,
--
_____________________________________________________________________
/ __// /__ ____ __ http://www.modeemi.fi/~flux/\ \
/ /_ / // // /\ \/ / \ /
/_/ /_/ \___/ /_/\_\@modeemi.fi \/
^ permalink raw reply
* Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]
From: Wolfgang Denk @ 2016-05-17 18:42 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20160516131439.GA2850@metamorpher.de>
Dear Andreas,
In message <20160516131439.GA2850@metamorpher.de> you wrote:
> On Mon, May 16, 2016 at 02:58:01PM +0200, Wolfgang Denk wrote:
> > Seems I was lucky - already the second of the 120 possible
> > combination turned out to be working: b a c d f e
>
> Find a large enough file (disks * chunksize) and verify it.
Running "fsck -f -n" over one of the (big, multi million files) file
systems turned out to be a quick and good enough test.
> With GPT partition table, I set PARTLABEL to mdnumber-role so that's
> another place that has metadata in case mdadm loses its own...
> Since GPT lives at beginning and end of the disk it should have a
> good chance of surviving accidents, and you can address them as
> /dev/disk/by-partlabel/mdnumber-* in the correct order...
So far I did not use any partitioning at all on such drives. never
needed it...
> Anyway, glad you (hopefully, finally?) got your data back.
Yes, indeed, all data recovered. And I really owe you a beer...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Lispers are among the best grads of the Sweep-It-Under-Someone-
Else's-Carpet School of Simulated Simplicity. [Was that sufficiently
incendiary? :-)] - Larry Wall in <1992Jan10.201804.11926@netlabs.com
^ permalink raw reply
* [PATCH] mdcheck: Send progress messages to system log
From: Bill Merriam @ 2016-05-17 15:12 UTC (permalink / raw)
To: linux-raid
From 03bec5cfdd87f25b1669a4b62d19cf872403d37a Mon Sep 17 00:00:00 2001
From: Bill Merriam <bill@merriam.net>
Date: Tue, 17 May 2016 10:16:13 -0400
Subject: [PATCH] The mdcheck script now adds messages to the system log
to
report on progress of the array check. These are issued when mdcheck
starts
or continues a check and when it suspends a check at the expiration of
duration. The messages either report the check has completed or the
block
number of the current and last block in the array and the percentage of
completion.
Signed-off-by: Bill Merriam <bill@merriam.net>
---
misc/mdcheck | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/misc/mdcheck b/misc/mdcheck
index 2c8f54d..c33e3f6 100644
--- a/misc/mdcheck
+++ b/misc/mdcheck
@@ -100,6 +100,8 @@ do
continue
else
start=`cat "$fl"`
+ size=$(expr $(cat $sys/md/component_size) \* 2)
+ logger $(echo $dev $start $size | awk '{printf "MDCHECK Continuing
check on %s at block %i of %i, %6.2f%% complete\n", $1, $2, $3,
$2/$3*100 }')
fi
cnt=$[cnt+1]
@@ -129,6 +131,7 @@ do
then
eval MD_${i}_fl=
rm -f $fl
+ logger "MDCHECK check completed on ${sys##*/}, removing $fl"
continue;
fi
read a rest < $sys/md/sync_completed
@@ -156,4 +159,8 @@ do
fi
echo idle > $sys/md/sync_action
cat $sys/md/sync_min > $fl
+ dev=${sys##*/}
+ start=$(cat $fl)
+ size=$(expr $(cat $sys/md/component_size) \* 2)
+ logger $(echo $dev $start $size | awk '{printf "MDCHECK Suspending
check on %s at block %i of %i, %6.2f%% complete\n", $1, $2, $3,
$2/$3*100 }')
done
--
^ permalink raw reply related
* Re: Two disk RAID10 inactive on boot if partition is missing
From: Phil Turmel @ 2016-05-17 13:31 UTC (permalink / raw)
To: Mikael Abrahamsson, Peter Kay; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <alpine.DEB.2.02.1605171209470.28372@uplift.swm.pp.se>
On 05/17/2016 06:13 AM, Mikael Abrahamsson wrote:
> On Tue, 17 May 2016, Peter Kay wrote:
>
>> I'm not trying to boot from it, and I'm using Salix (Slackware), not a
>> debian based distribution. My boot partitions are not raided.
>
> The setting would still be valid if your distribution defaults to not
> assembling and using degraded arrays on boot.
See the "Unclean Shutdown" section of "man md".
The kernel parameter you need is "md_mod.start_dirty_degraded=1".
Doing this is a really good way to end up with split brain. Why do you
need to regularly boot without the devices that were present at shutdown?
Phil
^ permalink raw reply
* [PATCH] IMSM: retry reading sync_completed during reshape
From: Pawel Baldysiak @ 2016-05-17 11:24 UTC (permalink / raw)
To: jes.sorensen
Cc: linux-raid, artur.paszkiewicz, aleksey.obitotskiy,
tomasz.majchrzak
The sync_completed after restarting a reshape
(for example - after reboot) is set to "delayed" until
mdmon changes the state. Mdadm does not wait for that change with
old kernels. If this condition occurs - it exits and reshape
is not continuing. This patch adds retry of reading sync_complete
with a delay. It gives time for mdmon to change the "delayed" state.
Signed-off-by: Pawel Baldysiak <pawel.baldysiak@intel.com>
---
super-intel.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/super-intel.c b/super-intel.c
index ba3ee48..7e2860c 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -10378,6 +10378,7 @@ exit_imsm_reshape_super:
int wait_for_reshape_imsm(struct mdinfo *sra, int ndata)
{
int fd = sysfs_get_fd(sra, NULL, "sync_completed");
+ int retry = 3;
unsigned long long completed;
/* to_complete : new sync_max position */
unsigned long long to_complete = sra->reshape_progress;
@@ -10388,11 +10389,17 @@ int wait_for_reshape_imsm(struct mdinfo *sra, int ndata)
return 1;
}
- if (sysfs_fd_get_ll(fd, &completed) < 0) {
- dprintf("cannot read reshape_position (no reshape in progres)\n");
- close(fd);
- return 1;
- }
+ do {
+ if (sysfs_fd_get_ll(fd, &completed) < 0) {
+ if (!retry) {
+ dprintf("cannot read reshape_position (no reshape in progres)\n");
+ close(fd);
+ return 1;
+ }
+ usleep(30000);
+ } else
+ break;
+ } while (retry--);
if (completed > position_to_set) {
dprintf("wrong next position to set %llu (%llu)\n",
^ permalink raw reply related
* Re: Two disk RAID10 inactive on boot if partition is missing
From: Mikael Abrahamsson @ 2016-05-17 10:13 UTC (permalink / raw)
To: Peter Kay; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <CAN4OnoguQMvnuUr7mGYpTi7_SonZ42Z5TSigKaJ0ZfZuiup0Og@mail.gmail.com>
On Tue, 17 May 2016, Peter Kay wrote:
> I'm not trying to boot from it, and I'm using Salix (Slackware), not a
> debian based distribution. My boot partitions are not raided.
The setting would still be valid if your distribution defaults to not
assembling and using degraded arrays on boot.
A dmesg output from when "it doesn't work" would probably yield an answer
if this is why it's not being started properly.
> If I tell mdam to activate the raid I get no errors, and nothing
> happens.
It would be interesting to see what mdadm command options you use here,
and mdadm output from this with verbose output (-v) turned on, and what is
written in dmesg when you do this.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* [PATCH] Need update superblock on time when deciding to do reshape
From: Xiao Ni @ 2016-05-17 8:54 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Jes.Sorensen
Hi all
If the disks are not enough to have spaces for relocating the data_offset,
it needs to run start_reshape and then run mdadm --grow --continue by
systemd. But mdadm --grow --continue fails because it checkes that
info->reshape_active is 0.
The info->reshape_active is set to 1 when the superblock feature_map
have the flag MD_FEATURE_RESHAPE_ACTIVE. Superblock feature_map is set
MD_FEATURE_RESHAPE_ACTIVE as mddev->reshape_position != MaxSector.
Function start_reshape calls raid5_start_reshape which changes
mddev->reshape_position to 0. Then in md_check_recovery it updates the
superblock to underlying devices. But there is a chance that the superblock
haven't written to underlying devices, the mdadm reads the superblock data.
So mdadm --grow --continue fails.
The steps to reproduce this:
mdadm -CR /dev/md0 -l5 -n3 /dev/loop[0-2] --bitmap=internal
mdadm --wait /dev/md0
mdadm /dev/md0 -a /dev/loop3
mdadm --grow --raid-devices 4 /dev/md0
The loop device size is 500MB
[root@storageqe-09 ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 loop3[4] loop2[3] loop1[1] loop0[0]
1021952 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
[>....................] reshape = 0.0% (1/510976) finish=0.0min speed=255488K/sec
bitmap: 1/1 pages [4KB], 65536KB chunk
unused devices: <none>
So if we update the superblock on time, mdadm can read the right superblock data.
Signed-off-by <xni@redhat.com>
---
drivers/md/md.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 14d3b37..7919606 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -4350,6 +4350,7 @@ action_store(struct mddev *mddev, const char *page, size_t len)
else {
clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
err = mddev->pers->start_reshape(mddev);
+ md_update_sb(mddev, 1);
}
mddev_unlock(mddev);
}
--
2.4.3
^ permalink raw reply related
* Re: Two disk RAID10 inactive on boot if partition is missing
From: Mikael Abrahamsson @ 2016-05-17 8:40 UTC (permalink / raw)
To: Peter Kay; +Cc: linux-raid
In-Reply-To: <CAN4OnogXN45Z3UUJyFzGgACPXuQMm1Gfw18kY9bjATrt5tvNqg@mail.gmail.com>
On Tue, 17 May 2016, Peter Kay wrote:
> If the entire SSD device is missing on boot, the mdraid fails to exist
> (/dev/md/mdcache is not present), saying it's inactive and the partition
> device is a spare, thus causing the bcache to fail to exist also.
I didn't see this in your email, does this help?
https://help.ubuntu.com/community/Installation/SoftwareRAID#Boot_from_Degraded_Disk
Boot from Degraded Disk
If the default HDD fails then RAID will ask you to boot from a degraded
disk. If your server is located in a remote area, the best practice may be
to configure this to occur automatically:
edit /etc/initramfs-tools/conf.d/mdadm
change "BOOT_DEGRADED=false" to "BOOT_DEGRADED=true"
# Please provide URL to support claim: (this option is not supported from
mdadm-3.2.5-5ubuntu3 / Ubuntu 14.04 onwards)
Additionally, this can be specified on the kernel boot line with the
bootdegraded=[true|false]
You also can use #dpkg-reconfigure mdadm rather than CLI!
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Two disk RAID10 inactive on boot if partition is missing
From: Peter Kay @ 2016-05-17 1:52 UTC (permalink / raw)
To: linux-raid
I have a two disk RAID10 device consisting of a partition on one SSD
(/dev/sda12), and an entire other SSD (/dev/sdc). This is used to
create an mdraid device, acting as a cache for bcache.
This works fine if it boots up with the ssd and partition, and also if
one device goes offline whilst the system is still up, and then the
device is added again.
If the entire SSD device is missing on boot, the mdraid fails to exist
(/dev/md/mdcache is not present), saying it's inactive and the
partition device is a spare, thus causing the bcache to fail to exist
also.
One factor, that probably is not significant due to the metadata, is
that the dev/sdc will be mapped by the kernel to another disk if the
SSD does not exist on startup i.e. because the BIOS skips over it
/dev/sdc will now be a hard drive used by another disk array, not the
missing SSD. Shouldn't be a problem as the devices are not hardcoded :
I had no mdadm.conf, I've changed it to the following with no effect :
DEVICE /dev/sda12 /dev/sd*
ARRAY /dev/md/mdcache metadata=1.2
UUID=e634085b:95d697c9:7a422bc2:c94b142d name=gladstone:mdcache
ARRAY /dev/md/mdbigraid metadata=1.2
UUID=b5d09362:28d19835:21556221:36531da3 name=gladstone:mdbigraid
uname -a
Linux gladstone 4.5.2-xen #1 SMP PREEMPT Wed Apr 27 02:12:36 BST 2016
x86_64 Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz GenuineIntel
GNU/Linux
(This is a Xen dom0. Have tried with an earlier Linux kernel, under
bare metal : no difference)
/dev/md/mdcache:
Version : 1.2
Creation Time : Sun Apr 10 22:51:53 2016
Raid Level : raid10
Array Size : 117151744 (111.72 GiB 119.96 GB)
Used Dev Size : 117151744 (111.72 GiB 119.96 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Tue May 17 01:14:29 2016
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : far=2
Chunk Size : 512K
Name : gladstone:mdcache (local to host gladstone)
UUID : e634085b:95d697c9:7a422bc2:c94b142d
Events : 125
Number Major Minor RaidDevice State
0 8 12 0 active sync /dev/sda12
2 8 32 1 active sync /dev/sdc
A cat /proc/mdstat when it's working
(yes, testing a rebuild of another four disk raid10)
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4] [multipath]
md126 : active raid10 sdf[0] sde[4] sdb[3] sdd[2]
1953261568 blocks super 1.2 512K chunks 2 offset-copies [4/3] [U_UU]
[=====>...............] recovery = 25.0% (244969472/976630784)
finish=213.5min speed=57106K/sec
md127 : active raid10 sda12[0] sdc[2]
117151744 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU]
unused devices: <none>
mdadm --examine of the partition
/dev/sda12:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e634085b:95d697c9:7a422bc2:c94b142d
Name : gladstone:mdcache (local to host gladstone)
Creation Time : Sun Apr 10 22:51:53 2016
Raid Level : raid10
Raid Devices : 2
Avail Dev Size : 234305410 (111.73 GiB 119.96 GB)
Array Size : 117151744 (111.72 GiB 119.96 GB)
Used Dev Size : 234303488 (111.72 GiB 119.96 GB)
Data Offset : 131072 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 35309acc:c28c8b78:360f2d49:e87870db
Update Time : Tue May 17 01:29:23 2016
Checksum : 90634a13 - correct
Events : 125
Layout : far=2
Chunk Size : 512K
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing)
and disk
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e634085b:95d697c9:7a422bc2:c94b142d
Name : gladstone:mdcache (local to host gladstone)
Creation Time : Sun Apr 10 22:51:53 2016
Raid Level : raid10
Raid Devices : 2
Avail Dev Size : 234310576 (111.73 GiB 119.97 GB)
Array Size : 117151744 (111.72 GiB 119.96 GB)
Used Dev Size : 234303488 (111.72 GiB 119.96 GB)
Data Offset : 131072 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 76c6dba4:36e4a87a:ff54f25d:9e7a8970
Update Time : Tue May 17 02:09:25 2016
Checksum : 14a09cd9 - correct
Events : 125
Layout : far=2
Chunk Size : 512K
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing)
The partition was of type 83. I have changed to type FD with no difference.
Any clues? I can blow this away/change the disk (sdc) to be a
partition so the raid isn't using a partition and a disk if necessary,
but I can't see why it shouldn't work and would rather get to the root
cause.
If I tell mdam to activate the raid I get no errors, and nothing happens.
Cheers!
PK
^ permalink raw reply
* Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]
From: Andreas Klauer @ 2016-05-16 13:14 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-raid
In-Reply-To: <20160516125801.20A1A100879@atlas.denx.de>
On Mon, May 16, 2016 at 02:58:01PM +0200, Wolfgang Denk wrote:
> Seems I was lucky - already the second of the 120 possible
> combination turned out to be working: b a c d f e
Find a large enough file (disks * chunksize) and verify it.
Sometimes you can be unlucky, i.e. the LVM is detected, the filesystem
mounts, but still data is corrupt because the wrong two disks switched
places (just not the ones that contain filesystem metadata).
> But I still have not the slightest idea why the drive order might have
> changed...
Me neither. :)
With GPT partition table, I set PARTLABEL to mdnumber-role so that's
another place that has metadata in case mdadm loses its own...
Since GPT lives at beginning and end of the disk it should have a
good chance of surviving accidents, and you can address them as
/dev/disk/by-partlabel/mdnumber-* in the correct order...
Anyway, glad you (hopefully, finally?) got your data back.
Regards
Andreas Klauer
^ permalink raw reply
* Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]
From: Wolfgang Denk @ 2016-05-16 12:58 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20160516120600.5428910035C@atlas.denx.de>
Dear Andreas,
In message <20160516120600.5428910035C@atlas.denx.de> I wrote:
>
...
> OK, so I started playing around with the disk order - even though I
> checked yet another time from the disk serial numbers that the drive
> order "a b c d e f" is what was used when initially creating the
> array. When swapping the first two disks (so sda where the LABELONE
> is present) becomes the second disk (i. e. "b a c d e f"), then LVM
> will recognize the volume group and volumes, but data are corrupted.
>
> So I guess I have to try the possible permutations (probably with sda
> being the second disk only).
Seems I was lucky - already the second of the 120 possible
combination turned out to be working: b a c d f e
But I still have not the slightest idea why the drive order might have
changed...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Do you suppose the reason the ends of the `Intel Inside' logo don't
match up is that it was drawn on a Pentium?
^ permalink raw reply
* Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]
From: Wolfgang Denk @ 2016-05-16 12:06 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20160516083903.GA29380@EIS.leimen.priv>
Dear Andreas,
In message <20160516083903.GA29380@EIS.leimen.priv> you wrote:
>
> First, you can use hexdump after all to have a look at the first chunk
> (assuming the 136KiB you found is actually the data offset).
>
> dd bs=136K skip=1 if=/dev/mapper/sda | hexdump -C | less
>
> (same for sd?)
>
> LVM metadata is in plaintext, example:
Well, this does not look so bad:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 4c 41 42 45 4c 4f 4e 45 01 00 00 00 00 00 00 00 |LABELONE........|
00000210 3c fe 50 23 20 00 00 00 4c 56 4d 32 20 30 30 31 |<.P# ...LVM2 001|
00000220 34 79 78 49 78 69 48 73 6a 68 79 64 48 6f 76 58 |4yxIxiHsjhydHovX|
00000230 55 4f 30 48 47 31 5a 70 51 45 50 53 33 43 49 61 |UO0HG1ZpQEPS3CIa|
00000240 00 00 65 83 a3 03 00 00 00 00 03 00 00 00 00 00 |..e.............|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................|
00000270 00 f0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 3a fe b8 5d 20 4c 56 4d 32 20 78 5b 35 41 25 72 |:..] LVM2 x[5A%r|
00001010 30 4e 2a 3e 01 00 00 00 00 10 00 00 00 00 00 00 |0N*>............|
00001020 00 f0 02 00 00 00 00 00 00 80 00 00 00 00 00 00 |................|
00001030 46 0b 00 00 00 00 00 00 65 8d d7 42 00 00 00 00 |F.......e..B....|
00001040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001200 63 61 73 74 6f 72 30 20 7b 0a 69 64 20 3d 20 22 |castor0 {.id = "|
00001210 56 33 52 6e 30 55 2d 47 4d 41 64 2d 34 55 73 4e |V3Rn0U-GMAd-4UsN|
00001220 2d 61 6d 35 69 2d 66 50 59 50 2d 41 43 37 70 2d |-am5i-fPYP-AC7p-|
00001230 66 4d 50 51 32 35 22 0a 73 65 71 6e 6f 20 3d 20 |fMPQ25".seqno = |
00001240 31 0a 73 74 61 74 75 73 20 3d 20 5b 22 52 45 53 |1.status = ["RES|
00001250 49 5a 45 41 42 4c 45 22 2c 20 22 52 45 41 44 22 |IZEABLE", "READ"|
00001260 2c 20 22 57 52 49 54 45 22 5d 0a 65 78 74 65 6e |, "WRITE"].exten|
00001270 74 5f 73 69 7a 65 20 3d 20 38 31 39 32 0a 6d 61 |t_size = 8192.ma|
00001280 78 5f 6c 76 20 3d 20 30 0a 6d 61 78 5f 70 76 20 |x_lv = 0.max_pv |
00001290 3d 20 30 0a 0a 70 68 79 73 69 63 61 6c 5f 76 6f |= 0..physical_vo|
000012a0 6c 75 6d 65 73 20 7b 0a 0a 70 76 30 20 7b 0a 69 |lumes {..pv0 {.i|
000012b0 64 20 3d 20 22 34 79 78 49 78 69 2d 48 73 6a 68 |d = "4yxIxi-Hsjh|
000012c0 2d 79 64 48 6f 2d 76 58 55 4f 2d 30 48 47 31 2d |-ydHo-vXUO-0HG1-|
000012d0 5a 70 51 45 2d 50 53 33 43 49 61 22 0a 64 65 76 |ZpQE-PS3CIa".dev|
000012e0 69 63 65 20 3d 20 22 2f 64 65 76 2f 6d 64 32 22 |ice = "/dev/md2"|
000012f0 0a 0a 73 74 61 74 75 73 20 3d 20 5b 22 41 4c 4c |..status = ["ALL|
00001300 4f 43 41 54 41 42 4c 45 22 5d 0a 64 65 76 5f 73 |OCATABLE"].dev_s|
00001310 69 7a 65 20 3d 20 37 38 31 34 30 39 39 35 38 34 |ize = 7814099584|
00001320 0a 70 65 5f 73 74 61 72 74 20 3d 20 33 38 34 0a |.pe_start = 384.|
00001330 70 65 5f 63 6f 75 6e 74 20 3d 20 39 35 33 38 36 |pe_count = 95386|
00001340 39 0a 7d 0a 7d 0a 0a 7d 0a 23 20 47 65 6e 65 72 |9.}.}..}.# Gener|
00001350 61 74 65 64 20 62 79 20 4c 56 4d 32 20 76 65 72 |ated by LVM2 ver|
00001360 73 69 6f 6e 20 32 2e 30 32 2e 33 39 20 28 32 30 |sion 2.02.39 (20|
00001370 30 38 2d 30 36 2d 32 37 29 3a 20 54 75 65 20 4a |08-06-27): Tue J|
00001380 61 6e 20 31 38 20 31 33 3a 30 31 3a 30 31 20 32 |an 18 13:01:01 2|
00001390 30 31 31 0a 0a 63 6f 6e 74 65 6e 74 73 20 3d 20 |011..contents = |
...
> For me this starts at offset 0x1200 (roughly 4K) should be well within
> your 16K chunk. It should look similar for you on one of your disks if
> the offset is correct.
Confirmed. So we can assume the offset if OK...
> You are using your disks in alphabetical order, are you sure this is
> the same order your RAID originally used? Maybe the drive letters
> changed?
I rechecked again...
> You found LABELONE on sda, which is your first drive (Device Role 0)
> in your RAID (see mdadm --examine after you create it), but when I
> create a new RAID based on loop devices, pvcreate and vgcreate it,
> the LABELONE actually appears on the 2nd drive (Device Role 1).
Confirmed. When I create a new array and pvcreate and vgcreate it, I
also see the LABELONE on /dev/mapper/sdb, at offset
134218240 LABELONE
= 131072 kB.
OK, so I started playing around with the disk order - even though I
checked yet another time from the disk serial numbers that the drive
order "a b c d e f" is what was used when initially creating the
array. When swapping the first two disks (so sda where the LABELONE
is present) becomes the second disk (i. e. "b a c d e f"), then LVM
will recognize the volume group and volumes, but data are corrupted.
So I guess I have to try the possible permutations (probably with sda
being the second disk only).
Doing that now. But I have no idea what could cause this...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Just because your doctor has a name for your condition doesn't mean
he knows what it is.
^ permalink raw reply
* Re: MD RAID6 corrupted by Avago 9260-4i controller [SOLVED]
From: Wolfgang Denk @ 2016-05-16 11:05 UTC (permalink / raw)
To: Andreas Klauer; +Cc: linux-raid
In-Reply-To: <20160516102418.GA2347@metamorpher.de>
Dear Andreas,
In message <20160516102418.GA2347@metamorpher.de> you wrote:
> On Mon, May 16, 2016 at 12:06:42PM +0200, Wolfgang Denk wrote:
> > Hm... is --data-offset the only parameter I can play with?
>
> There is also --layout=
The output of the initial create command was
mdadm: layout defaults to left-symmetric
mdadm: size set to 976762448K
mdadm: array /dev/md2 started.
so this should be known...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I think animal testing is a terrible idea; they get all nervous and
give the wrong answers.
^ 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