* Re: Raid 6 failing to assemble after machine power loss now, with 1 disk only failed, seems to think its a raid0 array
From: Phil Turmel @ 2016-03-30 22:17 UTC (permalink / raw)
To: Peter Knight, linux-raid
In-Reply-To: <CAAgcXJEgLxSaa7x3YO=CuMXS9hPPfPMiUtebQ4RB4F6dmQPd1g@mail.gmail.com>
On 03/30/2016 05:19 PM, Peter Knight wrote:
> Hi,
>
> I hope someone can explain what is going on and hopefully help me
> recover my data.
> What is causing this? and how can I get it reassembled so I can read the data?
When mdadm assembles an array during boot that has fewer devices than
when it was last shut down (cleanly), it generally declines to start it.
Probably, all you need is:
mdadm --run /dev/md126
{ --detail may not be accurate on an inactive device. The member
--examine data is trustworthy. }
Phil
^ permalink raw reply
* Raid 6 failing to assemble after machine power loss now, with 1 disk only failed, seems to think its a raid0 array
From: Peter Knight @ 2016-03-30 21:19 UTC (permalink / raw)
To: linux-raid
Hi,
I hope someone can explain what is going on and hopefully help me
recover my data.
Machine stopped due to power cut it contains 5 hdd with 2 partitions
on each. one set of partitions was a raid1 and this came back fine
showing that disk sdd1 was out of date. the other set of partitions
for raid6 was much less happy. when looking at it (/dev/md126) it
seems to indicate it wants raid level0 but it was a raid6 array (which
has 2 spares) and only lost 1 disk. In case of problems caused by the
out dated partition we zeroed the superblock on the outdated partition
but it still seems to not reassemble the raid6 and says not enough
disks (which there are).
We have tried a manual entry in the /etc/mdadm/mdadm.conf file
specifying this uuid for the device and forcing the raid level to 6
but still no success
What is causing this? and how can I get it reassembled so I can read the data?
Thanks
Peter
Relevant commands and outputs below:
root@Wheal-Peevor:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5]
[raid4] [raid10]
md126 : inactive sdc2[1](S) sde2[3](S) sdf2[4](S) sdb2[0](S)
7730171648 blocks
md127 : active raid1 sdc1[1] sde1[3] sdf1[4] sdb1[0]
20971456 blocks [5/4] [UU_UU]
root@Wheal-Peevor:~# mdadm --detail /dev/md127
/dev/md127:
Version : 0.90
Creation Time : Sun Jan 9 14:02:22 2011
Raid Level : raid1
Array Size : 20971456 (20.00 GiB 21.47 GB)
Used Dev Size : 20971456 (20.00 GiB 21.47 GB)
Raid Devices : 5
Total Devices : 4
Preferred Minor : 127
Persistence : Superblock is persistent
Update Time : Wed Mar 30 21:51:26 2016
State : clean, degraded
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
UUID : 504284fe:c53effb7:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Events : 0.66830
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
4 0 0 4 removed
3 8 65 3 active sync /dev/sde1
4 8 81 4 active sync /dev/sdf1
root@Wheal-Peevor:~# mdadm --detail /dev/md126
/dev/md126:
Version : 0.90
Raid Level : raid0
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
State : inactive
UUID : 81186e3e:7abdbb10:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Events : 0.2615946
Number Major Minor RaidDevice
- 8 18 - /dev/sdb2
- 8 34 - /dev/sdc2
- 8 66 - /dev/sde2
- 8 82 - /dev/sdf2
root@Wheal-Peevor:~# mdadm --examine /dev/sd[bcef]2
/dev/sdb2:
Magic : a92b4efc
Version : 0.90.00
UUID : 81186e3e:7abdbb10:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Creation Time : Sun Jan 9 14:02:38 2011
Raid Level : raid6
Used Dev Size : 1932542912 (1843.02 GiB 1978.92 GB)
Array Size : 5797628736 (5529.05 GiB 5936.77 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 126
Update Time : Sun Mar 13 10:54:22 2016
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Checksum : 61abf5fc - correct
Events : 2615946
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 0 8 18 0 active sync /dev/sdb2
0 0 8 18 0 active sync /dev/sdb2
1 1 8 34 1 active sync /dev/sdc2
2 2 0 0 2 faulty removed
3 3 8 66 3 active sync /dev/sde2
4 4 8 82 4 active sync /dev/sdf2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 81186e3e:7abdbb10:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Creation Time : Sun Jan 9 14:02:38 2011
Raid Level : raid6
Used Dev Size : 1932542912 (1843.02 GiB 1978.92 GB)
Array Size : 5797628736 (5529.05 GiB 5936.77 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 126
Update Time : Sun Mar 13 10:54:22 2016
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Checksum : 61abf60e - correct
Events : 2615946
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 1 8 34 1 active sync /dev/sdc2
0 0 8 18 0 active sync /dev/sdb2
1 1 8 34 1 active sync /dev/sdc2
2 2 0 0 2 faulty removed
3 3 8 66 3 active sync /dev/sde2
4 4 8 82 4 active sync /dev/sdf2
/dev/sde2:
Magic : a92b4efc
Version : 0.90.00
UUID : 81186e3e:7abdbb10:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Creation Time : Sun Jan 9 14:02:38 2011
Raid Level : raid6
Used Dev Size : 1932542912 (1843.02 GiB 1978.92 GB)
Array Size : 5797628736 (5529.05 GiB 5936.77 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 126
Update Time : Sun Mar 13 10:54:22 2016
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Checksum : 61abf632 - correct
Events : 2615946
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 3 8 66 3 active sync /dev/sde2
0 0 8 18 0 active sync /dev/sdb2
1 1 8 34 1 active sync /dev/sdc2
2 2 0 0 2 faulty removed
3 3 8 66 3 active sync /dev/sde2
4 4 8 82 4 active sync /dev/sdf2
/dev/sdf2:
Magic : a92b4efc
Version : 0.90.00
UUID : 81186e3e:7abdbb10:e9ca3044:bb7815cf (local to host
Wheal-Peevor)
Creation Time : Sun Jan 9 14:02:38 2011
Raid Level : raid6
Used Dev Size : 1932542912 (1843.02 GiB 1978.92 GB)
Array Size : 5797628736 (5529.05 GiB 5936.77 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 126
Update Time : Sun Mar 13 10:54:22 2016
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Checksum : 61abf644 - correct
Events : 2615946
Layout : left-symmetric
Chunk Size : 64K
Number Major Minor RaidDevice State
this 4 8 82 4 active sync /dev/sdf2
0 0 8 18 0 active sync /dev/sdb2
1 1 8 34 1 active sync /dev/sdc2
2 2 0 0 2 faulty removed
3 3 8 66 3 active sync /dev/sde2
4 4 8 82 4 active sync /dev/sdf2
^ permalink raw reply
* Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes
From: Eric W. Biederman @ 2016-03-30 20:18 UTC (permalink / raw)
To: Seth Forshee
Cc: Alexander Viro, Serge Hallyn, Richard Weinberger,
Austin S Hemmelgarn, Miklos Szeredi, linux-kernel, linux-bcache,
dm-devel, linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux
In-Reply-To: <20160330145820.GA41461@ubuntu-hedt>
Seth Forshee <seth.forshee@canonical.com> writes:
> On Tue, Mar 29, 2016 at 08:36:09PM -0500, Eric W. Biederman wrote:
>> Seth Forshee <seth.forshee@canonical.com> writes:
>>
>> > On Fri, Mar 04, 2016 at 04:43:06PM -0600, Eric W. Biederman wrote:
>> >> In general this is only an issue if uids and gids on the filesystem
>> >> do not map into the user namespace.
>> >>
>> >> Therefore the general fix is to limit the logic of checking for
>> >> capabilities in s_user_ns if we are dealing with INVALID_UID and
>> >> INVALID_GID. For proc and kernfs that should never be the case
>> >> so the problem becomes a non-issue.
>> >>
>> >> Further I would look at limiting that relaxation to just
>> >> inode_change_ok.
>> >
>> > Finally got around to implementing this today; is the patch below what
>> > you had in mind?
>>
>> Pretty much.
>>
>> For the same reason that capble_wrt_inode_uidgid(inode) had to look
>> at both inode->i_uid and inode->i_gid I think we need to look at
>> both inode->i_uid and inode->i_gid in those case.
>>
>> I am worried about chgrp_ok in cases such as inode->i_uid is valid
>> but unmapped. I have a similiar worry about chown_ok where
>> inode->i_gid is valid but unmapped (although that worry is less
>> serious).
>
> That makes sense.
>
> So then what is wanted is to check that the other id is either invalid,
> or else it maps into s_user_ns. So for chown_ok() something like this:
>
> if (!uid_valid(inode->i_uid) &&
> (!gid_valid(inode->i_gid) || kgid_has_mapping(inode->i_sb->s_user_ns, inode->i_gid)) &&
> ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
> return true;
>
> and likewise for chgrp_ok(). Does that satisfy your concerns?
Yes it does.
Eric
^ permalink raw reply
* [PATCH] Consistent use of IEC 80000-13 prefix in manpage
From: Marko Hauptvogel @ 2016-03-30 19:48 UTC (permalink / raw)
To: linux-raid
From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Added the optional K suffix for completeness, as it
is allowed by util.c's parse_size(char*).
Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
---
mdadm.8.in | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/mdadm.8.in b/mdadm.8.in
index 50be1aa..80b0826 100644
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -467,8 +467,8 @@ If this is not specified
size, though if there is a variance among the drives of greater than
1%, a warning is
issued.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
-Gigabytes respectively.
+A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
Mebibytes or
+Gibibytes respectively.
Sometimes a replacement drive can be a little smaller than the
original drives though this should be minimised by IDEMA standards.
@@ -534,8 +534,8 @@ problems the array can be made bigger again with no
loss with another
.B "\-\-grow \-\-array\-size="
command.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
-Gigabytes respectively.
+A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
Mebibytes or
+Gibibytes respectively.
A value of
.B max
restores the apparent size of the array to be whatever the real
@@ -551,8 +551,8 @@ This is only meaningful for RAID0, RAID4, RAID5,
RAID6, and RAID10.
RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power
of 2. In any case it must be a multiple of 4KB.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
-Gigabytes respectively.
+A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
Mebibytes or
+Gibibytes respectively.
.TP
.BR \-\-rounding=
@@ -729,7 +729,7 @@ beneficial. This can be suppressed with
.TP
.BR \-\-bitmap\-chunk=
Set the chunksize of the bitmap. Each bit corresponds to that many
-Kilobytes of storage.
+Kibibytes of storage.
When using a file based bitmap, the default is to use the smallest
size that is at-least 4 and requires no more than 2^21 chunks.
When using an
@@ -737,8 +737,8 @@ When using an
bitmap, the chunksize defaults to 64Meg, or larger if necessary to
fit the bitmap into the available space.
-A suffix of 'M' or 'G' can be given to indicate Megabytes or
-Gigabytes respectively.
+A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
Mebibytes or
+Gibibytes respectively.
.TP
.BR \-W ", " \-\-write\-mostly
@@ -808,7 +808,8 @@ an array which was originally created using a
different version of
which computed a different offset.
Setting the offset explicitly over-rides the default. The value given
-is in Kilobytes unless an 'M' or 'G' suffix is given.
+is in Kibibytes unless a suffix of 'K', 'M' or 'G' is given to indicate
+Kibibytes, Mebibytes or Gibibytes respectively.
Since Linux 3.4,
.B \-\-data\-offset
--
2.7.4
^ permalink raw reply related
* md raid sync and ext3 formatting on xen hvm guest causing kernel crash and device offline
From: Anugraha Sinha @ 2016-03-30 18:11 UTC (permalink / raw)
To: neilb, philip; +Cc: linux-raid
Hi Phil,
This problem is related to mirror raid resyncing when doing installation
through anaconda of CentOS 6.6 systems as a xen hvm guest.
Base xen system - xen kernel version - 4.1.18-1.el6xen.x86_64
Guest System - CentOS 6.6 - kernel version - 2.6.32-504.16.2.el6
Drive exposed on host system, for hvm guest = /dev/sdb - 2TB
partitioned as
/dev/sdb1 - primary - 1024MB - 262144MB = 256GB
/dev/sdb2 - primary - 262144MB - 524288MB = 256GB
/dev/sdb3 - primary - 524288MB - 786432MB = 256GB
/dev/sda4 - extended - 786432MB - (-1)
/dev/sda5 - logical - 786432MB - 1048576MB = 256GB
/dev/sda6 - logical - 1048576MB - (-1)
The above partition layout was exposed to hvm guest as follows
-------------------
builder = "hvm"
name = "centos_md_sync"
memory = 2048
vcpus = 4
vif = ['bridge=xenbr0']
disk =
['phy:/dev/sdb1,sda,w','phy:/dev/sdb2,sdb,w','phy:/dev/sdb3,sdc,w','phy:/dev/sdb5,sdd,w']
vnc = 1
boot="c"
---------------------
When anaconda installation started, I partitioned drives mentioned above
as follows
Host System -> Guest System -> Partition layout
/dev/sdb1 -> /dev/sda -> /dev/sda1, /dev/sda2 ..... /dev/sda12
/dev/sdb2 -> /dev/sdb -> /dev/sdb1, /dev/sdb2 ..... /dev/sdb12
/dev/sdb3 -> /dev/sdc -> /dev/sdc1, /dev/sdc2 ..... /dev/sdc12
/dev/sdb5 -> /dev/sdd -> /dev/sdd1, /dev/sdd2 ..... /dev/sdd12
Now in the HVM guest OS we doing RAID 1 mirroring as follows (done
during installation itself, from anaconda)
/dev/sd[ab]1 = /dev/md0
/dev/sd[ab]2 = /dev/md1
|.
|.
|.
/dev/sd[cd]1 = /dev/mdX
/dev/sd[cd]2 = /dev/mdY ....etc.
Now these md(s) get created properly, and as soon as the creation ends,
resyncing starts. Now when /dev/md0 is resyncing, other partitions on
/dev/sda & /dev/sdb go in DELAYED state, that is expected, I understand.
Similarly with /dev/sdc and /dev/sdd. However after sometime, the
/dev/sd[abcd] drives start to go offline and eventually kernel crashes.
I checked /sys/block/sda/device/state information on Guest OS while the
installation was going on, and it says "offline"
I picked up some snapshots and they are kept here:
https://drive.google.com/folderview?id=0B3b5lkAlTOf9eGVFUTVOeWxoTms&usp=sharing
Some important points,
1. I installed a Linux CentOS 6.6, without having these SW RAID
partitions being created from within anaconda.
2. When the Guest System came up, I created md raids from within a
running system, and similar issue were seen. The problem was same as to
what happened during installation, devices went offline, and then kernel
crashed.
Everytime, a RAID1 sync starts for a large drive in Guest OS
(say > 20GB), after sometime, devices start to go offline and then
kernel crashes. Whether during installation or else otherwise as well.
Could you please help in this.
If you want some more snapshots or error messages do let me know.
Regards
Anugraha Sinha
^ permalink raw reply
* Re: Unable to handle kernel NULL pointer dereference in super_written
From: Shaohua Li @ 2016-03-30 17:27 UTC (permalink / raw)
To: Xiao Ni, Shaohua Li; +Cc: linux-raid, Jes Sorensen, Neil Brown
In-Reply-To: <2075551491.35783408.1459323893191.JavaMail.zimbra@redhat.com>
On 03/30/2016 12:44 AM, Xiao Ni wrote:
>
> ----- Original Message -----
>> From: "Shaohua Li" <shli@kernel.org>
>> To: "Xiao Ni" <xni@redhat.com>
>> Cc: "linux-raid" <linux-raid@vger.kernel.org>, "Jes Sorensen" <Jes.Sorensen@redhat.com>, "Neil Brown" <neilb@suse.de>
>> Sent: Wednesday, March 30, 2016 5:37:31 AM
>> Subject: Re: Unable to handle kernel NULL pointer dereference in super_written
>>
>> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
>>> Hi all
>>>
>>> I encountered one NULL pointer dereference problem.
>>>
>>> The environment：
>>> latest linux-stable and mdadm codes
>>> aarch64 platform
>>> the md device is created with loop devices
>>>
>>> It's a test case to check date integrity. I added the test script as the
>>> attachment.
>> Could you please try this patch:
> Thanks for the patch, I'm running test and will give the result. It need to run
> more than 300 iterations to reproduce this.
>
>>
>> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
>> Message-Id:
>> <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
>> From: Shaohua Li <shli@fb.com>
>> Date: Tue, 29 Mar 2016 14:00:19 -0700
>> Subject: [PATCH] MD: add rdev reference for super write
>>
>> md_super_write() and corresponding md_super_wait() generally are called
>> with reconfig_mutex locked, which prevents disk disappears. There is one
>> case this rule is broken. write_sb_page of bitmap.c doesn't hold the
>> mutex. next_active_rdev does increase rdev reference, but it decreases
>> the reference too early (eg, before IO finish). disk can disappear at
>> the window. We unconditionally increase rdev reference in
>> md_super_write() to avoid the race.
> In the path hot_remove_disk, the write_sb_page is protected by reconfig_mutex.
> It shouldn't submit bio to the leg which is already set FAULTY. Could you give
> an example to show how the buy happen?
Not sure if I understand your question correctly, but I try to answer.
When a disk is reported faulty with md_error we don't immediately remove
the disk as there is risk for example some IO is running in the rdev. We
increase rdev reference in every IO and decrease the reference after IO
finishes. You can find this in raid5.c for example. We only delete the
rdev after the reference is 0, please see remove_and_add_spares(). So
it's possible you will find disk with FAULTY set, but it's still in rdev
list.
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: Unable to handle kernel NULL pointer dereference in super_written
From: Shaohua Li @ 2016-03-30 17:16 UTC (permalink / raw)
To: Guoqing Jiang, Shaohua Li, Xiao Ni; +Cc: linux-raid, Jes.Sorensen, Neil Brown
In-Reply-To: <56FB3B2A.9030405@suse.com>
On 03/29/2016 07:34 PM, Guoqing Jiang wrote:
>
>
> On 03/30/2016 05:37 AM, Shaohua Li wrote:
>> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
>>> Hi all
>>>
>>> I encountered one NULL pointer dereference problem.
>>>
>>> The environment：
>>> latest linux-stable and mdadm codes
>>> aarch64 platform
>>> the md device is created with loop devices
>>>
>>> It's a test case to check date integrity. I added the test script as
>>> the attachment.
>> Could you please try this patch:
>>
>>
>> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
>> Message-Id:
>> <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
>> From: Shaohua Li <shli@fb.com>
>> Date: Tue, 29 Mar 2016 14:00:19 -0700
>> Subject: [PATCH] MD: add rdev reference for super write
>>
>> md_super_write() and corresponding md_super_wait() generally are called
>> with reconfig_mutex locked, which prevents disk disappears.
>
> Just for curious, I find several paths maybe also don't hold
> reconfig_mutex,
> take the followings as example.
>
> 1. md_run -> md_update_sb -> md_super_write/md_super_wait
> 2. rdev_size_store -> rdev_size_change -> md_super_write/md_super_wait
we do mddev_lock/unlock calling these. The rdev_size_sotre is a bit
tricky. the lock is hold in rdev_attr_store
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: [PATCH] Introduce stat2kname() and fd2kname()
From: Jes Sorensen @ 2016-03-30 15:26 UTC (permalink / raw)
To: Artur Paszkiewicz; +Cc: linux-raid
In-Reply-To: <1459257629-22027-1-git-send-email-artur.paszkiewicz@intel.com>
Artur Paszkiewicz <artur.paszkiewicz@intel.com> writes:
> These are similar to stat2devnm() and fd2devnm() but not limited to md
> devices. If the device is a partition they will return its kernel name,
> not the whole device's name. For more information see commit:
> 8d83493 ("Introduce devid2kname - slightly different to devid2devnm.")
>
> Also remove unsued declaration for fmt_devname().
>
> Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> ---
> lib.c | 15 +++++++++++++++
> mdadm.h | 3 ++-
> super-intel.c | 6 +++++-
> 3 files changed, 22 insertions(+), 2 deletions(-)
Applied, thanks!
Jes
^ permalink raw reply
* Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes
From: Seth Forshee @ 2016-03-30 14:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Alexander Viro, Serge Hallyn, Richard Weinberger,
Austin S Hemmelgarn, Miklos Szeredi, linux-kernel, linux-bcache,
dm-devel, linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux
In-Reply-To: <87twjoiw6u.fsf@x220.int.ebiederm.org>
On Tue, Mar 29, 2016 at 08:36:09PM -0500, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@canonical.com> writes:
>
> > On Fri, Mar 04, 2016 at 04:43:06PM -0600, Eric W. Biederman wrote:
> >> In general this is only an issue if uids and gids on the filesystem
> >> do not map into the user namespace.
> >>
> >> Therefore the general fix is to limit the logic of checking for
> >> capabilities in s_user_ns if we are dealing with INVALID_UID and
> >> INVALID_GID. For proc and kernfs that should never be the case
> >> so the problem becomes a non-issue.
> >>
> >> Further I would look at limiting that relaxation to just
> >> inode_change_ok.
> >
> > Finally got around to implementing this today; is the patch below what
> > you had in mind?
>
> Pretty much.
>
> For the same reason that capble_wrt_inode_uidgid(inode) had to look
> at both inode->i_uid and inode->i_gid I think we need to look at
> both inode->i_uid and inode->i_gid in those case.
>
> I am worried about chgrp_ok in cases such as inode->i_uid is valid
> but unmapped. I have a similiar worry about chown_ok where
> inode->i_gid is valid but unmapped (although that worry is less
> serious).
That makes sense.
So then what is wanted is to check that the other id is either invalid,
or else it maps into s_user_ns. So for chown_ok() something like this:
if (!uid_valid(inode->i_uid) &&
(!gid_valid(inode->i_gid) || kgid_has_mapping(inode->i_sb->s_user_ns, inode->i_gid)) &&
ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
return true;
and likewise for chgrp_ok(). Does that satisfy your concerns?
> >> So that we can easily wrap that check per filesystem
> >> and deny the relaxation for proc and kernfs. proc and kernfs already
> >> have wrappers for .setattr so denying changes when !uid_vaid and
> >> !gid_valid would be a trivial addition, and ensure calamity does
> >> not ensure.
> >
> > I'm confused about this part though. As you say above, proc and kernfs
> > will never have inodes with invalid ids, so it's not an issue. Do you
> > just mean this to be extra insurance against problems?
>
> I meant two things.
> 1) As filesystems explicitly have to call inode_change_ok they can
> over ride the default if it is possible.
>
> 2) Because being paranoid about backward compatibility matters, it
> almost certainly workth add adding a check:
> "if (!uid_valid(inode->i_uid) ||!gid_valid(inode->i_gid)) return -EPERM"
> To proc and sysfs just before they call inode_change_ok just so we
> don't need to analyze them and confirm that they don't use
> INVALID_UID.
>
> That just makes the patch more robust.
>
> The we could leave removing that code for a follow on patch where
> someone takes the time to read through and audit all of the proc and
> sysfs code to ensure that the case does not arise, instead of just
> implicitily assuming it.
>
> That is the usual pattern when pushing down changes. Do something
> that is easily guaranteed to work, and leave the careful looking for
> a patch all of it's own.
Okay, I'll add checks.
Thanks,
Seth
^ permalink raw reply
* Re: Unable to handle kernel NULL pointer dereference in super_written
From: Xiao Ni @ 2016-03-30 7:44 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid, Jes Sorensen, Neil Brown
In-Reply-To: <20160329213731.GA2287@kernel.org>
----- Original Message -----
> From: "Shaohua Li" <shli@kernel.org>
> To: "Xiao Ni" <xni@redhat.com>
> Cc: "linux-raid" <linux-raid@vger.kernel.org>, "Jes Sorensen" <Jes.Sorensen@redhat.com>, "Neil Brown" <neilb@suse.de>
> Sent: Wednesday, March 30, 2016 5:37:31 AM
> Subject: Re: Unable to handle kernel NULL pointer dereference in super_written
>
> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
> > Hi all
> >
> > I encountered one NULL pointer dereference problem.
> >
> > The environment：
> > latest linux-stable and mdadm codes
> > aarch64 platform
> > the md device is created with loop devices
> >
> > It's a test case to check date integrity. I added the test script as the
> > attachment.
>
> Could you please try this patch:
Thanks for the patch, I'm running test and will give the result. It need to run
more than 300 iterations to reproduce this.
>
>
> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
> Message-Id:
> <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
> From: Shaohua Li <shli@fb.com>
> Date: Tue, 29 Mar 2016 14:00:19 -0700
> Subject: [PATCH] MD: add rdev reference for super write
>
> md_super_write() and corresponding md_super_wait() generally are called
> with reconfig_mutex locked, which prevents disk disappears. There is one
> case this rule is broken. write_sb_page of bitmap.c doesn't hold the
> mutex. next_active_rdev does increase rdev reference, but it decreases
> the reference too early (eg, before IO finish). disk can disappear at
> the window. We unconditionally increase rdev reference in
> md_super_write() to avoid the race.
In the path hot_remove_disk, the write_sb_page is protected by reconfig_mutex.
It shouldn't submit bio to the leg which is already set FAULTY. Could you give
an example to show how the buy happen?
Best Regards
Xiao
>
> Reported-by: Xiao Ni <xni@redhat.com>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/md/md.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index c068f17..bcfde333 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -718,6 +718,7 @@ static void super_written(struct bio *bio)
>
> if (atomic_dec_and_test(&mddev->pending_writes))
> wake_up(&mddev->sb_wait);
> + rdev_dec_pending(rdev, mddev);
> bio_put(bio);
> }
>
> @@ -732,6 +733,8 @@ void md_super_write(struct mddev *mddev, struct md_rdev
> *rdev,
> */
> struct bio *bio = bio_alloc_mddev(GFP_NOIO, 1, mddev);
>
> + atomic_inc(&rdev->nr_pending);
> +
> bio->bi_bdev = rdev->meta_bdev ? rdev->meta_bdev : rdev->bdev;
> bio->bi_iter.bi_sector = sector;
> bio_add_page(bio, page, size, 0);
> --
> 2.8.0.rc2
>
> --
> 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
>
--
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: Unable to handle kernel NULL pointer dereference in super_written
From: Guoqing Jiang @ 2016-03-30 2:34 UTC (permalink / raw)
To: Shaohua Li, Xiao Ni; +Cc: linux-raid, Jes.Sorensen, Neil Brown
In-Reply-To: <20160329213731.GA2287@kernel.org>
On 03/30/2016 05:37 AM, Shaohua Li wrote:
> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
>> Hi all
>>
>> I encountered one NULL pointer dereference problem.
>>
>> The environment：
>> latest linux-stable and mdadm codes
>> aarch64 platform
>> the md device is created with loop devices
>>
>> It's a test case to check date integrity. I added the test script as the attachment.
> Could you please try this patch:
>
>
> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
> Message-Id: <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
> From: Shaohua Li <shli@fb.com>
> Date: Tue, 29 Mar 2016 14:00:19 -0700
> Subject: [PATCH] MD: add rdev reference for super write
>
> md_super_write() and corresponding md_super_wait() generally are called
> with reconfig_mutex locked, which prevents disk disappears.
Just for curious, I find several paths maybe also don't hold reconfig_mutex,
take the followings as example.
1. md_run -> md_update_sb -> md_super_write/md_super_wait
2. rdev_size_store -> rdev_size_change -> md_super_write/md_super_wait
Thanks,
Guoqing
> There is one
> case this rule is broken. write_sb_page of bitmap.c doesn't hold the
> mutex. next_active_rdev does increase rdev reference, but it decreases
> the reference too early (eg, before IO finish). disk can disappear at
> the window. We unconditionally increase rdev reference in
> md_super_write() to avoid the race.
>
> Reported-by: Xiao Ni <xni@redhat.com>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/md/md.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index c068f17..bcfde333 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -718,6 +718,7 @@ static void super_written(struct bio *bio)
>
> if (atomic_dec_and_test(&mddev->pending_writes))
> wake_up(&mddev->sb_wait);
> + rdev_dec_pending(rdev, mddev);
> bio_put(bio);
> }
>
> @@ -732,6 +733,8 @@ void md_super_write(struct mddev *mddev, struct md_rdev *rdev,
> */
> struct bio *bio = bio_alloc_mddev(GFP_NOIO, 1, mddev);
>
> + atomic_inc(&rdev->nr_pending);
> +
> bio->bi_bdev = rdev->meta_bdev ? rdev->meta_bdev : rdev->bdev;
> bio->bi_iter.bi_sector = sector;
> bio_add_page(bio, page, size, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND v2 11/18] fs: Ensure the mounter of a filesystem is privileged towards its inodes
From: Eric W. Biederman @ 2016-03-30 1:36 UTC (permalink / raw)
To: Seth Forshee
Cc: Alexander Viro, Serge Hallyn, Richard Weinberger,
Austin S Hemmelgarn, Miklos Szeredi, linux-kernel, linux-bcache,
dm-devel, linux-raid, linux-mtd, linux-fsdevel, fuse-devel,
linux-security-module, selinux
In-Reply-To: <20160328165936.GC137406@ubuntu-hedt>
Seth Forshee <seth.forshee@canonical.com> writes:
> On Fri, Mar 04, 2016 at 04:43:06PM -0600, Eric W. Biederman wrote:
>> In general this is only an issue if uids and gids on the filesystem
>> do not map into the user namespace.
>>
>> Therefore the general fix is to limit the logic of checking for
>> capabilities in s_user_ns if we are dealing with INVALID_UID and
>> INVALID_GID. For proc and kernfs that should never be the case
>> so the problem becomes a non-issue.
>>
>> Further I would look at limiting that relaxation to just
>> inode_change_ok.
>
> Finally got around to implementing this today; is the patch below what
> you had in mind?
Pretty much.
For the same reason that capble_wrt_inode_uidgid(inode) had to look
at both inode->i_uid and inode->i_gid I think we need to look at
both inode->i_uid and inode->i_gid in those case.
I am worried about chgrp_ok in cases such as inode->i_uid is valid
but unmapped. I have a similiar worry about chown_ok where
inode->i_gid is valid but unmapped (although that worry is less
serious).
>> So that we can easily wrap that check per filesystem
>> and deny the relaxation for proc and kernfs. proc and kernfs already
>> have wrappers for .setattr so denying changes when !uid_vaid and
>> !gid_valid would be a trivial addition, and ensure calamity does
>> not ensure.
>
> I'm confused about this part though. As you say above, proc and kernfs
> will never have inodes with invalid ids, so it's not an issue. Do you
> just mean this to be extra insurance against problems?
I meant two things.
1) As filesystems explicitly have to call inode_change_ok they can
over ride the default if it is possible.
2) Because being paranoid about backward compatibility matters, it
almost certainly workth add adding a check:
"if (!uid_valid(inode->i_uid) ||!gid_valid(inode->i_gid)) return -EPERM"
To proc and sysfs just before they call inode_change_ok just so we
don't need to analyze them and confirm that they don't use
INVALID_UID.
That just makes the patch more robust.
The we could leave removing that code for a follow on patch where
someone takes the time to read through and audit all of the proc and
sysfs code to ensure that the case does not arise, instead of just
implicitily assuming it.
That is the usual pattern when pushing down changes. Do something
that is easily guaranteed to work, and leave the careful looking for
a patch all of it's own.
Eric
> Thanks,
> Seth
>
> ---
>
> diff --git a/fs/attr.c b/fs/attr.c
> index 3cfaaac4a18e..f2bcd3f7dfbb 100644
> --- a/fs/attr.c
> +++ b/fs/attr.c
> @@ -16,6 +16,31 @@
> #include <linux/evm.h>
> #include <linux/ima.h>
>
> +static bool chown_ok(const struct inode *inode, kuid_t uid)
> +{
> + if (uid_eq(current_fsuid(), inode->i_uid) && uid_eq(uid, inode->i_uid))
> + return true;
> + if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
> + return true;
> + if (!uid_valid(inode->i_uid) &&
> + ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
> + return true;
> + return false;
> +}
> +
> +static bool chgrp_ok(const struct inode *inode, kgid_t gid)
> +{
> + if (uid_eq(current_fsuid(), inode->i_uid) &&
> + (in_group_p(gid) || gid_eq(gid, inode->i_gid)))
> + return true;
> + if (capable_wrt_inode_uidgid(inode, CAP_CHOWN))
> + return true;
> + if (!gid_valid(inode->i_gid) &&
> + ns_capable(inode->i_sb->s_user_ns, CAP_CHOWN))
> + return true;
> + return false;
> +}
> +
> /**
> * inode_change_ok - check if attribute changes to an inode are allowed
> * @inode: inode to check
> @@ -58,17 +83,11 @@ int inode_change_ok(const struct inode *inode, struct iattr *attr)
> return 0;
>
> /* Make sure a caller can chown. */
> - if ((ia_valid & ATTR_UID) &&
> - (!uid_eq(current_fsuid(), inode->i_uid) ||
> - !uid_eq(attr->ia_uid, inode->i_uid)) &&
> - !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
> + if ((ia_valid & ATTR_UID) && !chown_ok(inode, attr->ia_uid))
> return -EPERM;
>
> /* Make sure caller can chgrp. */
> - if ((ia_valid & ATTR_GID) &&
> - (!uid_eq(current_fsuid(), inode->i_uid) ||
> - (!in_group_p(attr->ia_gid) && !gid_eq(attr->ia_gid, inode->i_gid))) &&
> - !capable_wrt_inode_uidgid(inode, CAP_CHOWN))
> + if ((ia_valid & ATTR_GID) && !chgrp_ok(inode, attr->ia_gid))
> return -EPERM;
>
> /* Make sure a caller can chmod. */
^ permalink raw reply
* Re: Unable to handle kernel NULL pointer dereference in super_written
From: NeilBrown @ 2016-03-29 22:23 UTC (permalink / raw)
To: Shaohua Li, Xiao Ni; +Cc: linux-raid, Jes.Sorensen
In-Reply-To: <20160329213731.GA2287@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]
On Wed, Mar 30 2016, Shaohua Li wrote:
> On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
>> Hi all
>>
>> I encountered one NULL pointer dereference problem.
>>
>> The environment：
>> latest linux-stable and mdadm codes
>> aarch64 platform
>> the md device is created with loop devices
>>
>> It's a test case to check date integrity. I added the test script as the attachment.
>
> Could you please try this patch:
>
>
> From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
> Message-Id: <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
> From: Shaohua Li <shli@fb.com>
> Date: Tue, 29 Mar 2016 14:00:19 -0700
> Subject: [PATCH] MD: add rdev reference for super write
>
> md_super_write() and corresponding md_super_wait() generally are called
> with reconfig_mutex locked, which prevents disk disappears. There is one
> case this rule is broken. write_sb_page of bitmap.c doesn't hold the
> mutex. next_active_rdev does increase rdev reference, but it decreases
> the reference too early (eg, before IO finish). disk can disappear at
> the window. We unconditionally increase rdev reference in
> md_super_write() to avoid the race.
>
Yes, that makes sense. Thanks.
Acked-by: NeilBrown <neilb@suse.com>
> Reported-by: Xiao Ni <xni@redhat.com>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Shaohua Li <shli@fb.com>
> ---
> drivers/md/md.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index c068f17..bcfde333 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -718,6 +718,7 @@ static void super_written(struct bio *bio)
>
> if (atomic_dec_and_test(&mddev->pending_writes))
> wake_up(&mddev->sb_wait);
> + rdev_dec_pending(rdev, mddev);
> bio_put(bio);
> }
>
> @@ -732,6 +733,8 @@ void md_super_write(struct mddev *mddev, struct md_rdev *rdev,
> */
> struct bio *bio = bio_alloc_mddev(GFP_NOIO, 1, mddev);
>
> + atomic_inc(&rdev->nr_pending);
> +
> bio->bi_bdev = rdev->meta_bdev ? rdev->meta_bdev : rdev->bdev;
> bio->bi_iter.bi_sector = sector;
> bio_add_page(bio, page, size, 0);
> --
> 2.8.0.rc2
>
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Unable to handle kernel NULL pointer dereference in super_written
From: Shaohua Li @ 2016-03-29 21:37 UTC (permalink / raw)
To: Xiao Ni; +Cc: linux-raid, Jes.Sorensen, Neil Brown
In-Reply-To: <538658018.35237734.1459254120634.JavaMail.zimbra@redhat.com>
On Tue, Mar 29, 2016 at 08:22:00AM -0400, Xiao Ni wrote:
> Hi all
>
> I encountered one NULL pointer dereference problem.
>
> The environment：
> latest linux-stable and mdadm codes
> aarch64 platform
> the md device is created with loop devices
>
> It's a test case to check date integrity. I added the test script as the attachment.
Could you please try this patch:
From b86d9e1724184c79ad1ea63901aec802492b861c Mon Sep 17 00:00:00 2001
Message-Id: <b86d9e1724184c79ad1ea63901aec802492b861c.1459285706.git.shli@fb.com>
From: Shaohua Li <shli@fb.com>
Date: Tue, 29 Mar 2016 14:00:19 -0700
Subject: [PATCH] MD: add rdev reference for super write
md_super_write() and corresponding md_super_wait() generally are called
with reconfig_mutex locked, which prevents disk disappears. There is one
case this rule is broken. write_sb_page of bitmap.c doesn't hold the
mutex. next_active_rdev does increase rdev reference, but it decreases
the reference too early (eg, before IO finish). disk can disappear at
the window. We unconditionally increase rdev reference in
md_super_write() to avoid the race.
Reported-by: Xiao Ni <xni@redhat.com>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/md.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index c068f17..bcfde333 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -718,6 +718,7 @@ static void super_written(struct bio *bio)
if (atomic_dec_and_test(&mddev->pending_writes))
wake_up(&mddev->sb_wait);
+ rdev_dec_pending(rdev, mddev);
bio_put(bio);
}
@@ -732,6 +733,8 @@ void md_super_write(struct mddev *mddev, struct md_rdev *rdev,
*/
struct bio *bio = bio_alloc_mddev(GFP_NOIO, 1, mddev);
+ atomic_inc(&rdev->nr_pending);
+
bio->bi_bdev = rdev->meta_bdev ? rdev->meta_bdev : rdev->bdev;
bio->bi_iter.bi_sector = sector;
bio_add_page(bio, page, size, 0);
--
2.8.0.rc2
--
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 related
* Re: [PATCH] mdadm:Add '--nodes' option in GROW mode
From: Jes Sorensen @ 2016-03-29 15:43 UTC (permalink / raw)
To: zhilong; +Cc: Guoqing Jiang, linux-raid
In-Reply-To: <56F4A0CB.1040609@suse.com>
zhilong <zlliu@suse.com> writes:
> mdadm:add '--nodes' option in GROW mode, because
> 'Cluster nodes' is set 4 by default if the nodes
> parameter is not specified when switch bitmap
> from none to clustered.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
> ---
> mdadm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mdadm.c b/mdadm.c
> index d2afcb2..58ac32a 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -589,6 +589,7 @@ int main(int argc, char *argv[])
> ident.raid_disks = s.raiddisks;
> continue;
> case O(ASSEMBLE, Nodes):
> + case O(GROW, Nodes):
> case O(CREATE, Nodes):
> c.nodes = parse_num(optarg);
> if (c.nodes <= 0) {
Applied!
Something funny happened to the formatting of your patch. Somehow it
ended up with an additional space at the beginning of each line. Not
sure if it is related to your mail client using format-flowed.
I manually fixed it up, so it's all good.
Thanks,
Jes
^ permalink raw reply
* [PATCH] Introduce stat2kname() and fd2kname()
From: Artur Paszkiewicz @ 2016-03-29 13:20 UTC (permalink / raw)
To: linux-raid; +Cc: Artur Paszkiewicz
These are similar to stat2devnm() and fd2devnm() but not limited to md
devices. If the device is a partition they will return its kernel name,
not the whole device's name. For more information see commit:
8d83493 ("Introduce devid2kname - slightly different to devid2devnm.")
Also remove unsued declaration for fmt_devname().
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
---
lib.c | 15 +++++++++++++++
mdadm.h | 3 ++-
super-intel.c | 6 +++++-
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib.c b/lib.c
index 6808f62..621edf3 100644
--- a/lib.c
+++ b/lib.c
@@ -84,6 +84,21 @@ char *devid2kname(int devid)
return NULL;
}
+char *stat2kname(struct stat *st)
+{
+ if ((S_IFMT & st->st_mode) != S_IFBLK)
+ return NULL;
+ return devid2kname(st->st_rdev);
+}
+
+char *fd2kname(int fd)
+{
+ struct stat stb;
+ if (fstat(fd, &stb) == 0)
+ return stat2kname(&stb);
+ return NULL;
+}
+
char *devid2devnm(int devid)
{
char path[30];
diff --git a/mdadm.h b/mdadm.h
index 3b96076..d209488 100755
--- a/mdadm.h
+++ b/mdadm.h
@@ -1474,7 +1474,8 @@ void abort_reshape(struct mdinfo *sra);
void *super1_make_v0(struct supertype *st, struct mdinfo *info, mdp_super_t *sb0);
-extern void fmt_devname(char *name, int num);
+extern char *stat2kname(struct stat *st);
+extern char *fd2kname(int fd);
extern char *stat2devnm(struct stat *st);
extern char *fd2devnm(int fd);
diff --git a/super-intel.c b/super-intel.c
index f04ac2f..ba3ee48 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -4589,7 +4589,11 @@ static int load_super_imsm(struct supertype *st, int fd, char *devname)
/* retry the load if we might have raced against mdmon */
if (rv == 3) {
- struct mdstat_ent *mdstat = mdstat_by_component(fd2devnm(fd));
+ struct mdstat_ent *mdstat = NULL;
+ char *name = fd2kname(fd);
+
+ if (name)
+ mdstat = mdstat_by_component(name);
if (mdstat && mdmon_running(mdstat->devnm) && getpid() != mdmon_pid(mdstat->devnm)) {
for (retry = 0; retry < 3; retry++) {
--
2.6.2
^ permalink raw reply related
* Unable to handle kernel NULL pointer dereference in super_written
From: Xiao Ni @ 2016-03-29 12:22 UTC (permalink / raw)
To: linux-raid; +Cc: shli, Jes.Sorensen, Neil Brown
In-Reply-To: <678678296.35099303.1459240762496.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 10953 bytes --]
Hi all
I encountered one NULL pointer dereference problem.
The environment：
latest linux-stable and mdadm codes
aarch64 platform
the md device is created with loop devices
It's a test case to check date integrity. I added the test script as the attachment.
[37158.968198] Unable to handle kernel NULL pointer dereference at virtual address 000002a8
[37158.976261] pgd = fffffe0001300000
[37158.979648] [000002a8] *pgd=00000043f9a50003, *pud=00000043f9a50003, *pmd=00000043f9a50003, *pte=00e8000078090707
[37158.989911] Internal error: Oops: 96000006 [#1] SMP
[37158.994766] Modules linked in: ext4 mbcache jbd2 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq md_mod loop vfat fat sg xgene_rng nfsd ip_tables xfs libcrc32c dm_mirror dm_region_hash dm_log dm_mod realtek(E)
[37159.016342] CPU: 0 PID: 1817 Comm: loop0 Tainted: G E 4.5.0 #1
[37159.023271] Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Oct 20 2015
[37159.030548] task: fffffe03dd7db300 ti: fffffe03d5fa4000 task.ti: fffffe03d5fa4000
[37159.038021] PC is at super_written+0x34/0x98 [md_mod]
[37159.043052] LR is at bio_endio+0x90/0xc4
[37159.046956] pc : [<fffffdfffc577984>] lr : [<fffffe0000360890>] pstate: 800001c5
[37159.054319] sp : fffffe03d5fa7b40
[37159.057617] x29: fffffe03d5fa7b40 x28: 0000000000000000
[37159.062924] x27: 0000000000000000 x26: 0000000000000000
[37159.068230] x25: fffffe03d848adf8 x24: 0000000000000000
[37159.073535] x23: 0000000000000000 x22: fffffe03d876ce00
[37159.078841] x21: fffffe00bc3a8c00 x20: fffffe019df0aa00
[37159.084147] x19: 0000000000000000 x18: 000003ffe853c260
[37159.089455] x17: 00000000004f0468 x16: fffffe0000219b20
[37159.094760] x15: 0000000000000000 x14: 0000000000000000
[37159.100066] x13: 0000000000000000 x12: 0000000000000000
[37159.105371] x11: fffffe00007137b8 x10: 0000000000000aa0
[37159.110677] x9 : fffffe03ffe3ca60 x8 : 0000000000000000
[37159.115982] x7 : 00000003ff340000 x6 : 00000000032ff9d8
[37159.121288] x5 : 0000000000000000 x4 : 0000000000000000
[37159.126593] x3 : fffffe0000b43000 x2 : 00000000000002a8
[37159.131899] x1 : 0000000000000000 x0 : fffffe0000360890
[37159.137204]
[37159.138688] Process loop0 (pid: 1817, stack limit = 0xfffffe03d5fa4020)
[37159.145272] Stack: (0xfffffe03d5fa7b40 to 0xfffffe03d5fa8000)
[37159.150991] 7b40: fffffe03d5fa7b70 fffffe0000360890 fffffe019df0aa00 fffffe00003608c4
[37159.158788] 7b60: 0000000000000000 dead000000000200 fffffe03d5fa7ba0 fffffe0000367c8c
[37159.166584] 7b80: fffffe019df0aa00 0000000000000000 0000000000000000 fffffe03d876ce00
[37159.174379] 7ba0: fffffe03d5fa7be0 fffffe00003715dc fffffe03d876ce00 0000000000000000
[37159.182174] 7bc0: fffffe00bc801200 0000000000000000 fffffdfffc533690 0000000000000140
[37159.189969] 7be0: fffffe03d5fa7c00 fffffe000036b5a4 fffffe03d876ce00 fffffe03d848ae80
[37159.197764] 7c00: fffffe03d5fa7c50 fffffe000036b960 fffffe03d848ae80 fffffe03d848aea0
[37159.205559] 7c20: 0000000000000001 0000000000000000 fffffe00bc801200 0000000000000140
[37159.213354] 7c40: fffffe03d848ae80 0000000000000004 fffffe03d5fa7ca0 fffffe0000371600
[37159.221148] 7c60: fffffe03dc904000 0000000000000000 fffffe03d5fa4000 0000000000000001
[37159.228945] 7c80: fffffe00be386f50 fffffe00011a4ff0 0000000000000000 0000000000000000
[37159.236739] 7ca0: fffffe03d5fa7cc0 fffffe0000371800 fffffe03dc904000 0000000000000000
[37159.244534] 7cc0: fffffe03d5fa7cf0 fffffe0000371848 fffffe03dc904000 0000000000000000
[37159.252330] 7ce0: fffffe03d5fa4000 fffffdfffc532948 fffffe03d5fa7d10 fffffdfffc532740
[37159.260125] 7d00: fffffe00be386e00 0000000000000000 fffffe03d5fa7df0 fffffe00000d4f78
[37159.267921] 7d20: fffffe00011a4000 fffffe00be386f48 fffffe03d5fa4000 0000000000000001
[37159.275717] 7d40: fffffe00be386f50 fffffe00011a4ff0 0000000000000000 0000000000000000
[37159.283513] 7d60: 0000000000000000 0000000000000000 fffffe03d5fa7dc0 fffffe03dc904170
[37159.291308] 7d80: fffffe03dc904000 fffffe00be386f48 fffffe03d5fa4000 0000000000000001
[37159.299104] 7da0: fffffe00be386f50 fffffe00011a4ff0 0000000000000000 0000000000000000
[37159.306900] 7dc0: fffffe03d5fa7de0 fffffe00006f64f0 fffffe03d5fa7df0 fffffe00000d4fb4
[37159.314695] 7de0: fffffe03d5fa7df0 fffffe00000d4fcc fffffe03d5fa7e30 fffffe00000d4f00
[37159.322491] 7e00: fffffe03d848c100 fffffe0001111e68 fffffe0000915ff8 fffffe00be386f48
[37159.330286] 7e20: fffffe00000d4f14 0000000000000000 0000000000000000 fffffe00000859c0
[37159.338082] 7e40: fffffe00000d4e24 fffffe03d848c100 0000000000000000 0000000000000000
[37159.345876] 7e60: 0000000000000000 fffffe00000e1b28 fffffe03dc0ecb00 0000000000000000
[37159.353673] 7e80: 0000000000000000 fffffe00be386f48 0000000000000000 0000000000000000
[37159.361469] 7ea0: fffffe03d5fa7ea0 fffffe03d5fa7ea0 0000000000000000 fffffe0000000000
[37159.369263] 7ec0: fffffe03d5fa7ec0 fffffe03d5fa7ec0 0000000000000000 0000000000000000
[37159.377059] 7ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.384855] 7f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.392651] 7f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.400446] 7f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.408240] 7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.416035] 7f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.423831] 7fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.431625] 7fc0: 0000000000000000 0000000000000000 0000000000000000 0000000000000005
[37159.439420] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.447214] Call trace:
[37159.449649] Exception stack(0xfffffe03d5fa7980 to 0xfffffe03d5fa7aa0)
[37159.456059] 7980: 0000000000000000 fffffe019df0aa00 fffffe03d5fa7b40 fffffdfffc577984
[37159.463854] 79a0: fffffe0000b43000 fffffe03ffe39400 fffffe03d5fa7a00 fffffe00006f6254
[37159.471648] 79c0: fffffe03d5fa4000 fffffe00006f5b20 7fffffffffffffff 0000000000000002
[37159.479445] 79e0: fffffe03d5fa4000 fffffe03d5fa7b48 7fffffffffffffff 0000000000000000
[37159.487240] 7a00: fffffe03d5fa7a20 fffffe00006f8ca4 fffffe03ffe39400 00000000fffffffb
[37159.495034] 7a20: fffffe0000360890 0000000000000000 00000000000002a8 fffffe0000b43000
[37159.502830] 7a40: 0000000000000000 0000000000000000 00000000032ff9d8 00000003ff340000
[37159.510625] 7a60: 0000000000000000 fffffe03ffe3ca60 0000000000000aa0 fffffe00007137b8
[37159.518421] 7a80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[37159.526237] [<fffffdfffc577984>] super_written+0x34/0x98 [md_mod]
[37159.532302] [<fffffe0000360890>] bio_endio+0x90/0xc4
[37159.537246] [<fffffe0000367c8c>] blk_update_request+0xb8/0x34c
[37159.543053] [<fffffe00003715dc>] blk_mq_end_request+0x2c/0x84
[37159.548773] [<fffffe000036b5a4>] blk_flush_complete_seq+0x1ac/0x308
[37159.555011] [<fffffe000036b960>] flush_end_io+0x124/0x1c8
[37159.560384] [<fffffe0000371600>] blk_mq_end_request+0x50/0x84
[37159.566104] [<fffffe0000371800>] __blk_mq_complete_request+0x108/0x118
[37159.572601] [<fffffe0000371848>] blk_mq_complete_request+0x38/0x44
[37159.578755] [<fffffdfffc532740>] loop_queue_work+0x368/0x870 [loop]
[37159.584995] [<fffffe00000d4f78>] kthread_worker_fn+0x64/0x160
[37159.590714] [<fffffe00000d4f00>] kthread+0xdc/0xf0
[37159.595483] [<fffffe00000859c0>] ret_from_fork+0x10/0x50
[37159.600771] Code: f9400eb3 35000281 910aa262 f9800051 (885f7c40)
I added BUG_ON(rdev->mddev == NULL) in super_write and super_written.
Panic happened in super_written :
[ 4829.714552] md: export_rdev(loop0)
[ 4829.850794] ------------[ cut here ]------------
[ 4829.855396] kernel BUG at /root/md/md.c:713!
708 static void super_written(struct bio *bio)
709 {
710 struct md_rdev *rdev = bio->bi_private;
711 struct mddev *mddev = rdev->mddev;
712
713 BUG_ON(rdev->mddev == NULL);
I tried this on x86_64 too, it gave another calltrace:
[26396.335146] BUG: unable to handle kernel NULL pointer dereference at 00000000000002a8
[26396.342990] IP: [<ffffffffa0425b00>] super_written+0x20/0x80 [md_mod]
[26396.349449] PGD 0
[26396.351468] Oops: 0002 [#1] SMP
[26396.354898] Modules linked in: ext4 mbcache jbd2 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_td
[26396.408404] CPU: 5 PID: 3261 Comm: loop0 Not tainted 4.5.0 #1
[26396.414140] Hardware name: Dell Inc. PowerEdge R715/0G2DP3, BIOS 3.2.2 09/15/2014
[26396.421608] task: ffff8808339be680 ti: ffff8808365f4000 task.ti: ffff8808365f4000
[26396.429074] RIP: 0010:[<ffffffffa0425b00>] [<ffffffffa0425b00>] super_written+0x20/0x80 [md_mod]
[26396.437952] RSP: 0018:ffff8808365f7c38 EFLAGS: 00010046
[26396.443252] RAX: ffffffffa0425ae0 RBX: ffff8804336a7900 RCX: ffffe8f9f7b41198
[26396.450371] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8804336a7900
[26396.457489] RBP: ffff8808365f7c50 R08: 0000000000000005 R09: 00001801e02ce3d7
[26396.464608] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
[26396.471728] R13: ffff8808338d9a00 R14: 0000000000000000 R15: ffff880833f9fe00
[26396.478849] FS: 00007f9e5066d740(0000) GS:ffff880237b40000(0000) knlGS:0000000000000000
[26396.486922] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[26396.492656] CR2: 00000000000002a8 CR3: 00000000019ea000 CR4: 00000000000006e0
[26396.499775] Stack:
[26396.501781] ffff8804336a7900 0000000000000000 0000000000000000 ffff8808365f7c68
[26396.509199] ffffffff81308cd0 ffff8804336a7900 ffff8808365f7ca8 ffffffff81310637
[26396.516618] 00000000a0233a00 ffff880833f9fe00 0000000000000000 ffff880833fb0000
[26396.524038] Call Trace:
[26396.526485] [<ffffffff81308cd0>] bio_endio+0x40/0x60
[26396.531529] [<ffffffff81310637>] blk_update_request+0x87/0x320
[26396.537439] [<ffffffff8131a20a>] blk_mq_end_request+0x1a/0x70
[26396.543261] [<ffffffff81313889>] blk_flush_complete_seq+0xd9/0x2a0
[26396.549517] [<ffffffff81313ccf>] flush_end_io+0x15f/0x240
[26396.554993] [<ffffffff8131a22a>] blk_mq_end_request+0x3a/0x70
[26396.560815] [<ffffffff8131a314>] __blk_mq_complete_request+0xb4/0xe0
[26396.567246] [<ffffffff8131a35c>] blk_mq_complete_request+0x1c/0x20
[26396.573506] [<ffffffffa04182df>] loop_queue_work+0x6f/0x72c [loop]
[26396.579764] [<ffffffff81697844>] ? __schedule+0x2b4/0x8f0
[26396.585242] [<ffffffff810a7812>] kthread_worker_fn+0x52/0x170
[26396.591065] [<ffffffff810a77c0>] ? kthread_create_on_node+0x1a0/0x1a0
[26396.597582] [<ffffffff810a7238>] kthread+0xd8/0xf0
[26396.602453] [<ffffffff810a7160>] ? kthread_park+0x60/0x60
[26396.607929] [<ffffffff8169bdcf>] ret_from_fork+0x3f/0x70
[26396.613319] [<ffffffff810a7160>] ? kthread_park+0x60/0x60
Best Regards
Xiao
[-- Attachment #2: test.sh --]
[-- Type: application/x-shellscript, Size: 2240 bytes --]
^ permalink raw reply
* Re: Probable bug in md with rdev->new_data_offset
From: Étienne Buira @ 2016-03-29 11:07 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <56F92140.6080801@turmel.org>
Sorry, forgot to reply to list as well, resending for completeness.
On Mon, Mar 28, 2016 at 08:19:12AM -0400, Phil Turmel wrote:
> On 03/28/2016 06:31 AM, Étienne Buira wrote:
../..
> > After printking the values for rdev->new_data_offset and
> > rdev->data_offset in the
> > if (rdev->new_data_offset != rdev->data_offset) { ...
> > block of super_1_sync, i found that new_data_offset (252928 in my case)
> > where smaller than data_offset (258048), thus, the substraction to
> > compute sb->new_data_offset yielded an insanely high value.
>
> Modern mdadm and kernels avoid the use of backup files by adjusting the
> data offset. The lowered offset you see is normal.
>
> I suspect the grsecurity kernels haven't kept up with this. If you can
> reproduce a problem with a vanilla kernel, please report back here.
> Otherwise you'll have to report to your kernel provider.
>
> Phil
Hi,
Thank you for the answer.
I tried to reproduce the case with vanilla 4.4.6, but couldn't enter the
above said 'if', so i'm giving up on this topic.
However, i'm still surprised that sb->new_offset gets assigned a
'negative' (well, high, because it is computed unsigned) value.
Regards.
--
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: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
From: Ming Lei @ 2016-03-29 1:28 UTC (permalink / raw)
To: Shaohua Li
Cc: Sebastian Roesner, Eric Wheeler, linux-bcache, linux-raid,
Ming Lin, Vlad-Cosmin Miu, rjones, Kent Overstreet, Jeff Moyer,
Jens Axboe
In-Reply-To: <20160328181059.GA83819@kernel.org>
On Tue, Mar 29, 2016 at 2:10 AM, Shaohua Li <shli@kernel.org> wrote:
> On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote:
>> Hello Ming, Eric,
>>
>> Am 26.03.2016 um 16:40 schrieb Ming Lei:
>> > From the trace, looks the bio returned from bio_clone_mddev() is NULL,
>> >and maybe the source bio is buggy, something like the attached patch
>> >might be helpful, could you apply the attached debug patch, reproduce
>> >and post the log?
>>
>> I was able to reproduce it on a non-productive system, but only after
>> copying the bcache superblocks/partition starts from the original system,
>> with new created ones it worked fine.
>>
>> Full trace and check_bio output can be found here:
>>
>> http://pastebin.com/ngvGGHBZ
>
> 320 bvecs exceeds what bio-clone_set can handle. Could you please try below patch?
>
The source bio is still a cloned bio which includes 320 bvecs, which is weried.
And I guess bio_add_page() isn't used for the initial source bio from bcache.
From the stack trace, looks it is related with prio_io(), which just
sets bio size as
the bucket size, so could you check what the bucket size is about your
bcache device via bcache-super-show or sysfs?
If the bucket size is (320 * 4K), looks we should limit the queue's max
sector as 1MB.
BTW, in my bcache block, the bucket size is 512K, and I can't reproduce
the issue, and it is stored in superblock.
> commit 92761dad7ff6e1bf25de247e0064dd398e797599
> Author: Shaohua Li <shli@fb.com>
> Date: Mon Mar 28 10:54:35 2016 -0700
>
> block: don't make BLK_DEF_MAX_SECTORS too big
>
> bio_alloc_bioset() allocates bvecs from bvec_slabs which can only allocate
> maximum 256 bvec (eg, 1M for 4k pages). We can't bump BLK_DEF_MAX_SECTORS to
> exceed this value otherwise bio_alloc_bioset will fail.
>
> This fixes commit 30e2bc08b2bb7c069. We probably should make the bvec_slabs
> hold bigger bvecs if bigger bio size is required.
>
> Signed-off-by: Shaohua Li <shli@fb.com>
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 7e5d7e0..da64325 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
> enum blk_default_limits {
> BLK_MAX_SEGMENTS = 128,
> BLK_SAFE_MAX_SECTORS = 255,
> - BLK_DEF_MAX_SECTORS = 2560,
> + /*
> + * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
> + * Otherwise bio_alloc_bioset will break.
> + */
> + BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> BLK_MAX_SEGMENT_SIZE = 65536,
> BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
> };
This change should work.
But, when multipage bvecs is ready, I think the above limit can be increased
too. I suggest to use (BIO_MAX_PAGES << (PAGE_SHIFT - 9)) instead of
BIO_MAX_SECTORS, which is removed in my following patch and there is
only one user of this macro:
http://marc.info/?l=linux-kernel&m=145862727620599&w=2
Thanks,
Ming
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Wols Lists @ 2016-03-28 21:03 UTC (permalink / raw)
Cc: Linux Raid
In-Reply-To: <22265.36590.539103.542573@quad.stoffel.home>
On 28/03/16 21:07, John Stoffel wrote:
> You do want to test booting from a broken RAID1 boot device. When I
> recently did my big re-org, I found that to make it boot I had to move
> the working boot drive to the non-working slot, since of course the
> failed one was effectively /dev/first-drive and that's how grub needed
> to boot.
Your setup regime really should check that you install grub on ALL your
drives. Easier said than done though when adding new drives ... :-)
Cheers,
Wol
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: John Stoffel @ 2016-03-28 20:07 UTC (permalink / raw)
To: Ram Ramesh; +Cc: John Stoffel, Linux Raid
In-Reply-To: <56F98958.3020704@gmail.com>
>>>>> "Ram" == Ram Ramesh <rramesh2400@gmail.com> writes:
Ram> On 03/28/2016 02:25 PM, John Stoffel wrote:
>> I just went back and checked, and I got the:
>>
>> LSI 9211 SAS9211-8i 8port low profile 6Gb/s SAS Host Bus Adapter
>>
>> which was a DELL brand controller. The 9207 is another model which is
>> also recommended, but this is from 2014 or even earlier. There might
>> be newer models out there.
>>
>> I paid $123 plus shipping. Been very happy with it, not problems at
>> all.
Ram> I searched your description and got this
>> http://www.ebay.com/itm/LSI-SAS-9211-8i-6Gbps-8Port-PCI-Express-SATA-SAS-Host-Bus-Adapter-Hot-/380703631558
Ram> Is this the one you are talking about? In my message I mentions this,
>> www.ebay.com/itm/like/252048579357?lpid=82&chn=ps&ul_noapp=true
That looks very much how I remember mine. Make sure you get a full
height bracket when you order, that was one of the things I had to
check as I recall now, since I have a full height tower system, not a
2U rack mounted system.
Ram> Mine is cheaper, so it worries me (BTW, for LSI 9211-8i, the
Ram> prices are all over the place). Yours claims RAID capability
Ram> (assuming IR firmware) and the other seem to be no raid (may be
Ram> IT firmware)
I just flashed the standard LSI firmware from their site as I recall.
I disabled any hardware RAID stuff as well. Since I can't just
bounce the system to check, take what I say with a grain of salt.
Ram> Both are from China, and like you say, not sure what I will get.
I seem to recall I got it from someone in the US.
The other trick I did was to put all my data volumes on the LSI
controller, and just a pair of SSDs onto the internal SATA
controllers. This way I know which devices I'll boot from, and it
made it simpler to know I had updated and setup GRUB properly.
You do want to test booting from a broken RAID1 boot device. When I
recently did my big re-org, I found that to make it boot I had to move
the working boot drive to the non-working slot, since of course the
failed one was effectively /dev/first-drive and that's how grub needed
to boot.
John
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Ram Ramesh @ 2016-03-28 19:43 UTC (permalink / raw)
To: John Stoffel; +Cc: Linux Raid
In-Reply-To: <22265.34078.125691.255754@quad.stoffel.home>
On 03/28/2016 02:25 PM, John Stoffel wrote:
> I just went back and checked, and I got the:
>
> LSI 9211 SAS9211-8i 8port low profile 6Gb/s SAS Host Bus Adapter
>
> which was a DELL brand controller. The 9207 is another model which is
> also recommended, but this is from 2014 or even earlier. There might
> be newer models out there.
>
> I paid $123 plus shipping. Been very happy with it, not problems at
> all.
I searched your description and got this
> http://www.ebay.com/itm/LSI-SAS-9211-8i-6Gbps-8Port-PCI-Express-SATA-SAS-Host-Bus-Adapter-Hot-/380703631558
Is this the one you are talking about? In my message I mentions this,
> www.ebay.com/itm/like/252048579357?lpid=82&chn=ps&ul_noapp=true
Mine is cheaper, so it worries me (BTW, for LSI 9211-8i, the prices are
all over the place). Yours claims RAID capability (assuming IR firmware)
and the other seem to be no raid (may be IT firmware)
Both are from China, and like you say, not sure what I will get.
Ramesh
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Ram Ramesh @ 2016-03-28 19:42 UTC (permalink / raw)
To: Andreas Klauer; +Cc: Linux Raid
In-Reply-To: <20160328193541.GA9502@EIS>
On 03/28/2016 02:35 PM, Andreas Klauer wrote:
> On Mon, Mar 28, 2016 at 01:44:33PM -0500, Ram Ramesh wrote:
>> The recommendations typically go for PCIe x1-2port type cards
> Well, an 8 port card (like HP H220 or similar) is a bit too
> expensive if all you need is two more slots, and it's not
> like mdadm is picky - anything goes, well, as long as it
> meets minimum requirements (no I/O errors etc)...
>
> If you're looking for something on an even larger scale,
> maybe have a look at the Backblaze Storage Pod blog posts.
> Although the hardware they use seems to be hard to get,
> it might give you some ideas.
>
> They actually use port multipliers, I actually wish they
> were as widespread (and as cheap) as USB hubs, so we all
> could simply put three or four disks to a single SATA port,
> but alas...
>
> Maybe next time.
>
> Regards
> Andreas Klauer
Andreas,
The two links I gave are about $120 and $80. If I used 2-port ones,
it will be too many (to get 8 ports) and my experience with marvell
chipset cards (4-port) was not good. So, I thought LSI 8-port is better
and reasonably priced. I also saw several feenas threads talking about
these cards working well in linux. Do you see risk in buying these as
they may not be what they claim to be?
Ramesh
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Phil Turmel @ 2016-03-28 19:41 UTC (permalink / raw)
To: Ram Ramesh, Linux Raid
In-Reply-To: <56F97B91.4070302@gmail.com>
Hi Ram,
On 03/28/2016 02:44 PM, Ram Ramesh wrote:
> The recommendations typically go for PCIe x1-2port type cards like
> this one
>> http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
Marvell
>>
chipsets have a mixed history on this list. The SATA models
have been nothing but trouble. But I haven't heard much about them
lately. Maybe someone else can comment on recent performance.
The marvell SAS models were also trouble until the kernel drivers got
some love in the past couple years. They're fine with current kernels.
I ran one of them as a short-term boost for an old server until I built
my most recent media server. It was 4.1 kernel I believe. I don't have
a link to that card handy, sorry. (I gave it to a family member.)
> However, I am looking for something along PCIe x4/x8 with 4+ ports
> like this one
>
>> http://www.amazon.com/SAS9211-8I-8PORT-Int-Sata-Pcie/dp/B002RL8I7M
> or (similar, but cheaper)
>> ww.ebay.com/itm/like/252048579357?lpid=82&chn=ps&ul_noapp=true
LSI has a very good reputation on this list. The above is likely to be
a very good choice. I have a similar unit in my media server:
https://smile.amazon.com/gp/product/B0034DMSO6/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1
Runs great. I did replace the firmware with the "IT" version so it
would boot faster (no attempt to enable soft raid).
Phil
^ permalink raw reply
* Re: Looking to pick PCIe x4/x8 4+ SATA expansion card recommendation.
From: Andreas Klauer @ 2016-03-28 19:35 UTC (permalink / raw)
To: Ram Ramesh; +Cc: Linux Raid
In-Reply-To: <56F97B91.4070302@gmail.com>
On Mon, Mar 28, 2016 at 01:44:33PM -0500, Ram Ramesh wrote:
> The recommendations typically go for PCIe x1-2port type cards
Well, an 8 port card (like HP H220 or similar) is a bit too
expensive if all you need is two more slots, and it's not
like mdadm is picky - anything goes, well, as long as it
meets minimum requirements (no I/O errors etc)...
If you're looking for something on an even larger scale,
maybe have a look at the Backblaze Storage Pod blog posts.
Although the hardware they use seems to be hard to get,
it might give you some ideas.
They actually use port multipliers, I actually wish they
were as widespread (and as cheap) as USB hubs, so we all
could simply put three or four disks to a single SATA port,
but alas...
Maybe next time.
Regards
Andreas Klauer
^ 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