* Re: [PATCH v2] Remove: container should wait for an array to release a drive
From: Jes Sorensen @ 2016-07-20 17:35 UTC (permalink / raw)
To: Tomasz Majchrzak
Cc: linux-raid, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
In-Reply-To: <1469001665-13648-1-git-send-email-tomasz.majchrzak@intel.com>
Tomasz Majchrzak <tomasz.majchrzak@intel.com> writes:
> A 'faulty' drive is being removed from a container after it has been
> released by an array, however there is a race there. The drive is
> released asynchronously by a monitor but sometimes it doesn't happen
> before container checks it. It results in a container refusing to remove
> a drive as it still seems to be a part of some array.
>
> It seems 'ping_monitor' could be a solution here to assure monitor has
> had a chance to process the events, however it doesn't resolve the
> problem - sometimes an array has to request a release of the drive few
> times (as the array is busy) and single 'ping_monitor' call is not
> sufficient. As there is no way to query monitor progress, it forces us
> to retry a check several times before an error is returned.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Manage.c | 38 +++++++++++++++++++++++++-------------
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/Manage.c b/Manage.c
> index e2e88b8..7f8eb88 100644
> --- a/Manage.c
> +++ b/Manage.c
> @@ -1125,19 +1125,31 @@ int Manage_remove(struct supertype *tst, int fd, struct mddev_dev *dv,
> */
> if (rdev == 0)
> ret = -1;
> - else
> - ret = sysfs_unique_holder(devnm, rdev);
> - if (ret == 0) {
> - pr_err("%s is not a member, cannot remove.\n",
> - dv->devname);
> - close(lfd);
> - return -1;
> - }
> - if (ret >= 2) {
> - pr_err("%s is still in use, cannot remove.\n",
> - dv->devname);
> - close(lfd);
> - return -1;
> + else {
> + /* The drive has already been set to 'faulty', however monitor might
> + * not have had time to process it and the drive might still have
> + * an entry in the 'holders' directory. Try a few times to avoid
> + * a false error */
Sorry for nagging again, but code is 80 characters wide, and comments
should not go beyond the 80 character limit - just like in the
kernel. The preferred format is (with applicable indentation):
/*
* Blah blah blah blah blah
* .... more blah blah blah
*/
Thanks,
Jes
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Wols Lists @ 2016-07-20 16:10 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Amit Biswas, linux-raid
In-Reply-To: <578F9A6F.3050503@youngman.org.uk>
On 20/07/16 16:36, Wols Lists wrote:
> Get that first 3TB drive. NOW. Physically replace sda in the machine,
> and configure it as a single-drive mirror ( --create --devices=2 sda
> spare).
Just noticed your edu address. If Phil Turmel chimes in, he'll tell me
off for telling you to spend money :-)
If you are an impecunious student, and your data will fit on 2TB, then
beg borrow or steal :-) a 2TB drive.
Use that as your backup, mirrored, as I said, and then you can combine
the two constellations into a 2TB raid0, and add that in as the second
half of your mirror. That will at least give you a working, safe, raid
system.
Cheers,
Wol
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Wols Lists @ 2016-07-20 15:36 UTC (permalink / raw)
To: Roman Mamedov; +Cc: Amit Biswas, linux-raid
In-Reply-To: <20160720200726.2e399266@natsu>
On 20/07/16 16:07, Roman Mamedov wrote:
> On Wed, 20 Jul 2016 15:31:09 +0100 Wols Lists
> <antlists@youngman.org.uk> wrote:
>
>> backing up and replacing the barracudas
>
> Yeah especially the sdb and sdf ones, which are failing HARD right
> now.
>
> 5 Reallocated_Sector_Ct 0x0033 095 095 036 Pre-fail
> Always - 7808 197 Current_Pending_Sector 0x0012 080
> 080 000 Old_age Always - 3359 198
> Offline_Uncorrectable 0x0010 080 080 000 Old_age Offline
> - 3359
>
> 5 Reallocated_Sector_Ct 0x0033 072 051 036 Pre-fail
> Always - 37616 187 Reported_Uncorrect 0x0032 001
> 001 000 Old_age Always - 587 197
> Current_Pending_Sector 0x0012 001 001 000 Old_age Always
> - 33664 198 Offline_Uncorrectable 0x0010 001 001 000
> Old_age Offline - 33664
>
OUCH!
Okay, and I don't like recommending stuff because I'm not an expert,
but you have 6 x 1TB drives, raid-10. Does that give you 1.5TB of
usable space, or 3TB? Never mind. I'm going to recommend getting 4 x
3TB drives at about £100 each - not nice. But you only need one to
start with.
Get that first 3TB drive. NOW. Physically replace sda in the machine,
and configure it as a single-drive mirror ( --create --devices=2 sda
spare).
Boot your system, run that timeout script, and try to assemble your
array with --scan --assemble --force. That SHOULD be safe. Read up and
make certain - I accept no responsibility for your data ...
If that works, you can now mount your array(s). READ ONLY.
Now copy your data across to the new drive - use something like rsync
or cp and keep a log - there's a high probability you'll get read
errors, and you don't want this to crash the copy and leave it only
partly complete, and you also want to know what failed.
You can now bring the system up on the new drive.
DUMP THE BARRACUDAS - ALL OF THEM. Two are failing, and the third one
is probably no better - it's not worth risking your data. The
constellations are probably okay as backup drives - it's a couple of
quid for an enclosure to turn them into usb drives :-)
As soon as you can, get the other three 3TB drives. The first of these
is urgent - your system will be running on a degraded mirror and you
need to fix that asap. The second drive will convert your mirror to
raid5, and the last one will convert it to raid6.
NB - I can't remember - is your boot/system partition on these drives?
You're better off running that as a mirror regardless, so if so, split
the 3TB drives into a small boot/system partition and a large data
partition, raid6 the data as you get the drives, and raid1 the
boot/system across all four drives (install grub on all four, too).
Cheers,
Wol
--
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: Recovering RAID Volumes from 6 Disks
From: Roman Mamedov @ 2016-07-20 15:07 UTC (permalink / raw)
To: Wols Lists; +Cc: Amit Biswas, linux-raid
In-Reply-To: <578F8B2D.5070003@youngman.org.uk>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Wed, 20 Jul 2016 15:31:09 +0100
Wols Lists <antlists@youngman.org.uk> wrote:
> backing up and replacing the barracudas
Yeah especially the sdb and sdf ones, which are failing HARD right now.
5 Reallocated_Sector_Ct 0x0033 095 095 036 Pre-fail Always - 7808
197 Current_Pending_Sector 0x0012 080 080 000 Old_age Always - 3359
198 Offline_Uncorrectable 0x0010 080 080 000 Old_age Offline - 3359
5 Reallocated_Sector_Ct 0x0033 072 051 036 Pre-fail Always - 37616
187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always - 587
197 Current_Pending_Sector 0x0012 001 001 000 Old_age Always - 33664
198 Offline_Uncorrectable 0x0010 001 001 000 Old_age Offline - 33664
--
With respect,
Roman
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Wols Lists @ 2016-07-20 14:53 UTC (permalink / raw)
To: Amit Biswas; +Cc: linux-raid
In-Reply-To: <578F8B2D.5070003@youngman.org.uk>
Looking back at your first post, what I think has happened is that sda
has failed, and sdb has fallen foul of the timeout problem.
IFF I'm right, getting your array back shouldn't be too hard.
Cheers,
Wol
On 20/07/16 15:31, Wols Lists wrote:
> Ummmmm ...
>
> b,e and f are Barracudas ... I know my 3TB Barracudas are vulnerable to
> the timeout problem. It looks like the 1TB ones probably are as well ...
>
> While you're waiting for someone else to chime in, read the following
> ... not the best reading ... about why your Barracudas are probably a
> bad choice :-(
>
> http://marc.info/?l=linux-raid&m=139050322510249&w=2
> http://marc.info/?l=linux-raid&m=135863964624202&w=2
> http://marc.info/?l=linux-raid&m=135811522817345&w=1
> http://marc.info/?l=linux-raid&m=133761065622164&w=2
> http://marc.info/?l=linux-raid&m=132477199207506
> http://marc.info/?l=linux-raid&m=133665797115876&w=2
> http://marc.info/?l=linux-raid&m=142487508806844&w=3
> http://marc.info/?l=linux-raid&m=144535576302583&w=2
>
> Have you got a spare Constellation lying around? If not, can you get a
> proper raid drive - WD Red or Seagate NAS? Do a ddrescue to copy sda to
> the replacement drive if you can. You don't want to use that to recover
> the array if you can help it, but you might not have much choice, and at
> least you'll have it to hand.
>
> And do NOT do this until the experts chime in and help, but hopefully
> it's just a case of making sure all your arrays are stopped, running the
> following script
>
> for x in /sys/block/sd[a-z] ; do
> echo 180 > $x/device/timeout
> done
>
> echo 4096 > /sys/block/md0/md/stripe_cache_size
>
> on the barracudas and re-assembling the array(s). At which point,
> backing up and replacing the barracudas should be extremely high on the
> agenda! It's probably a good idea to go Raid-6 and get 2 or 3TB drives.
>
> Cheers,
> Wol
>
>
> On 19/07/16 23:34, Amit Biswas wrote:
>> Here are the smart reports for all six drives. drive sda was not co-operating...
>>
>> /dev/sda
>>
>> smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
>> Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
>>
>> === START OF INFORMATION SECTION ===
>> Vendor: /2:0:0:0
>> Product:
>> User Capacity: 600,332,565,813,390,450 bytes [600 PB]
>> Logical block size: 774843950 bytes
>>>> Terminate command early due to bad response to IEC mode page
>>
>> === START OF READ SMART DATA SECTION ===
>>
>> Error Counter logging not supported
>>
>> Device does not support Self Test logging
>>
>
> --
> 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: Recovering RAID Volumes from 6 Disks
From: Wols Lists @ 2016-07-20 14:31 UTC (permalink / raw)
To: Amit Biswas; +Cc: linux-raid
In-Reply-To: <CADsVfeyz=KiAqSBe11jjBT-yOWpZp_eyP_BctkjvWC5UPNLXuQ@mail.gmail.com>
Ummmmm ...
b,e and f are Barracudas ... I know my 3TB Barracudas are vulnerable to
the timeout problem. It looks like the 1TB ones probably are as well ...
While you're waiting for someone else to chime in, read the following
... not the best reading ... about why your Barracudas are probably a
bad choice :-(
http://marc.info/?l=linux-raid&m=139050322510249&w=2
http://marc.info/?l=linux-raid&m=135863964624202&w=2
http://marc.info/?l=linux-raid&m=135811522817345&w=1
http://marc.info/?l=linux-raid&m=133761065622164&w=2
http://marc.info/?l=linux-raid&m=132477199207506
http://marc.info/?l=linux-raid&m=133665797115876&w=2
http://marc.info/?l=linux-raid&m=142487508806844&w=3
http://marc.info/?l=linux-raid&m=144535576302583&w=2
Have you got a spare Constellation lying around? If not, can you get a
proper raid drive - WD Red or Seagate NAS? Do a ddrescue to copy sda to
the replacement drive if you can. You don't want to use that to recover
the array if you can help it, but you might not have much choice, and at
least you'll have it to hand.
And do NOT do this until the experts chime in and help, but hopefully
it's just a case of making sure all your arrays are stopped, running the
following script
for x in /sys/block/sd[a-z] ; do
echo 180 > $x/device/timeout
done
echo 4096 > /sys/block/md0/md/stripe_cache_size
on the barracudas and re-assembling the array(s). At which point,
backing up and replacing the barracudas should be extremely high on the
agenda! It's probably a good idea to go Raid-6 and get 2 or 3TB drives.
Cheers,
Wol
On 19/07/16 23:34, Amit Biswas wrote:
> Here are the smart reports for all six drives. drive sda was not co-operating...
>
> /dev/sda
>
> smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
> Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Vendor: /2:0:0:0
> Product:
> User Capacity: 600,332,565,813,390,450 bytes [600 PB]
> Logical block size: 774843950 bytes
>>> Terminate command early due to bad response to IEC mode page
>
> === START OF READ SMART DATA SECTION ===
>
> Error Counter logging not supported
>
> Device does not support Self Test logging
>
^ permalink raw reply
* Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
From: Seth Forshee @ 2016-07-20 12:52 UTC (permalink / raw)
To: Sheng Yang
Cc: Eric W. Biederman, Miklos Szeredi, Alexander Viro, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, kernel list,
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: <CA+2rt426_pshAauQizcxkfAq16vmEpB4sJ4genW_ucosH3j=zQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jul 19, 2016 at 07:44:11PM -0700, Sheng Yang wrote:
> On Tue, Apr 26, 2016 at 12:36 PM, Seth Forshee
> <seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
> > When the userspace process servicing fuse requests is running in
> > a pid namespace then pids passed via the fuse fd are not being
> > translated into that process' namespace. Translation is necessary
> > for the pid to be useful to that process.
> >
> > Since no use case currently exists for changing namespaces all
> > translations can be done relative to the pid namespace in use
> > when fuse_conn_init() is called. For fuse this translates to
> > mount time, and for cuse this is when /dev/cuse is opened. IO for
> > this connection from another namespace will return errors.
> >
> > Requests from processes whose pid cannot be translated into the
> > target namespace are not permitted, except for requests
> > allocated via fuse_get_req_nofail_nopages. For no-fail requests
> > in.h.pid will be 0 if the pid translation fails.
>
> Hi Seth,
>
> This patch caused a regression in our major container use case with
> FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
> Ubuntu 4.4.0-6.21 kernel.
>
> The use case is:
> 1. Create a Docker container.
> 2. Inside the container, start the FUSE backend, and mounted fs.
> 3. Following step 2 in the container, create a loopback device to map
> a file in the mounted fuse to create a block device, which will be
> available to the whole system.
>
> It works well before this commit.
>
> The use case is broken because no matter which namespace losetup runs,
> the real request from loopback device seems always come from init ns,
> thus it will be in different ns running fuse backend. So the request
> will got denied, because the ns running fuse won't able to see the
> things from higher level(level 0 in fact) pid namespace.
>
> I think since init pid ns has ability to access any process in the
> system, it should able to access the fuse mounted by any pid namespace
> process as well.
>
> What you think?
It sounds like we need to remove the restriction on accessing the
filesystem from a different pid namespace. I don't think this poses a
security problem. However there's no pid mapping that is usable by the
userspace fuse process, so what do we put in the fuse request? Probably
the only candidates are 0 and 0xffffffff.
So a question for the fuse developers - is one value or the other
preferrable for fuse_in_header.pid when the pid cannot be mapped, and is
this going to cause problems for any fuse filesystems? I suspect that
few filesystems actually look at the pid anyway, and already for a
filesystem mounted in a pid namespace the values being given to
userspace won't be correct for the namespace of the fuse process.
Seth
^ permalink raw reply
* Re: How does md gurantee not miss to free an active stripe_head when md stops?
From: Vaughan @ 2016-07-20 10:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid
Hi Neil,
I'm using v3.10 md code for develop. Recently I encounter a problem where an
read IO usually returned from physical disk after md has been stopped.
I reviewed the code and find when md stops, it unregister raid5d
unconditionally and call shrink_stripes() to free only the *inactive*
stripes.
I know before stop, it uses O_EXCL open the md, but that won't stop others
open it and send IO to it.
So I think it's possible that some active stripes will be still running.
And I also found
commit 5aa61f427e4979be733e4847b9199ff9cc48a47e
Author: NeilBrown <neilb@suse.de>
Date: Mon Dec 15 12:56:57 2014 +1100
md: split detach operation out from ->stop.
add calling a quiesce before unregister raid5d in __md_stop, which not
exists there before.
Does this fix the hole when md stop?
In my case, an OOPS usually happens like below:
I keep calling mdadm -stop to stop a md, but lsof shows it's opened by
systemd-udevd, so "still is inuse".
30s later, udev reports timeout and be kicked with SIGKILL.
systemd-udevd: worker [19335]/devices/virtual/block/md41 timeout; kill it.
Then md stop process is able to continue and go passed the free_conf(). But
there is an active_stripe left.
kernel:
shrink_stripes:conf(ffff880004affc00)->md(ffff8802d95b4000,md41)active_strip
es=1 <== this is my debug print.
kernel: md41: detected capacity change from 3409128980480 to 0
mdadm: stopped /dev/md41
After md is stopped, an read IO from underlying returned and OOPS.
[190830.867371] md: unbind<dm-64>
[190830.876345] md: export_rdev(dm-64)
[190831.201619] BUG: unable to handle kernel [190831.202875] paging request
at 0000000000002050 [190831.204101] IP: [<ffffffffa089a349>]
raid5_end_read_request+0xf9/0xdc0[raid456]
I found this returned bio is caused by a user read page, which is caused by
a fput to kill_bdev.
PID: 21345 TASK: ffff8803e5a916c0 CPU: 1 COMMAND: "mdadm"
#0 [ffff88016f777b88] __schedule at ffffffff815f513d
#1 [ffff88016f777bf0] io_schedule at ffffffff815f599d
#2 [ffff88016f777c08] sleep_on_page at ffffffff81155f1e
#3 [ffff88016f777c18] __wait_on_bit_lock at ffffffff815f38ab
#4 [ffff88016f777c58] __lock_page at ffffffff81156038
#5 [ffff88016f777cb0] truncate_inode_pages_range at ffffffff8116645e
#6 [ffff88016f777e00] truncate_inode_pages at ffffffff811664b5
#7 [ffff88016f777e10] kill_bdev at ffffffff811ffaef
#8 [ffff88016f777e28] __blkdev_put at ffffffff81201124
#9 [ffff88016f777e68] blkdev_put at ffffffff81201bae
#10 [ffff88016f777e98] blkdev_close at ffffffff81201d55
#11 [ffff88016f777ea8] __fput at ffffffff811c81b9
#12 [ffff88016f777ef0] ____fput at ffffffff811c847e
#13 [ffff88016f777f00] task_work_run at ffffffff81093b37
#14 [ffff88016f777f30] do_notify_resume at ffffffff81013b0c
#15 [ffff88016f777f50] int_signal at ffffffff8160049d
^ permalink raw reply
* Re: Cannot start array on disk
From: Phil Turmel @ 2016-07-20 10:30 UTC (permalink / raw)
To: Bhatia Amit, linux-raid@vger.kernel.org
In-Reply-To: <1537154003.1687848.1468983169996.JavaMail.yahoo@mail.yahoo.com>
Hi Amit,
{ Note, convention on kernel.org is to trim & bottom post, or interleave
replies with trimmed context. }
On 07/19/2016 10:52 PM, Bhatia Amit wrote:
> Hi Phil
>
> One more thing. When the enclosure became inaccesible in June 2016,
> WDC gave me a new unit with drives. I dont remember for sure, but I
> think I first replaced drive A from new enclosure with the Drive A
> (currently in discussion) from old enclosure, hoping new unit would
> reconfigure based on info from old drive. But I was not able to
> access the unit. Then I put back the two new drives back in new
> enclosure, configured new unit for RAID1 and then replaced the drive
> A again with the drive A from old enclosure, but again no luck
> accessing it (Error Message=Unable to mount). Since the default
> configuration of a new configuration is Striping and not RAID1,
> probably the first action (replacing drive A before configuring new
> unit for RAID1), might have been the cause why this drive A shows as
> RAID=linear, rather than RAID1.
That could explain it, but I would have expected your mount of /dev/sdc4
to succeed. Your dmesg excerpt clearly shows a raid1 binding on
partition 4, so the metadata on the drive you are examining must be
wrong. The only way I know for that to happen is if there are multiple
superblocks on the drive, and a plain examine is finding the v1.0
metadata first.
I'm not sure if this is supported, by try specifying the version along
with --examine for each of v0.90, v1.0, v1.1, and v1.2 to see if any
difference shows. Paste the results from each.
Phil
^ permalink raw reply
* [PATCH] raid5: fix incorrectly counter of conf->empty_inactive_list_nr
From: Zhengyuan Liu @ 2016-07-20 9:22 UTC (permalink / raw)
To: shli@kernel.org, linux-raid; +Cc: 刘云, 胡海
The counter conf->empty_inactive_list_nr is only used for determine if
the raid5 is congested which is deal with in function
raid5_congested(). It was increased in get_free_stripe() when
conf->inactive_list got emptied and decreased in
release_inactive_stripe_list() when splice temp_inactive_list to
conf->inactive_list. However, this could cause to problem when
raid5_get_active_stripe was called, this function may call
list_del_init(&sh->lru) to delete sh from "conf->inactive_list +
hash" which may cause "conf->inactive_list + hash" to be empty when
atomic_inc_not_zero(&sh->count) got false.
I have found conf->empty_inactive_list_nr to be negative number
during my random test.
Is there anything out of my thinking?
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -659,6 +659,7 @@ raid5_get_active_stripe(struct r5conf *conf,
sector_t sector,
{
struct stripe_head *sh;
int hash = stripe_hash_locks_hash(sector);
+ int inc_empty_inactive_list_flag;
pr_debug("get_stripe, sector %llu\n", (unsigned long long)sector);
@@ -703,7 +704,14 @@ raid5_get_active_stripe(struct r5conf *conf,
sector_t sector,
atomic_inc(&conf->active_stripes);
BUG_ON(list_empty(&sh->lru) &&
!test_bit(STRIPE_EXPANDING, &sh->state));
+
+ inc_empty_inactive_list_flag = 0;
+ if(!list_empty(conf->inactive_list + hash))
+ inc_empty_inactive_list_flag = 1;
list_del_init(&sh->lru);
+ if(list_empty(conf->inactive_list +
hash) && inc_empty_inactive_list_flag)
+
atomic_inc(&conf->empty_inactive_list_nr);
+
if (sh->group) {
sh->group->stripes_cnt--;
sh->group = NULL;
^ permalink raw reply
* [PATCH v2] Remove: container should wait for an array to release a drive
From: Tomasz Majchrzak @ 2016-07-20 8:01 UTC (permalink / raw)
To: linux-raid
Cc: Jes.Sorensen, aleksey.obitotskiy, pawel.baldysiak,
artur.paszkiewicz
A 'faulty' drive is being removed from a container after it has been
released by an array, however there is a race there. The drive is
released asynchronously by a monitor but sometimes it doesn't happen
before container checks it. It results in a container refusing to remove
a drive as it still seems to be a part of some array.
It seems 'ping_monitor' could be a solution here to assure monitor has
had a chance to process the events, however it doesn't resolve the
problem - sometimes an array has to request a release of the drive few
times (as the array is busy) and single 'ping_monitor' call is not
sufficient. As there is no way to query monitor progress, it forces us
to retry a check several times before an error is returned.
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Manage.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/Manage.c b/Manage.c
index e2e88b8..7f8eb88 100644
--- a/Manage.c
+++ b/Manage.c
@@ -1125,19 +1125,31 @@ int Manage_remove(struct supertype *tst, int fd, struct mddev_dev *dv,
*/
if (rdev == 0)
ret = -1;
- else
- ret = sysfs_unique_holder(devnm, rdev);
- if (ret == 0) {
- pr_err("%s is not a member, cannot remove.\n",
- dv->devname);
- close(lfd);
- return -1;
- }
- if (ret >= 2) {
- pr_err("%s is still in use, cannot remove.\n",
- dv->devname);
- close(lfd);
- return -1;
+ else {
+ /* The drive has already been set to 'faulty', however monitor might
+ * not have had time to process it and the drive might still have
+ * an entry in the 'holders' directory. Try a few times to avoid
+ * a false error */
+ int count = 20;
+ do {
+ ret = sysfs_unique_holder(devnm, rdev);
+ if (ret < 2)
+ break;
+ usleep(100 * 1000); //100ms
+ } while (--count > 0);
+
+ if (ret == 0) {
+ pr_err("%s is not a member, cannot remove.\n",
+ dv->devname);
+ close(lfd);
+ return -1;
+ }
+ if (ret >= 2) {
+ pr_err("%s is still in use, cannot remove.\n",
+ dv->devname);
+ close(lfd);
+ return -1;
+ }
}
}
/* FIXME check that it is a current member */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] raid10: improve random reads performance
From: Tomasz Majchrzak @ 2016-07-20 7:31 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid
In-Reply-To: <20160719222006.GA79792@kernel.org>
On Tue, Jul 19, 2016 at 03:20:06PM -0700, Shaohua Li wrote:
> On Fri, Jun 24, 2016 at 02:20:16PM +0200, Tomasz Majchrzak wrote:
> > RAID10 random read performance is lower than expected due to excessive spinlock
> > utilisation which is required mostly for rebuild/resync. Simplify allow_barrier
> > as it's in IO path and encounters a lot of unnecessary congestion.
> >
> > As lower_barrier just takes a lock in order to decrement a counter, convert
> > counter (nr_pending) into atomic variable and remove the spin lock. There is
> > also a congestion for wake_up (it uses lock internally) so call it only when
> > it's really needed. As wake_up is not called constantly anymore, ensure process
> > waiting to raise a barrier is notified when there are no more waiting IOs.
> >
> > Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
>
> Patch looks good, applied. Do you have data how this improves the performance?
>
> Thanks,
> Shaohua
I have tested it on a platform with 4 NVMe drives using fio random reads
feature. Before the patch RAID10 array has been achieved 234% of single drive
performance. With my patch the same array achieves 347% of single drive
performance. The best performance of 4 drives in compare to one drive in this
test could be 400% so it's around 30% boost.
Tomek
^ permalink raw reply
* RE: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
From: Obitotskiy, Aleksey @ 2016-07-20 6:25 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <20160719224603.GB79792@kernel.org>
Hello,
md_update_sb does not clean MD_CHANGE_PENDING flag for imsm arrays (i.e. external == 1).
And until MD_CHANGE_PENDING is set all remaining or new IO will not be finished
but will stay in return_bi list.
Regards,
Aleskey
-----Original Message-----
From: Shaohua Li [mailto:shli@kernel.org]
Sent: Wednesday, 20 July, 2016 00:46
To: Obitotskiy, Aleksey <aleksey.obitotskiy@intel.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
On Fri, Jul 15, 2016 at 03:24:27PM +0200, Alexey Obitotskiy wrote:
> After array enters in failed state (e.g. number of failed drives
> becomes more then accepted for raid5 level) it sets error flags (one
> of this flags is MD_CHANGE_PENDING). This flag prevents to finish all
> new or non-finished IOs to array and hold them in pending state. In
> some cases this can leads to deadlock situation.
>
> For example udev handle array state changes (drives becomes faulty)
> and blkid started but unable to finish reads due to IO hold.
> At the same time we unable to get exclusive access to array (to stop
> array in our case) because another external application still use this
> array (blkid in our case).
>
> Fix makes possible to return IO with errors immediately.
> So external application can finish working with array and give
> exclusive access to other applications.
>
> Signed-off-by: Alexey Obitotskiy <aleksey.obitotskiy@intel.com>
> ---
> drivers/md/raid5.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index
> 6c1149d..99471b6 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -4692,7 +4692,9 @@ finish:
> }
>
> if (!bio_list_empty(&s.return_bi)) {
> - if (test_bit(MD_CHANGE_PENDING, &conf->mddev->flags)) {
> + if (test_bit(MD_CHANGE_PENDING, &conf->mddev->flags) &&
> + (s.failed <= conf->max_degraded ||
> + conf->mddev->external == 0)) {
> spin_lock_irq(&conf->device_lock);
> bio_list_merge(&conf->return_bi, &s.return_bi);
> spin_unlock_irq(&conf->device_lock);
> --
> 2.7.4
Hi Alexey,
I'm not clear about the race. When we set the MD_CHANGE_PENDING, we will schedule superblock write, which will eventually finish (either success or timedout). Why will the IO be hold forever?
Thanks,
Shaohua
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-20 2:52 UTC (permalink / raw)
To: Bhatia Amit, Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <1436537429.1672198.1468980612541.JavaMail.yahoo@mail.yahoo.com>
Hi Phil
One more thing. When the enclosure became inaccesible in June 2016, WDC gave me a new unit with drives. I dont remember for sure, but I think I first replaced drive A from new enclosure with the Drive A (currently in discussion) from old enclosure, hoping new unit would reconfigure based on info from old drive. But I was not able to access the unit. Then I put back the two new drives back in new enclosure, configured new unit for RAID1 and then replaced the drive A again with the drive A from old enclosure, but again no luck accessing it (Error Message=Unable to mount). Since the default configuration of a new configuration is Striping and not RAID1, probably the first action (replacing drive A before configuring new unit for RAID1), might have been the cause why this drive A shows as RAID
=linear, rather than RAID1.
Thanks
Amit
----- Original Message -----
From: Bhatia Amit <amitbhatia@rocketmail.com>
To: Phil Turmel <philip@turmel.org>; "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Sent: Tuesday, July 19, 2016 10:10 PM
Subject: Re: Cannot start array on disk
Hi Phil
1. The enclosure had 2 drives in RAID1, since 2013. One drive went bad early this year around Feb 2016 (Drive A). WDC gave a RMA replacement drive. I remember accessing the enclosure at least once after the RMA drive rebuilt. This drive A is the one that is still alive. The drive B went bad recently (June 2016) after which I was unable to access the system at all.
2. The drive should be around 1/3rd used i.e around 1TB out of 3TB drive should be used.
3. Connecting this drive via esata to a linux laptop, gparted shows sdc1 and sdc2 as EXT3 of 1.91GB each, and sdc3 (489MB) and sdc4 (2.72TB) as linux-raid filesystem.
4. I mounted sdc1 and sdc2 and var/log directories on both look like copy of each other:
$ ls -lart p1/var/log
total 1136
-rw-rw-rw- 1 root root 31 Dec 31 1969 master_drive_serial_number
drwxr-xr-x 2 root root 4096 Mar 24 2010 sysstat
drwxr-xr-x 2 root root 4096 Sep 16 2013 apt
-rw-rw-rw- 1 root adm 4734 Sep 16 2013 dmesg.4.gz
-rw-rw-rw- 1 root adm 4799 Sep 16 2013 dmesg.3.gz
drwxr-xr-- 2 root root 4096 Sep 16 2013 news
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.warn
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.log
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.info
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.err
-rw-r--r-- 1 root adm 0 Sep 16 2013 lpr.log
drwxr-xr-x 2 root root 4096 Sep 16 2013 apache2
-rw-rw-rw- 1 root adm 14889 May 7 2015 dmesg.0
-rw-r--r-- 1 root adm 0 May 7 2015 sshd.log
-rw-r--r-- 1 root adm 1765 May 7 2015 kern.log
-rw-r--r-- 1 root root 1504 May 7 2015 dpkg.log
-rw-r----- 1 root adm 0 Jul 1 22:38 vsftpd.log
drwxr-xr-x 3 root root 4096 Jul 1 22:38 samba
-rw-rw-rw- 1 root adm 4747 Jul 1 22:42 dmesg.2.gz
-rw-rw-rw- 1 root adm 4747 Jul 1 22:48 dmesg.1.gz
-rw-rw-rw- 1 root root 154 Jul 1 23:01 version.log
drwxr-xr-x 14 root root 4096 Jul 1 23:06 ..
-rw-r--r-- 1 root adm 75 Jul 1 23:06 wdalerts.log
-rw-r--r-- 1 root adm 15259 Jul 1 23:10 wdnas.log
-rw-r--r-- 1 root root 3067 Jul 1 23:10 forked-daapd.log
-rw-r--r-- 1 root adm 32586 Jul 1 23:11 user.log
-rw-r--r-- 1 root adm 74 Jul 1 23:11 dlna_server.log
-rw-r--r-- 1 root adm 4243 Jul 1 23:11 miocrawler.log
-rw-r--r-- 1 root adm 21531 Jul 1 23:12 mediacrawler.log
-rw-r--r-- 1 root adm 643021 Jul 2 00:02 rest_api.log.1
-rw-r--r-- 1 root adm 151111 Jul 2 00:02 messages
-rw-r--r-- 1 root adm 31328 Jul 2 02:14 daemon.log
-rw-rw-rw- 1 root root 720 Jul 2 03:00 ramlog
-rw-rw-rw- 1 root adm 15162 Jul 2 12:02 dmesg
-rw-rw-rw- 1 root root 108362 Jul 2 12:02 rest_api.log
-rw-rw-rw- 1 root root 58 Jul 2 12:02 purge.log
drwxr-xr-x 7 root root 4096 Jul 2 12:02 .
5. A grep of raid or sd or ext, on messages shows:
$ cat p1/var/log/messages | egrep -i "sd|raid|ext"
Sep 16 11:53:17 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Sep 16 11:53:17 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Sep 16 11:53:17 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Sep 16 11:53:17 MyBookLiveDuo kernel: sda:
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 16 11:53:17 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Sep 16 11:53:17 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Sep 16 11:53:17 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Sep 16 11:53:17 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Sep 16 11:53:17 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: considering sdb2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sdb2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sdb1 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sda2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sda1 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sda1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sda2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sdb1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sdb2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: kicking non-fresh sdb2 from array!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: unbind<sdb2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: export_rdev(sdb2)
Sep 16 11:53:17 MyBookLiveDuo kernel: md: kicking non-fresh sdb1 from array!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: unbind<sdb1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: export_rdev(sdb1)
Sep 16 11:53:17 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Sep 16 11:53:17 MyBookLiveDuo kernel: raid1: raid set md0 active with 2 out of 4 mirrors
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3-fs: recovery complete.
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 16 11:53:17 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Sep 16 11:53:25 MyBookLiveDuo kernel: md: bind<sdb3>
Sep 16 11:53:25 MyBookLiveDuo kernel: md: bind<sda3>
Sep 16 11:53:25 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Sep 16 11:53:36 MyBookLiveDuo [admin-rest-api.postinst] 09/16/13 18:53:36: test context=test
Sep 16 11:53:40 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d1790000
Jul 1 19:39:01 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:39:01 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:39:01 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:39:01 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb1
Jul 1 19:39:02 MyBookLiveDuo kernel: md: recovery of RAID array md0
Jul 1 19:39:02 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:39:40 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:39:40 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 3, wo:1, o:1, dev:sdb2
Jul 1 19:39:41 MyBookLiveDuo kernel: md: recovery of RAID array md0
Jul 1 19:40:18 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:42:02 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 19:42:02 MyBookLiveDuo kernel: ufsd: driver unloaded
Jul 1 19:42:26 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Jul 1 19:42:26 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Jul 1 19:42:26 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Jul 1 19:42:26 MyBookLiveDuo kernel: sda:
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:42:26 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Jul 1 19:42:26 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Jul 1 19:42:26 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 1 19:42:26 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Jul 1 19:42:26 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: considering sdb2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sdb2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sdb1 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sda2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sda1 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md0: WARNING: sdb2 appears to be on the same physical disk as sdb1.
Jul 1 19:42:26 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Jul 1 19:42:26 MyBookLiveDuo kernel: raid1: raid set md0 active with 4 out of 4 mirrors
Jul 1 19:42:26 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Jul 1 19:42:26 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 1 19:42:26 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Jul 1 19:42:32 MyBookLiveDuo kernel: md: bind<sdb3>
Jul 1 19:42:32 MyBookLiveDuo kernel: md: bind<sda3>
Jul 1 19:42:32 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Jul 1 19:42:40 MyBookLiveDuo [admin-rest-api.postinst] 07/02/16 02:42:40: test context=test
Jul 1 19:42:44 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d1790000
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 19:47:30 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 19:47:31 MyBookLiveDuo kernel: ufsd: driver unloaded
Jul 1 19:48:09 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Jul 1 19:48:09 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Jul 1 19:48:09 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Jul 1 19:48:09 MyBookLiveDuo kernel: sda:
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:48:09 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Jul 1 19:48:09 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Jul 1 19:48:09 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Jul 1 19:48:09 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Jul 1 19:48:09 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: considering sdb2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sdb2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sdb1 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sda2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sda1 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md0: WARNING: sdb2 appears to be on the same physical disk as sdb1.
Jul 1 19:48:09 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Jul 1 19:48:09 MyBookLiveDuo kernel: raid1: raid set md0 active with 4 out of 4 mirrors
Jul 1 19:48:09 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Jul 1 19:48:09 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 1 19:48:09 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Jul 1 19:48:13 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: unbind<sdb4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: export_rdev(sdb4)
Jul 1 19:48:13 MyBookLiveDuo kernel: md: unbind<sda4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: export_rdev(sda4)
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sdb3>
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sda3>
Jul 1 19:48:15 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 19:53:51 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
Jul 1 19:53:56 MyBookLiveDuo [wd-nas.postinst] 07/02/16 02:53:55: restore context=restore
Jul 1 19:54:00 MyBookLiveDuo [networking-general.postinst] 07/02/16 02:54:00: restore context=restore
Jul 1 19:54:01 MyBookLiveDuo [apache-php-webdav.postinst] 07/02/16 02:54:01: restore context=restore
Jul 1 19:54:06 MyBookLiveDuo [date-time.postinst] 07/02/16 02:54:06: restore context=restore
Jul 1 19:54:09 MyBookLiveDuo [alerts.postinst] 07/02/16 02:54:09: restore context=restore
Jul 1 19:54:10 MyBookLiveDuo [admin-rest-api.postinst] 07/02/16 02:54:10: restore context=restore
Jul 1 19:54:12 MyBookLiveDuo [drive-lib.postinst] 07/02/16 02:54:12: restore context=restore
Jul 1 19:54:13 MyBookLiveDuo [data-volume-config.postinst] 07/02/16 02:54:13: restore context=restore
Jul 1 19:54:14 MyBookLiveDuo [upnp-nas.postinst] 07/02/16 02:54:14: restore context=restore
Jul 1 19:54:15 MyBookLiveDuo [dlna-server-access.postinst] 07/02/16 02:54:15: restore context=restore
Jul 1 19:54:16 MyBookLiveDuo [itunes.postinst] 07/02/16 02:54:16: restore context=restore
Jul 1 19:54:17 MyBookLiveDuo [nas-safepoint.postinst] 07/02/16 02:54:17: restore context=restore
Jul 1 19:54:18 MyBookLiveDuo [webui.postinst] 07/02/16 02:54:18: restore context=restore
Jul 1 19:54:28 MyBookLiveDuo [orion-resources.postinst] 07/02/16 02:54:28: restore context=restore
Jul 1 19:54:29 MyBookLiveDuo [afp.postinst] 07/02/16 02:54:29: restore context=restore
Jul 1 19:54:29 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Jul 1 19:55:18 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d3b00000
Jul 1 19:55:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 2, wo:1, o:0, dev:sdb1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:55:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:55:31 MyBookLiveDuo kernel: md: unbind<sdb1>
Jul 1 19:55:31 MyBookLiveDuo kernel: md: export_rdev(sdb1)
Jul 1 19:55:32 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:55:32 MyBookLiveDuo kernel: raid1: raid set md1 active with 1 out of 4 mirrors
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3-fs warning: checktime reached, running e2fsck is recommended
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3 FS on md1, internal journal
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with writeback data mode.
May 7 18:23:57 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
May 7 18:23:57 MyBookLiveDuo kernel: Kernel command line: root=/dev/md1 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
May 7 18:23:57 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
May 7 18:23:57 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
May 7 18:23:57 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
May 7 18:23:57 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
May 7 18:23:57 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
May 7 18:23:57 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
May 7 18:23:57 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
May 7 18:23:57 MyBookLiveDuo kernel: sda:
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 7 18:23:57 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
May 7 18:23:57 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
May 7 18:23:57 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
May 7 18:23:57 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
May 7 18:23:57 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
May 7 18:23:57 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: considering sdb2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sdb2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb1 has different UUID to sdb2
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sda2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sda1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sda1>
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sda2>
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sdb2>
May 7 18:23:57 MyBookLiveDuo kernel: md: running: <sdb2><sda2><sda1>
May 7 18:23:57 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
May 7 18:23:57 MyBookLiveDuo kernel: raid1: raid set md0 active with 3 out of 4 mirrors
May 7 18:23:57 MyBookLiveDuo kernel: md: considering sdb1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sdb1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sdb1>
May 7 18:23:57 MyBookLiveDuo kernel: md: running: <sdb1>
May 7 18:23:57 MyBookLiveDuo kernel: raid1: raid set md1 active with 1 out of 4 mirrors
May 7 18:23:57 MyBookLiveDuo kernel: EXT3 FS on md1, internal journal
May 7 18:23:57 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
May 7 18:23:57 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:1.
May 7 18:24:01 MyBookLiveDuo kernel: md: bind<sdb3>
May 7 18:24:01 MyBookLiveDuo kernel: md: bind<sda3>
May 7 18:24:01 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
May 7 18:24:02 MyBookLiveDuo kernel: md: bind<sdb4>
May 7 18:24:02 MyBookLiveDuo kernel: md: bind<sda4>
May 7 18:24:02 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
May 7 18:24:10 MyBookLiveDuo [admin-rest-api.postinst] 05/08/15 01:24:10: test context=test
May 7 18:24:14 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
May 7 18:24:23 MyBookLiveDuo [dlna-server-access.postinst] 05/08/15 01:24:23: configure 02.00.00-100316 context=upgrade
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d2750000
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sdb2>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sdb2)
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sda2>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sda2)
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sda1>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sda1)
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 20:06:50 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:06:50 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:06:50 MyBookLiveDuo kernel: disk 1, wo:1, o:1, dev:sda1
Jul 1 20:06:50 MyBookLiveDuo kernel: md: recovery of RAID array md1
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 20:06:50 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md1 ...
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb2
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb2
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 3, wo:1, o:1, dev:sda2
Jul 1 20:07:31 MyBookLiveDuo kernel: md: recovery of RAID array md1
Jul 1 20:08:39 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb2
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sda2
Jul 1 20:09:54 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 20:10:49 MyBookLiveDuo kernel: md: unbind<sda4>
Jul 1 20:10:49 MyBookLiveDuo kernel: md: export_rdev(sda4)
Jul 1 20:10:49 MyBookLiveDuo kernel: md: unbind<sdb4>
Jul 1 20:10:49 MyBookLiveDuo kernel: md: export_rdev(sdb4)
Jul 1 20:10:51 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 20:10:51 MyBookLiveDuo kernel: raid1: raid set md3 active with 1 out of 2 mirrors
Jul 1 20:10:51 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 20:10:51 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:10:51 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda4
Jul 1 20:10:51 MyBookLiveDuo kernel: disk 1, wo:1, o:1, dev:sdb4
Jul 1 20:10:51 MyBookLiveDuo kernel: md: recovery of RAID array md3
Jul 1 20:10:51 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
The messages file has 1922 lines, so I am not pasting the whole content here yet, unless you suggest.
6. Trying to mount sdc4 as ext4 fails:
$ sudo mount -t ext4 /dev/sdc4 p4
mount: /dev/sdc4 already mounted or p4 busy
Is there a way to confirm whether sdc4 was ext4 (as r-linux) had reported, or ext3?
7. Before trying to do fsck on sdc4, I wanted to check if you had any other suggestion based on info above. Also, looks like for fsck I should be providing filesystem type. So, wanted to check if I should try ext3 or ext4 on sdc4, when trying fsck.
Thanks
Amit
----- Original Message -----
From: Phil Turmel <philip@turmel.org>
To: Bhatia Amit <amitbhatia@rocketmail.com>; "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Sent: Tuesday, July 19, 2016 5:12 AM
Subject: Re: Cannot start array on disk
On 07/17/2016 03:59 PM, Bhatia Amit wrote:
> Hi
>
> I have a WD Live duo setup with two 3TB drives in RAID1. After a
> recent power surge etc, I could not access the enclosure data. I
> removed the drives out from the enclosure and connected them via
> esata cable to a Linux laptop. One of the drives had physical noise
> and failed to connect at all. The other drive was able to connect and
> showed up as /dev/sdc. Following some online search, I issued the
> following commands to get some results, but am unable to mount the
> drive to a linux laptop via esata. Questions:
>
> * Ideally both sdc3 and sdc4 should have shown RAID=RAID1. If sdc4 is
> showing RAID=linear, is it because the other drive went totally bad,
> and software decided to reconfigure this drive from RAID1 to linear
> ?
No way to know. I would be inclined to believe that that you didn't
actually have raid1 set for those partitions. Do you recall the
available space in that device while running?
> * Given the one of the two drives is totally dead, is it still
> possible to reconfigure, mount and recover data from the single
> drive?
If truly linear, no, not past the half-way mark. The device is
identified as role 0, so it would be the beginning of the filesystem in
a linear array. If it really was raid1 with v0.9 or v1.0 metadata, you
can mount /dev/sdc4 directly to access your data. That it doesn't show
a detected filesystem suggests that it wasn't raid1.
Even worse, that partition shows a creation date and update date both in
2013, with no events. Suggesting that the device hasn't actually been
running properly in the array since its initial creation.
> * I tried scanning the drive via r-linux and it does show files
> exist, but does not show any folder information. So data is there on
> the drive. Is there a way to recreate the setup with just this single
> drive, so that I can extract files with folder information?
With v1.0 metadata, you should be able to fsck /dev/sdc4 and then mount.
Kinda dangerous though -- I suggest you use an overlay for that. I
suspect that sdc4 hasn't been running in your array for the past three
years.
> * Looking at an online "derrick" script, the script seems to call
> mdadm create with the "missing" flag. Is that something I should be
> doing to be able to assemble and recover data from the drive ?
> "mdadm --create $rootfsRaid --verbose --metadata=0.9 --raid-devices=2
> --level=raid1 --run $diskRoot1 missing"
No.
Using --create is practically never the right solution, unless you've
done operations that destroy the right solution. Metadata v0.9 is
almost certainly wrong.
If you have syslogs on your other array that show the boot details from
the last successful boot *before* it died, that might provide the
details needed to figure if anything recent is on sdc4.
Phil
^ permalink raw reply
* Re: [PATCH v4 18/21] fuse: Add support for pid namespaces
From: Sheng Yang @ 2016-07-20 2:44 UTC (permalink / raw)
To: Seth Forshee
Cc: Eric W. Biederman, Miklos Szeredi, Alexander Viro, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Miklos Szeredi,
Pavel Tikhomirov, kernel list, linux-bcache, dm-devel, linux-raid,
linux-mtd, linux-fsdevel, fuse-devel, linux-security-module,
selinux, cgroups
In-Reply-To: <1461699396-33000-19-git-send-email-seth.forshee@canonical.com>
On Tue, Apr 26, 2016 at 12:36 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> When the userspace process servicing fuse requests is running in
> a pid namespace then pids passed via the fuse fd are not being
> translated into that process' namespace. Translation is necessary
> for the pid to be useful to that process.
>
> Since no use case currently exists for changing namespaces all
> translations can be done relative to the pid namespace in use
> when fuse_conn_init() is called. For fuse this translates to
> mount time, and for cuse this is when /dev/cuse is opened. IO for
> this connection from another namespace will return errors.
>
> Requests from processes whose pid cannot be translated into the
> target namespace are not permitted, except for requests
> allocated via fuse_get_req_nofail_nopages. For no-fail requests
> in.h.pid will be 0 if the pid translation fails.
Hi Seth,
This patch caused a regression in our major container use case with
FUSE in Ubuntu 16.04, as patch was checked in as Ubuntu Sauce in
Ubuntu 4.4.0-6.21 kernel.
The use case is:
1. Create a Docker container.
2. Inside the container, start the FUSE backend, and mounted fs.
3. Following step 2 in the container, create a loopback device to map
a file in the mounted fuse to create a block device, which will be
available to the whole system.
It works well before this commit.
The use case is broken because no matter which namespace losetup runs,
the real request from loopback device seems always come from init ns,
thus it will be in different ns running fuse backend. So the request
will got denied, because the ns running fuse won't able to see the
things from higher level(level 0 in fact) pid namespace.
I think since init pid ns has ability to access any process in the
system, it should able to access the fuse mounted by any pid namespace
process as well.
What you think?
--Sheng
>
> File locking changes based on previous work done by Eric
> Biederman.
>
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> Acked-by: Miklos Szeredi <mszeredi@redhat.com>
> ---
> fs/fuse/dev.c | 19 +++++++++++++++----
> fs/fuse/file.c | 22 +++++++++++++++++-----
> fs/fuse/fuse_i.h | 4 ++++
> fs/fuse/inode.c | 3 +++
> 4 files changed, 39 insertions(+), 9 deletions(-)
>
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index cbece1221417..4e91b2ac25a7 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -19,6 +19,7 @@
> #include <linux/pipe_fs_i.h>
> #include <linux/swap.h>
> #include <linux/splice.h>
> +#include <linux/sched.h>
>
> MODULE_ALIAS_MISCDEV(FUSE_MINOR);
> MODULE_ALIAS("devname:fuse");
> @@ -124,11 +125,11 @@ static void __fuse_put_request(struct fuse_req *req)
> atomic_dec(&req->count);
> }
>
> -static void fuse_req_init_context(struct fuse_req *req)
> +static void fuse_req_init_context(struct fuse_conn *fc, struct fuse_req *req)
> {
> req->in.h.uid = from_kuid_munged(&init_user_ns, current_fsuid());
> req->in.h.gid = from_kgid_munged(&init_user_ns, current_fsgid());
> - req->in.h.pid = current->pid;
> + req->in.h.pid = pid_nr_ns(task_pid(current), fc->pid_ns);
> }
>
> void fuse_set_initialized(struct fuse_conn *fc)
> @@ -181,10 +182,14 @@ static struct fuse_req *__fuse_get_req(struct fuse_conn *fc, unsigned npages,
> goto out;
> }
>
> - fuse_req_init_context(req);
> + fuse_req_init_context(fc, req);
> __set_bit(FR_WAITING, &req->flags);
> if (for_background)
> __set_bit(FR_BACKGROUND, &req->flags);
> + if (req->in.h.pid == 0) {
> + fuse_put_request(fc, req);
> + return ERR_PTR(-EOVERFLOW);
> + }
>
> return req;
>
> @@ -274,7 +279,7 @@ struct fuse_req *fuse_get_req_nofail_nopages(struct fuse_conn *fc,
> if (!req)
> req = get_reserved_req(fc, file);
>
> - fuse_req_init_context(req);
> + fuse_req_init_context(fc, req);
> __set_bit(FR_WAITING, &req->flags);
> __clear_bit(FR_BACKGROUND, &req->flags);
> return req;
> @@ -1243,6 +1248,9 @@ static ssize_t fuse_dev_do_read(struct fuse_dev *fud, struct file *file,
> struct fuse_in *in;
> unsigned reqsize;
>
> + if (task_active_pid_ns(current) != fc->pid_ns)
> + return -EIO;
> +
> restart:
> spin_lock(&fiq->waitq.lock);
> err = -EAGAIN;
> @@ -1872,6 +1880,9 @@ static ssize_t fuse_dev_do_write(struct fuse_dev *fud,
> struct fuse_req *req;
> struct fuse_out_header oh;
>
> + if (task_active_pid_ns(current) != fc->pid_ns)
> + return -EIO;
> +
> if (nbytes < sizeof(struct fuse_out_header))
> return -EINVAL;
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 719924d6c706..b5c616c5ec98 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -2067,7 +2067,8 @@ static int fuse_direct_mmap(struct file *file, struct vm_area_struct *vma)
> return generic_file_mmap(file, vma);
> }
>
> -static int convert_fuse_file_lock(const struct fuse_file_lock *ffl,
> +static int convert_fuse_file_lock(struct fuse_conn *fc,
> + const struct fuse_file_lock *ffl,
> struct file_lock *fl)
> {
> switch (ffl->type) {
> @@ -2082,7 +2083,14 @@ static int convert_fuse_file_lock(const struct fuse_file_lock *ffl,
>
> fl->fl_start = ffl->start;
> fl->fl_end = ffl->end;
> - fl->fl_pid = ffl->pid;
> +
> + /*
> + * Convert pid into the caller's pid namespace. If the pid
> + * does not map into the namespace fl_pid will get set to 0.
> + */
> + rcu_read_lock();
> + fl->fl_pid = pid_vnr(find_pid_ns(ffl->pid, fc->pid_ns));
> + rcu_read_unlock();
> break;
>
> default:
> @@ -2131,7 +2139,7 @@ static int fuse_getlk(struct file *file, struct file_lock *fl)
> args.out.args[0].value = &outarg;
> err = fuse_simple_request(fc, &args);
> if (!err)
> - err = convert_fuse_file_lock(&outarg.lk, fl);
> + err = convert_fuse_file_lock(fc, &outarg.lk, fl);
>
> return err;
> }
> @@ -2143,7 +2151,8 @@ static int fuse_setlk(struct file *file, struct file_lock *fl, int flock)
> FUSE_ARGS(args);
> struct fuse_lk_in inarg;
> int opcode = (fl->fl_flags & FL_SLEEP) ? FUSE_SETLKW : FUSE_SETLK;
> - pid_t pid = fl->fl_type != F_UNLCK ? current->tgid : 0;
> + struct pid *pid = fl->fl_type != F_UNLCK ? task_tgid(current) : NULL;
> + pid_t pid_nr = pid_nr_ns(pid, fc->pid_ns);
> int err;
>
> if (fl->fl_lmops && fl->fl_lmops->lm_grant) {
> @@ -2155,7 +2164,10 @@ static int fuse_setlk(struct file *file, struct file_lock *fl, int flock)
> if (fl->fl_flags & FL_CLOSE)
> return 0;
>
> - fuse_lk_fill(&args, file, fl, opcode, pid, flock, &inarg);
> + if (pid && pid_nr == 0)
> + return -EOVERFLOW;
> +
> + fuse_lk_fill(&args, file, fl, opcode, pid_nr, flock, &inarg);
> err = fuse_simple_request(fc, &args);
>
> /* locking is restartable */
> diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
> index eddbe02c4028..9145445a759a 100644
> --- a/fs/fuse/fuse_i.h
> +++ b/fs/fuse/fuse_i.h
> @@ -23,6 +23,7 @@
> #include <linux/poll.h>
> #include <linux/workqueue.h>
> #include <linux/kref.h>
> +#include <linux/pid_namespace.h>
>
> /** Max number of pages that can be used in a single read request */
> #define FUSE_MAX_PAGES_PER_REQ 32
> @@ -465,6 +466,9 @@ struct fuse_conn {
> /** The group id for this mount */
> kgid_t group_id;
>
> + /** The pid namespace for this mount */
> + struct pid_namespace *pid_ns;
> +
> /** The fuse mount flags for this mount */
> unsigned flags;
>
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index 1ce67668a8e1..eade0bfa4488 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -20,6 +20,7 @@
> #include <linux/random.h>
> #include <linux/sched.h>
> #include <linux/exportfs.h>
> +#include <linux/pid_namespace.h>
>
> MODULE_AUTHOR("Miklos Szeredi <miklos@szeredi.hu>");
> MODULE_DESCRIPTION("Filesystem in Userspace");
> @@ -609,6 +610,7 @@ void fuse_conn_init(struct fuse_conn *fc)
> fc->connected = 1;
> fc->attr_version = 1;
> get_random_bytes(&fc->scramble_key, sizeof(fc->scramble_key));
> + fc->pid_ns = get_pid_ns(task_active_pid_ns(current));
> }
> EXPORT_SYMBOL_GPL(fuse_conn_init);
>
> @@ -617,6 +619,7 @@ void fuse_conn_put(struct fuse_conn *fc)
> if (atomic_dec_and_test(&fc->count)) {
> if (fc->destroy_req)
> fuse_request_free(fc->destroy_req);
> + put_pid_ns(fc->pid_ns);
> fc->release(fc);
> }
> }
> --
> 2.7.4
>
^ permalink raw reply
* Re: Cannot start array on disk
From: Bhatia Amit @ 2016-07-20 2:10 UTC (permalink / raw)
To: Phil Turmel, linux-raid@vger.kernel.org
In-Reply-To: <73583e52-ca6b-b043-cbae-02c8a122be24@turmel.org>
Hi Phil
1. The enclosure had 2 drives in RAID1, since 2013. One drive went bad early this year around Feb 2016 (Drive A). WDC gave a RMA replacement drive. I remember accessing the enclosure at least once after the RMA drive rebuilt. This drive A is the one that is still alive. The drive B went bad recently (June 2016) after which I was unable to access the system at all.
2. The drive should be around 1/3rd used i.e around 1TB out of 3TB drive should be used.
3. Connecting this drive via esata to a linux laptop, gparted shows sdc1 and sdc2 as EXT3 of 1.91GB each, and sdc3 (489MB) and sdc4 (2.72TB) as linux-raid filesystem.
4. I mounted sdc1 and sdc2 and var/log directories on both look like copy of each other:
$ ls -lart p1/var/log
total 1136
-rw-rw-rw- 1 root root 31 Dec 31 1969 master_drive_serial_number
drwxr-xr-x 2 root root 4096 Mar 24 2010 sysstat
drwxr-xr-x 2 root root 4096 Sep 16 2013 apt
-rw-rw-rw- 1 root adm 4734 Sep 16 2013 dmesg.4.gz
-rw-rw-rw- 1 root adm 4799 Sep 16 2013 dmesg.3.gz
drwxr-xr-- 2 root root 4096 Sep 16 2013 news
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.warn
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.log
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.info
-rw-r--r-- 1 root adm 0 Sep 16 2013 mail.err
-rw-r--r-- 1 root adm 0 Sep 16 2013 lpr.log
drwxr-xr-x 2 root root 4096 Sep 16 2013 apache2
-rw-rw-rw- 1 root adm 14889 May 7 2015 dmesg.0
-rw-r--r-- 1 root adm 0 May 7 2015 sshd.log
-rw-r--r-- 1 root adm 1765 May 7 2015 kern.log
-rw-r--r-- 1 root root 1504 May 7 2015 dpkg.log
-rw-r----- 1 root adm 0 Jul 1 22:38 vsftpd.log
drwxr-xr-x 3 root root 4096 Jul 1 22:38 samba
-rw-rw-rw- 1 root adm 4747 Jul 1 22:42 dmesg.2.gz
-rw-rw-rw- 1 root adm 4747 Jul 1 22:48 dmesg.1.gz
-rw-rw-rw- 1 root root 154 Jul 1 23:01 version.log
drwxr-xr-x 14 root root 4096 Jul 1 23:06 ..
-rw-r--r-- 1 root adm 75 Jul 1 23:06 wdalerts.log
-rw-r--r-- 1 root adm 15259 Jul 1 23:10 wdnas.log
-rw-r--r-- 1 root root 3067 Jul 1 23:10 forked-daapd.log
-rw-r--r-- 1 root adm 32586 Jul 1 23:11 user.log
-rw-r--r-- 1 root adm 74 Jul 1 23:11 dlna_server.log
-rw-r--r-- 1 root adm 4243 Jul 1 23:11 miocrawler.log
-rw-r--r-- 1 root adm 21531 Jul 1 23:12 mediacrawler.log
-rw-r--r-- 1 root adm 643021 Jul 2 00:02 rest_api.log.1
-rw-r--r-- 1 root adm 151111 Jul 2 00:02 messages
-rw-r--r-- 1 root adm 31328 Jul 2 02:14 daemon.log
-rw-rw-rw- 1 root root 720 Jul 2 03:00 ramlog
-rw-rw-rw- 1 root adm 15162 Jul 2 12:02 dmesg
-rw-rw-rw- 1 root root 108362 Jul 2 12:02 rest_api.log
-rw-rw-rw- 1 root root 58 Jul 2 12:02 purge.log
drwxr-xr-x 7 root root 4096 Jul 2 12:02 .
5. A grep of raid or sd or ext, on messages shows:
$ cat p1/var/log/messages | egrep -i "sd|raid|ext"
Sep 16 11:53:17 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Sep 16 11:53:17 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Sep 16 11:53:17 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Sep 16 11:53:17 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Sep 16 11:53:17 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Sep 16 11:53:17 MyBookLiveDuo kernel: sda:
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 16 11:53:17 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Sep 16 11:53:17 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Sep 16 11:53:17 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Sep 16 11:53:17 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Sep 16 11:53:17 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Sep 16 11:53:17 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: considering sdb2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sdb2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sdb1 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sda2 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: adding sda1 ...
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sda1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sda2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sdb1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: bind<sdb2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: kicking non-fresh sdb2 from array!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: unbind<sdb2>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: export_rdev(sdb2)
Sep 16 11:53:17 MyBookLiveDuo kernel: md: kicking non-fresh sdb1 from array!
Sep 16 11:53:17 MyBookLiveDuo kernel: md: unbind<sdb1>
Sep 16 11:53:17 MyBookLiveDuo kernel: md: export_rdev(sdb1)
Sep 16 11:53:17 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Sep 16 11:53:17 MyBookLiveDuo kernel: raid1: raid set md0 active with 2 out of 4 mirrors
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3-fs: recovery complete.
Sep 16 11:53:17 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 16 11:53:17 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Sep 16 11:53:25 MyBookLiveDuo kernel: md: bind<sdb3>
Sep 16 11:53:25 MyBookLiveDuo kernel: md: bind<sda3>
Sep 16 11:53:25 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Sep 16 11:53:36 MyBookLiveDuo [admin-rest-api.postinst] 09/16/13 18:53:36: test context=test
Sep 16 11:53:40 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Sep 16 11:54:02 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d1790000
Jul 1 19:39:01 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:39:01 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:39:01 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:39:01 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:01 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb1
Jul 1 19:39:02 MyBookLiveDuo kernel: md: recovery of RAID array md0
Jul 1 19:39:02 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:39:40 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:39:40 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:39:40 MyBookLiveDuo kernel: disk 3, wo:1, o:1, dev:sdb2
Jul 1 19:39:41 MyBookLiveDuo kernel: md: recovery of RAID array md0
Jul 1 19:40:18 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb1
Jul 1 19:40:18 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:42:02 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 19:42:02 MyBookLiveDuo kernel: ufsd: driver unloaded
Jul 1 19:42:26 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Jul 1 19:42:26 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Jul 1 19:42:26 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Jul 1 19:42:26 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Jul 1 19:42:26 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Jul 1 19:42:26 MyBookLiveDuo kernel: sda:
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:42:26 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Jul 1 19:42:26 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Jul 1 19:42:26 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Jul 1 19:42:26 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 1 19:42:26 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Jul 1 19:42:26 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:42:26 MyBookLiveDuo kernel: md: considering sdb2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sdb2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sdb1 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sda2 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: adding sda1 ...
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:42:26 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Jul 1 19:42:26 MyBookLiveDuo kernel: md0: WARNING: sdb2 appears to be on the same physical disk as sdb1.
Jul 1 19:42:26 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Jul 1 19:42:26 MyBookLiveDuo kernel: raid1: raid set md0 active with 4 out of 4 mirrors
Jul 1 19:42:26 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Jul 1 19:42:26 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 1 19:42:26 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Jul 1 19:42:32 MyBookLiveDuo kernel: md: bind<sdb3>
Jul 1 19:42:32 MyBookLiveDuo kernel: md: bind<sda3>
Jul 1 19:42:32 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Jul 1 19:42:40 MyBookLiveDuo [admin-rest-api.postinst] 07/02/16 02:42:40: test context=test
Jul 1 19:42:44 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Jul 1 19:43:06 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d1790000
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md0 ...
Jul 1 19:44:37 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 19:47:30 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 19:47:31 MyBookLiveDuo kernel: ufsd: driver unloaded
Jul 1 19:48:09 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Jul 1 19:48:09 MyBookLiveDuo kernel: Kernel command line: root=/dev/md0 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
Jul 1 19:48:09 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
Jul 1 19:48:09 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
Jul 1 19:48:09 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
Jul 1 19:48:09 MyBookLiveDuo kernel: sda:
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 1 19:48:09 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
Jul 1 19:48:09 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
Jul 1 19:48:09 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Jul 1 19:48:09 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Jul 1 19:48:09 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
Jul 1 19:48:09 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
Jul 1 19:48:09 MyBookLiveDuo kernel: md: considering sdb2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sdb2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sdb1 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sda2 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: adding sda1 ...
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 19:48:09 MyBookLiveDuo kernel: md: running: <sdb2><sdb1><sda2><sda1>
Jul 1 19:48:09 MyBookLiveDuo kernel: md0: WARNING: sdb2 appears to be on the same physical disk as sdb1.
Jul 1 19:48:09 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
Jul 1 19:48:09 MyBookLiveDuo kernel: raid1: raid set md0 active with 4 out of 4 mirrors
Jul 1 19:48:09 MyBookLiveDuo kernel: EXT3 FS on md0, internal journal
Jul 1 19:48:09 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 1 19:48:09 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:0.
Jul 1 19:48:13 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: unbind<sdb4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: export_rdev(sdb4)
Jul 1 19:48:13 MyBookLiveDuo kernel: md: unbind<sda4>
Jul 1 19:48:13 MyBookLiveDuo kernel: md: export_rdev(sda4)
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sdb3>
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sda3>
Jul 1 19:48:15 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 19:48:15 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 19:53:51 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
Jul 1 19:53:56 MyBookLiveDuo [wd-nas.postinst] 07/02/16 02:53:55: restore context=restore
Jul 1 19:54:00 MyBookLiveDuo [networking-general.postinst] 07/02/16 02:54:00: restore context=restore
Jul 1 19:54:01 MyBookLiveDuo [apache-php-webdav.postinst] 07/02/16 02:54:01: restore context=restore
Jul 1 19:54:06 MyBookLiveDuo [date-time.postinst] 07/02/16 02:54:06: restore context=restore
Jul 1 19:54:09 MyBookLiveDuo [alerts.postinst] 07/02/16 02:54:09: restore context=restore
Jul 1 19:54:10 MyBookLiveDuo [admin-rest-api.postinst] 07/02/16 02:54:10: restore context=restore
Jul 1 19:54:12 MyBookLiveDuo [drive-lib.postinst] 07/02/16 02:54:12: restore context=restore
Jul 1 19:54:13 MyBookLiveDuo [data-volume-config.postinst] 07/02/16 02:54:13: restore context=restore
Jul 1 19:54:14 MyBookLiveDuo [upnp-nas.postinst] 07/02/16 02:54:14: restore context=restore
Jul 1 19:54:15 MyBookLiveDuo [dlna-server-access.postinst] 07/02/16 02:54:15: restore context=restore
Jul 1 19:54:16 MyBookLiveDuo [itunes.postinst] 07/02/16 02:54:16: restore context=restore
Jul 1 19:54:17 MyBookLiveDuo [nas-safepoint.postinst] 07/02/16 02:54:17: restore context=restore
Jul 1 19:54:18 MyBookLiveDuo [webui.postinst] 07/02/16 02:54:18: restore context=restore
Jul 1 19:54:28 MyBookLiveDuo [orion-resources.postinst] 07/02/16 02:54:28: restore context=restore
Jul 1 19:54:29 MyBookLiveDuo [afp.postinst] 07/02/16 02:54:29: restore context=restore
Jul 1 19:54:29 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
Jul 1 19:55:18 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md0 ...
Jul 1 19:55:19 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
Jul 1 19:55:28 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d3b00000
Jul 1 19:55:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 2, wo:1, o:0, dev:sdb1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:55:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda1
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda2
Jul 1 19:55:31 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sdb2
Jul 1 19:55:31 MyBookLiveDuo kernel: md: unbind<sdb1>
Jul 1 19:55:31 MyBookLiveDuo kernel: md: export_rdev(sdb1)
Jul 1 19:55:32 MyBookLiveDuo kernel: md: bind<sdb1>
Jul 1 19:55:32 MyBookLiveDuo kernel: raid1: raid set md1 active with 1 out of 4 mirrors
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sda1 from md0 ...
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sda2 from md0 ...
Jul 1 19:58:57 MyBookLiveDuo kernel: md: cannot remove active disk sdb2 from md0 ...
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3-fs warning: checktime reached, running e2fsck is recommended
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3 FS on md1, internal journal
Jul 1 20:00:59 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with writeback data mode.
May 7 18:23:57 MyBookLiveDuo kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
May 7 18:23:57 MyBookLiveDuo kernel: Kernel command line: root=/dev/md1 rw rootfstype=ext3 rootflags=data=ordered console=ttyS0,115200
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x1 185 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x2 189 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x4 197 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: int32x8 189 MB/s
May 7 18:23:57 MyBookLiveDuo kernel: raid6: using algorithm int32x4 (197 MB/s)
May 7 18:23:57 MyBookLiveDuo kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
May 7 18:23:57 MyBookLiveDuo kernel: md: raid0 personality registered for level 0
May 7 18:23:57 MyBookLiveDuo kernel: md: raid1 personality registered for level 1
May 7 18:23:57 MyBookLiveDuo kernel: md: raid10 personality registered for level 10
May 7 18:23:57 MyBookLiveDuo kernel: md: raid6 personality registered for level 6
May 7 18:23:57 MyBookLiveDuo kernel: md: raid5 personality registered for level 5
May 7 18:23:57 MyBookLiveDuo kernel: md: raid4 personality registered for level 4
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write Protect is off
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
May 7 18:23:57 MyBookLiveDuo kernel: sda:
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
May 7 18:23:57 MyBookLiveDuo kernel: sdb:apm82181 adma3: allocated 512 descriptor slots
May 7 18:23:57 MyBookLiveDuo kernel: sda1 sda2 sda3 sda4
May 7 18:23:57 MyBookLiveDuo kernel: sdb1 sdb2 sdb3 sdb4
May 7 18:23:57 MyBookLiveDuo kernel: sd 0:0:0:0: [sda] Attached SCSI disk
May 7 18:23:57 MyBookLiveDuo kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
May 7 18:23:57 MyBookLiveDuo kernel: md: If you don't use raid, use raid=noautodetect
May 7 18:23:57 MyBookLiveDuo kernel: md: Autodetecting RAID arrays.
May 7 18:23:57 MyBookLiveDuo kernel: md: sda3 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sda4 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb3 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb4 does not have a valid v0.90 superblock, not importing!
May 7 18:23:57 MyBookLiveDuo kernel: md: considering sdb2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sdb2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: sdb1 has different UUID to sdb2
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sda2 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sda1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sda1>
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sda2>
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sdb2>
May 7 18:23:57 MyBookLiveDuo kernel: md: running: <sdb2><sda2><sda1>
May 7 18:23:57 MyBookLiveDuo kernel: md0: WARNING: sda2 appears to be on the same physical disk as sda1.
May 7 18:23:57 MyBookLiveDuo kernel: raid1: raid set md0 active with 3 out of 4 mirrors
May 7 18:23:57 MyBookLiveDuo kernel: md: considering sdb1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: adding sdb1 ...
May 7 18:23:57 MyBookLiveDuo kernel: md: bind<sdb1>
May 7 18:23:57 MyBookLiveDuo kernel: md: running: <sdb1>
May 7 18:23:57 MyBookLiveDuo kernel: raid1: raid set md1 active with 1 out of 4 mirrors
May 7 18:23:57 MyBookLiveDuo kernel: EXT3 FS on md1, internal journal
May 7 18:23:57 MyBookLiveDuo kernel: EXT3-fs: mounted filesystem with ordered data mode.
May 7 18:23:57 MyBookLiveDuo kernel: VFS: Mounted root (ext3 filesystem) on device 9:1.
May 7 18:24:01 MyBookLiveDuo kernel: md: bind<sdb3>
May 7 18:24:01 MyBookLiveDuo kernel: md: bind<sda3>
May 7 18:24:01 MyBookLiveDuo kernel: raid1: raid set md2 active with 2 out of 2 mirrors
May 7 18:24:02 MyBookLiveDuo kernel: md: bind<sdb4>
May 7 18:24:02 MyBookLiveDuo kernel: md: bind<sda4>
May 7 18:24:02 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
May 7 18:24:10 MyBookLiveDuo [admin-rest-api.postinst] 05/08/15 01:24:10: test context=test
May 7 18:24:14 MyBookLiveDuo kernel: Adding 500544k swap on /dev/md2. Priority:-1 extents:1 across:500544k
May 7 18:24:23 MyBookLiveDuo [dlna-server-access.postinst] 05/08/15 01:24:23: configure 02.00.00-100316 context=upgrade
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: bad vermagic: kernel tainted.
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: module license 'unspecified' taints kernel.
May 7 18:24:52 MyBookLiveDuo kernel: ufsd: driver 8.5 (NTFS4LINUX_U85_014_S[2011-09-15-11:41:06]) LBD=ON with delayalloc with ioctl loaded at d2750000
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sdb2>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sdb2)
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sda2>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sda2)
Jul 1 20:06:48 MyBookLiveDuo kernel: md: unbind<sda1>
Jul 1 20:06:48 MyBookLiveDuo kernel: md: export_rdev(sda1)
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sda1>
Jul 1 20:06:50 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:06:50 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:06:50 MyBookLiveDuo kernel: disk 1, wo:1, o:1, dev:sda1
Jul 1 20:06:50 MyBookLiveDuo kernel: md: recovery of RAID array md1
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sda2>
Jul 1 20:06:50 MyBookLiveDuo kernel: md: cannot remove active disk sdb1 from md1 ...
Jul 1 20:06:50 MyBookLiveDuo kernel: md: bind<sdb2>
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb2
Jul 1 20:07:31 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 2, wo:1, o:1, dev:sdb2
Jul 1 20:07:31 MyBookLiveDuo kernel: disk 3, wo:1, o:1, dev:sda2
Jul 1 20:07:31 MyBookLiveDuo kernel: md: recovery of RAID array md1
Jul 1 20:08:39 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sdb1
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 1, wo:0, o:1, dev:sda1
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 2, wo:0, o:1, dev:sdb2
Jul 1 20:08:39 MyBookLiveDuo kernel: disk 3, wo:0, o:1, dev:sda2
Jul 1 20:09:54 MyBookLiveDuo kernel: nfsd: last server has exited, flushing export cache
Jul 1 20:10:49 MyBookLiveDuo kernel: md: unbind<sda4>
Jul 1 20:10:49 MyBookLiveDuo kernel: md: export_rdev(sda4)
Jul 1 20:10:49 MyBookLiveDuo kernel: md: unbind<sdb4>
Jul 1 20:10:49 MyBookLiveDuo kernel: md: export_rdev(sdb4)
Jul 1 20:10:51 MyBookLiveDuo kernel: md: bind<sda4>
Jul 1 20:10:51 MyBookLiveDuo kernel: raid1: raid set md3 active with 1 out of 2 mirrors
Jul 1 20:10:51 MyBookLiveDuo kernel: md: bind<sdb4>
Jul 1 20:10:51 MyBookLiveDuo kernel: RAID1 conf printout:
Jul 1 20:10:51 MyBookLiveDuo kernel: disk 0, wo:0, o:1, dev:sda4
Jul 1 20:10:51 MyBookLiveDuo kernel: disk 1, wo:1, o:1, dev:sdb4
Jul 1 20:10:51 MyBookLiveDuo kernel: md: recovery of RAID array md3
Jul 1 20:10:51 MyBookLiveDuo kernel: EXT4-fs (md3): mounted filesystem with ordered data mode
The messages file has 1922 lines, so I am not pasting the whole content here yet, unless you suggest.
6. Trying to mount sdc4 as ext4 fails:
$ sudo mount -t ext4 /dev/sdc4 p4
mount: /dev/sdc4 already mounted or p4 busy
Is there a way to confirm whether sdc4 was ext4 (as r-linux) had reported, or ext3?
7. Before trying to do fsck on sdc4, I wanted to check if you had any other suggestion based on info above. Also, looks like for fsck I should be providing filesystem type. So, wanted to check if I should try ext3 or ext4 on sdc4, when trying fsck.
Thanks
Amit
----- Original Message -----
From: Phil Turmel <philip@turmel.org>
To: Bhatia Amit <amitbhatia@rocketmail.com>; "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Sent: Tuesday, July 19, 2016 5:12 AM
Subject: Re: Cannot start array on disk
On 07/17/2016 03:59 PM, Bhatia Amit wrote:
> Hi
>
> I have a WD Live duo setup with two 3TB drives in RAID1. After a
> recent power surge etc, I could not access the enclosure data. I
> removed the drives out from the enclosure and connected them via
> esata cable to a Linux laptop. One of the drives had physical noise
> and failed to connect at all. The other drive was able to connect and
> showed up as /dev/sdc. Following some online search, I issued the
> following commands to get some results, but am unable to mount the
> drive to a linux laptop via esata. Questions:
>
> * Ideally both sdc3 and sdc4 should have shown RAID=RAID1. If sdc4 is
> showing RAID=linear, is it because the other drive went totally bad,
> and software decided to reconfigure this drive from RAID1 to linear
> ?
No way to know. I would be inclined to believe that that you didn't
actually have raid1 set for those partitions. Do you recall the
available space in that device while running?
> * Given the one of the two drives is totally dead, is it still
> possible to reconfigure, mount and recover data from the single
> drive?
If truly linear, no, not past the half-way mark. The device is
identified as role 0, so it would be the beginning of the filesystem in
a linear array. If it really was raid1 with v0.9 or v1.0 metadata, you
can mount /dev/sdc4 directly to access your data. That it doesn't show
a detected filesystem suggests that it wasn't raid1.
Even worse, that partition shows a creation date and update date both in
2013, with no events. Suggesting that the device hasn't actually been
running properly in the array since its initial creation.
> * I tried scanning the drive via r-linux and it does show files
> exist, but does not show any folder information. So data is there on
> the drive. Is there a way to recreate the setup with just this single
> drive, so that I can extract files with folder information?
With v1.0 metadata, you should be able to fsck /dev/sdc4 and then mount.
Kinda dangerous though -- I suggest you use an overlay for that. I
suspect that sdc4 hasn't been running in your array for the past three
years.
> * Looking at an online "derrick" script, the script seems to call
> mdadm create with the "missing" flag. Is that something I should be
> doing to be able to assemble and recover data from the drive ?
> "mdadm --create $rootfsRaid --verbose --metadata=0.9 --raid-devices=2
> --level=raid1 --run $diskRoot1 missing"
No.
Using --create is practically never the right solution, unless you've
done operations that destroy the right solution. Metadata v0.9 is
almost certainly wrong.
If you have syslogs on your other array that show the boot details from
the last successful boot *before* it died, that might provide the
details needed to figure if anything recent is on sdc4.
Phil
^ permalink raw reply
* Re: a hard lockup in md raid5 sequential write (v4.7-rc7)
From: Shaohua Li @ 2016-07-19 23:35 UTC (permalink / raw)
To: Coly Li; +Cc: linux-raid
In-Reply-To: <cd2e1d88-683c-81f7-c1e7-674d04ccdda1@suse.de>
On Mon, Jul 18, 2016 at 04:55:04PM +0800, Coly Li wrote:
> Hi,
>
> These days I observe a hard lockup in md raid5. This issue can be easily
> reproduced in kernel v4.7-rc7 (up to commit:
> 47ef4ad2684d380dd6d596140fb79395115c3950) by this fio job file:
>
> [global]
> direct=1
> thread=1
> [job]
> filename=/dev/md0
> blocksize=8m
> rw=write
> name=raid5
> lockmem=1
> numjobs=40
> write_bw_log=example
> group_reporting=1
> norandommap=1
> log_avg_msec=0
> runtime=600.0
> iodepth=64
> write_lat_log=example
>
> Where md0 is a raid5 target assembled by 3 Memblaze (PBlaze3) PCIe SSDs.
> This test runs on a dual 10-core processors Dell T7910 machine.
>
> From the crash dump, dmesg of the panic by nmi watchdog timeout is,
>
> [ 2330.544036] NMI watchdog: Watchdog detected hard LOCKUP on cpu
> 18.dModules linked in: raid456 async_raid6_recov async_memcpy libcrc32c
> async_pq async_xor async_tx joydev st memdisk(O) memcon(O) af_packet
> iscsi_ibft iscsi_boot_sysfs msr snd_hda_codec_hdmi intel_rapl sb_edac
> raid1 edac_core x86_pkg_temp_thermal intel_powerclamp coretemp raid0
> md_mod snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm
> snd_hda_intel irqbypass snd_hda_codec crct10dif_pclmul snd_hda_core
> crc32_pclmul ghash_clmulni_intel snd_hwdep dm_mod aesni_intel aes_x86_64
> snd_pcm mei_wdt e1000e igb iTCO_wdt lrw dcdbas iTCO_vendor_support
> snd_timer gf128mul mei_me dell_smm_hwmon glue_helper serio_raw
> ablk_helper cryptd snd lpc_ich pcspkr ptp i2c_i801 mei mptctl dca
> mfd_core pps_core soundcore mptbase shpchp fjes tpm_tis tpm btrfs xor
> raid6_pq hid_generic usbhid crc32c_intel nouveau video mxm_wmi
> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt xhci_pci
> fb_sys_fops ehci_pci xhci_hcd ehci_hcd sr_mod ttm cd
> [ 2330.544036] CPU: 18 PID: 30308 Comm: kworker/u42:4 Tainted: G
> O 4.7.0-rc7-vanilla #1
> [ 2330.544036] Hardware name: Dell Inc. Precision Tower 7910/0215PR,
> BIOS A07 04/14/2015
> [ 2330.544036] Workqueue: raid5wq raid5_do_work [raid456]
> [ 2330.544036] 0000000000000000 ffff88103f405bb0 ffffffff813a6eea
> 0000000000000000
> [ 2330.544036] 0000000000000000 ffff88103f405bc8 ffffffff8113c3e8
> ffff8808dc7d8800
> [ 2330.544036] ffff88103f405c00 ffffffff81180f8c 0000000000000001
> ffff88103f40a440
> [ 2330.544036] Call Trace:
> [ 2330.544036] <NMI> [<ffffffff813a6eea>] dump_stack+0x63/0x89
> [ 2330.544036] [<ffffffff8113c3e8>] watchdog_overflow_callback+0xc8/0xf0
> [ 2330.544036] [<ffffffff81180f8c>] __perf_event_overflow+0x7c/0x1b0
> [ 2330.544036] [<ffffffff8118b644>] perf_event_overflow+0x14/0x20
> [ 2330.544036] [<ffffffff8100bf57>] intel_pmu_handle_irq+0x1c7/0x460
> [ 2330.544036] [<ffffffff810053ad>] perf_event_nmi_handler+0x2d/0x50
> [ 2330.544036] [<ffffffff810312e1>] nmi_handle+0x61/0x140
> [ 2330.544036] [<ffffffff81031888>] default_do_nmi+0x48/0x130
> [ 2330.544036] [<ffffffff81031a5b>] do_nmi+0xeb/0x160
> [ 2330.544036] [<ffffffff816e5c71>] end_repeat_nmi+0x1a/0x1e
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] <<EOE>> [<ffffffff81193bbf>]
> queued_spin_lock_slowpath+0xb/0xf
> [ 2330.544036] [<ffffffff816e31ff>] _raw_spin_lock_irq+0x2f/0x40
> [ 2330.544036] [<ffffffffa084c5d8>]
> handle_active_stripes.isra.51+0x378/0x4f0 [raid456]
> [ 2330.544036] [<ffffffffa083f1a6>] ?
> raid5_wakeup_stripe_thread+0x96/0x1b0 [raid456]
> [ 2330.544036] [<ffffffffa084cf1d>] raid5_do_work+0x8d/0x120 [raid456]
> [ 2330.544036] [<ffffffff8109b5bb>] process_one_work+0x14b/0x450
> [ 2330.544036] [<ffffffff8109b9eb>] worker_thread+0x12b/0x490
> [ 2330.544036] [<ffffffff8109b8c0>] ? process_one_work+0x450/0x450
> [ 2330.544036] [<ffffffff810a1599>] kthread+0xc9/0xe0
> [ 2330.544036] [<ffffffff816e3a9f>] ret_from_fork+0x1f/0x40
> [ 2330.544036] [<ffffffff810a14d0>] ? kthread_create_on_node+0x180/0x180
> [ 2330.544036] Kernel panic - not syncing: Hard LOCKUP
> [ 2330.544036] CPU: 18 PID: 30308 Comm: kworker/u42:4 Tainted: G
> O 4.7.0-rc7-vanilla #1
> [ 2330.544036] Hardware name: Dell Inc. Precision Tower 7910/0215PR,
> BIOS A07 04/14/2015
> [ 2330.544036] Workqueue: raid5wq raid5_do_work [raid456]
> [ 2330.544036] 0000000000000000 ffff88103f405b28 ffffffff813a6eea
> ffffffff81a45241
> [ 2330.544036] 0000000000000000 ffff88103f405ba0 ffffffff81193642
> 0000000000000010
> [ 2330.544036] ffff88103f405bb0 ffff88103f405b50 0000000000000086
> ffffffff81a2a2e2
> [ 2330.544036] Call Trace:
> [ 2330.544036] <NMI> [<ffffffff813a6eea>] dump_stack+0x63/0x89
> [ 2330.544036] [<ffffffff81193642>] panic+0xd2/0x223
> [ 2330.544036] [<ffffffff810823af>] nmi_panic+0x3f/0x40
> [ 2330.544036] [<ffffffff8113c401>] watchdog_overflow_callback+0xe1/0xf0
> [ 2330.544036] [<ffffffff81180f8c>] __perf_event_overflow+0x7c/0x1b0
> [ 2330.544036] [<ffffffff8118b644>] perf_event_overflow+0x14/0x20
> [ 2330.544036] [<ffffffff8100bf57>] intel_pmu_handle_irq+0x1c7/0x460
> [ 2330.544036] [<ffffffff810053ad>] perf_event_nmi_handler+0x2d/0x50
> [ 2330.544036] [<ffffffff810312e1>] nmi_handle+0x61/0x140
> [ 2330.544036] [<ffffffff81031888>] default_do_nmi+0x48/0x130
> [ 2330.544036] [<ffffffff81031a5b>] do_nmi+0xeb/0x160
> [ 2330.544036] [<ffffffff816e5c71>] end_repeat_nmi+0x1a/0x1e
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] [<ffffffff810cbcc7>] ?
> native_queued_spin_lock_slowpath+0x117/0x1a0
> [ 2330.544036] <<EOE>> [<ffffffff81193bbf>]
> queued_spin_lock_slowpath+0xb/0xf
> [ 2330.544036] [<ffffffff816e31ff>] _raw_spin_lock_irq+0x2f/0x40
> [ 2330.544036] [<ffffffffa084c5d8>]
> handle_active_stripes.isra.51+0x378/0x4f0 [raid456]
> [ 2330.544036] [<ffffffffa083f1a6>] ?
> raid5_wakeup_stripe_thread+0x96/0x1b0 [raid456]
> [ 2330.544036] [<ffffffffa084cf1d>] raid5_do_work+0x8d/0x120 [raid456]
> [ 2330.544036] [<ffffffff8109b5bb>] process_one_work+0x14b/0x450
> [ 2330.544036] [<ffffffff8109b9eb>] worker_thread+0x12b/0x490
> [ 2330.544036] [<ffffffff8109b8c0>] ? process_one_work+0x450/0x450
> [ 2330.544036] [<ffffffff810a1599>] kthread+0xc9/0xe0
> [ 2330.544036] [<ffffffff816e3a9f>] ret_from_fork+0x1f/0x40
> [ 2330.544036] [<ffffffff810a14d0>] ? kthread_create_on_node+0x180/0x180
>
> The crash dump file is quite big (124MB), I need to find a method to
> share, if anyone of you wants it, please let me know.
>
> IMHO, this hard lockup seems related to bitmap allocation, because it
> can be easily reproduced on a new-created md raid5 target, with 40+
> processes doing big size (8MB+) writing.
Hi,
Sounds like a deadlock. Can you enable lockdep and run the test again and see
if lockdep gives any hint?
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH] md: Prevent IO hold during accessing to failed raid5 array
From: Shaohua Li @ 2016-07-19 22:46 UTC (permalink / raw)
To: Alexey Obitotskiy; +Cc: linux-raid
In-Reply-To: <1468589067-1966-1-git-send-email-aleksey.obitotskiy@intel.com>
On Fri, Jul 15, 2016 at 03:24:27PM +0200, Alexey Obitotskiy wrote:
> After array enters in failed state (e.g. number of failed drives
> becomes more then accepted for raid5 level) it sets error flags
> (one of this flags is MD_CHANGE_PENDING). This flag prevents to
> finish all new or non-finished IOs to array and hold them in
> pending state. In some cases this can leads to deadlock situation.
>
> For example udev handle array state changes (drives becomes faulty)
> and blkid started but unable to finish reads due to IO hold.
> At the same time we unable to get exclusive access to array
> (to stop array in our case) because another external application
> still use this array (blkid in our case).
>
> Fix makes possible to return IO with errors immediately.
> So external application can finish working with array and
> give exclusive access to other applications.
>
> Signed-off-by: Alexey Obitotskiy <aleksey.obitotskiy@intel.com>
> ---
> drivers/md/raid5.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 6c1149d..99471b6 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -4692,7 +4692,9 @@ finish:
> }
>
> if (!bio_list_empty(&s.return_bi)) {
> - if (test_bit(MD_CHANGE_PENDING, &conf->mddev->flags)) {
> + if (test_bit(MD_CHANGE_PENDING, &conf->mddev->flags) &&
> + (s.failed <= conf->max_degraded ||
> + conf->mddev->external == 0)) {
> spin_lock_irq(&conf->device_lock);
> bio_list_merge(&conf->return_bi, &s.return_bi);
> spin_unlock_irq(&conf->device_lock);
> --
> 2.7.4
Hi Alexey,
I'm not clear about the race. When we set the MD_CHANGE_PENDING, we will
schedule superblock write, which will eventually finish (either success or
timedout). Why will the IO be hold forever?
Thanks,
Shaohua
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Amit Biswas @ 2016-07-19 22:34 UTC (permalink / raw)
To: Wols Lists; +Cc: linux-raid
In-Reply-To: <578E8616.4000908@youngman.org.uk>
Here are the smart reports for all six drives. drive sda was not co-operating...
/dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: /2:0:0:0
Product:
User Capacity: 600,332,565,813,390,450 bytes [600 PB]
Logical block size: 774843950 bytes
>> Terminate command early due to bad response to IEC mode page
=== START OF READ SMART DATA SECTION ===
Error Counter logging not supported
Device does not support Self Test logging
/dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-9YN162
Serial Number: Z1D05TKG
LU WWN Device Id: 5 000c50 03ec23134
Firmware Version: CC9C
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:22 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 575) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 116) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3081) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail
Always - 205143226
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 152
5 Reallocated_Sector_Ct 0x0033 095 095 036 Pre-fail
Always - 7808
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail
Always - 4573741014
9 Power_On_Hours 0x0032 067 067 000 Old_age
Always - 29429
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 151
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age
Always - 0
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age
Always - 4 5 5
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 069 035 045 Old_age
Always In_the_past 31 (0 101 31 30 0)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 149
193 Load_Cycle_Count 0x0032 087 087 000 Old_age
Always - 26214
194 Temperature_Celsius 0x0022 031 065 000 Old_age
Always - 31 (0 14 0 0 0)
197 Current_Pending_Sector 0x0012 080 080 000 Old_age
Always - 3359
198 Offline_Uncorrectable 0x0010 080 080 000 Old_age
Offline - 3359
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age
Offline - 15576h+39m+12.722s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age
Offline - 42665052319107
242 Total_LBAs_Read 0x0000 100 253 000 Old_age
Offline - 234087115868324
SMART Error Log Version: 1
ATA Error Count: 342 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 342 occurred at disk power-on lifetime: 29429 hours (1226 days + 5 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 09 f8 0e 00 Error: UNC at LBA = 0x000ef809 = 981001
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 08 f8 0e 40 00 02:57:13.845 READ FPDMA QUEUED
60 00 08 00 f8 0e 40 00 02:57:13.845 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 02:57:13.844 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 02:57:13.844 READ FPDMA QUEUED
b0 da 00 00 4f c2 00 00 02:49:00.670 SMART RETURN STATUS
Error 341 occurred at disk power-on lifetime: 29429 hours (1226 days + 5 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 09 f8 0e 00 Error: UNC at LBA = 0x000ef809 = 981001
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 08 f8 0e 40 00 02:57:13.845 READ FPDMA QUEUED
60 00 08 00 f8 0e 40 00 02:57:13.845 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 02:57:13.844 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 02:57:13.844 READ FPDMA QUEUED
b0 da 00 00 4f c2 00 00 02:49:00.670 SMART RETURN STATUS
Error 340 occurred at disk power-on lifetime: 29428 hours (1226 days + 4 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 09 f8 0e 00 Error: UNC at LBA = 0x000ef809 = 981001
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 08 f8 0e 40 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 00 f8 0e 40 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 01:36:54.469 READ FPDMA QUEUED
60 00 08 08 10 00 40 00 01:36:12.430 READ FPDMA QUEUED
Error 339 occurred at disk power-on lifetime: 29428 hours (1226 days + 4 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 09 f8 0e 00 Error: UNC at LBA = 0x000ef809 = 981001
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 08 f8 0e 40 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 00 f8 0e 40 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 01:36:54.470 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 01:36:54.469 READ FPDMA QUEUED
60 00 08 08 10 00 40 00 01:36:12.430 READ FPDMA QUEUED
Error 338 occurred at disk power-on lifetime: 29427 hours (1226 days + 3 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 09 f8 0e 00 Error: UNC at LBA = 0x000ef809 = 981001
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 08 f8 0e 40 00 01:28:40.063 READ FPDMA QUEUED
60 00 08 08 00 00 40 00 01:28:37.685 READ FPDMA QUEUED
60 00 08 08 08 00 40 00 01:28:37.685 READ FPDMA QUEUED
60 00 08 08 10 00 40 00 01:28:37.684 READ FPDMA QUEUED
ef 10 02 00 00 00 a0 00 01:28:37.684 SET FEATURES [Enable SATA feature]
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 1 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sdc
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Constellation ES (SATA 6Gb/s)
Device Model: ST1000NM0011
Serial Number: Z1N4DQG8
LU WWN Device Id: 5 000c50 064169d91
Firmware Version: SN03
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7202 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:31 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 600) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 149) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x10bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 069 064 044 Pre-fail
Always - 10352612
3 Spin_Up_Time 0x0003 096 096 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 21
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail
Always - 129759408
9 Power_On_Hours 0x0032 080 080 000 Old_age
Always - 17545
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 21
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
188 Command_Timeout 0x0032 100 099 000 Old_age
Always - 3
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 069 062 045 Old_age
Always - 31 (Min/Max 30/31)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 16
193 Load_Cycle_Count 0x0032 096 096 000 Old_age
Always - 9383
194 Temperature_Celsius 0x0022 031 040 000 Old_age
Always - 31 (0 14 0 0 0)
195 Hardware_ECC_Recovered 0x001a 105 100 000 Old_age
Always - 10352612
197 Current_Pending_Sector 0x0012 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 199 000 Old_age
Always - 66
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sdc
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Constellation ES (SATA 6Gb/s)
Device Model: ST1000NM0011
Serial Number: Z1N4DQG8
LU WWN Device Id: 5 000c50 064169d91
Firmware Version: SN03
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7202 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:31 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 600) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 149) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x10bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 069 064 044 Pre-fail
Always - 10352612
3 Spin_Up_Time 0x0003 096 096 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 21
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail
Always - 129759408
9 Power_On_Hours 0x0032 080 080 000 Old_age
Always - 17545
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 21
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
188 Command_Timeout 0x0032 100 099 000 Old_age
Always - 3
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 069 062 045 Old_age
Always - 31 (Min/Max 30/31)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 16
193 Load_Cycle_Count 0x0032 096 096 000 Old_age
Always - 9383
194 Temperature_Celsius 0x0022 031 040 000 Old_age
Always - 31 (0 14 0 0 0)
195 Hardware_ECC_Recovered 0x001a 105 100 000 Old_age
Always - 10352612
197 Current_Pending_Sector 0x0012 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 199 000 Old_age
Always - 66
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sdd
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Constellation ES (SATA 6Gb/s)
Device Model: ST1000NM0011
Serial Number: Z1N4DX3G
LU WWN Device Id: 5 000c50 06416d153
Firmware Version: SN03
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7202 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:38 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 609) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 153) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x10bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 078 063 044 Pre-fail
Always - 59676424
3 Spin_Up_Time 0x0003 096 094 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 64
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 083 060 030 Pre-fail
Always - 202527202
9 Power_On_Hours 0x0032 074 074 000 Old_age
Always - 23267
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 60
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age
Always - 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 067 032 045 Old_age
Always In_the_past 33 (0 111 33 31 0)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 51
193 Load_Cycle_Count 0x0032 095 095 000 Old_age
Always - 10161
194 Temperature_Celsius 0x0022 033 068 000 Old_age
Always - 33 (0 16 0 0 0)
195 Hardware_ECC_Recovered 0x001a 114 099 000 Old_age
Always - 59676424
197 Current_Pending_Sector 0x0012 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 478 -
# 2 Extended offline Aborted by host 80% 462 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sde
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-1CH162
Serial Number: S1D8EGH8
LU WWN Device Id: 5 000c50 05c135595
Firmware Version: CC46
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:46 2016 UTC
==> WARNING: A firmware update for this drive is available,
see the following Seagate web pages:
http://knowledge.seagate.com/articles/en_US/FAQ/207931en
http://knowledge.seagate.com/articles/en_US/FAQ/223651en
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 575) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 115) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3085) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail
Always - 203719328
3 Spin_Up_Time 0x0003 098 097 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 122
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 081 060 030 Pre-fail
Always - 156895542
9 Power_On_Hours 0x0032 068 068 000 Old_age
Always - 28487
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 121
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age
Always - 0
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age
Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age
Always - 0 0 0
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 071 033 045 Old_age
Always In_the_past 29 (0 200 29 27 0)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 119
193 Load_Cycle_Count 0x0032 095 095 000 Old_age
Always - 11202
194 Temperature_Celsius 0x0022 029 067 000 Old_age
Always - 29 (0 11 0 0 0)
197 Current_Pending_Sector 0x0012 100 100 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age
Offline - 27611h+29m+28.145s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age
Offline - 10984310419
242 Total_LBAs_Read 0x0000 100 253 000 Old_age
Offline - 42457231761
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sdf
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.2.0-27-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-9YN162
Serial Number: Z1D04N3L
LU WWN Device Id: 5 000c50 03633f4d6
Firmware Version: CC9C
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Jul 7 18:58:53 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test
routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 584) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 115) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3081) SCT Status supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 089 087 006 Pre-fail
Always - 107847548
3 Spin_Up_Time 0x0003 098 097 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 148
5 Reallocated_Sector_Ct 0x0033 072 051 036 Pre-fail
Always - 37616
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail
Always - 235958313
9 Power_On_Hours 0x0032 066 066 000 Old_age
Always - 30474
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 147
183 Runtime_Bad_Block 0x0032 098 098 000 Old_age
Always - 2
184 End-to-End_Error 0x0032 100 100 099 Old_age
Always - 0
187 Reported_Uncorrect 0x0032 001 001 000 Old_age
Always - 587
188 Command_Timeout 0x0032 100 098 000 Old_age
Always - 13 13 13
189 High_Fly_Writes 0x003a 100 100 000 Old_age
Always - 0
190 Airflow_Temperature_Cel 0x0022 069 034 045 Old_age
Always In_the_past 31 (0 102 31 29 0)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age
Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 145
193 Load_Cycle_Count 0x0032 088 088 000 Old_age
Always - 24193
194 Temperature_Celsius 0x0022 031 066 000 Old_age
Always - 31 (0 13 0 0 0)
197 Current_Pending_Sector 0x0012 001 001 000 Old_age
Always - 33664
198 Offline_Uncorrectable 0x0010 001 001 000 Old_age
Offline - 33664
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age
Offline - 29478h+42m+45.934s
241 Total_LBAs_Written 0x0000 100 253 000 Old_age
Offline - 35126025198006
242 Total_LBAs_Read 0x0000 100 253 000 Old_age
Offline - 233821549666301
SMART Error Log Version: 1
ATA Error Count: 561 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 561 occurred at disk power-on lifetime: 28893 hours (1203 days + 21 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 00 ff ff ff 4f 00 12d+01:32:01.326 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 12d+01:32:01.325 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 12d+01:32:01.325 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 12d+01:32:01.325 READ FPDMA QUEUED
60 00 00 ff ff ff 4f 00 12d+01:32:01.325 READ FPDMA QUEUED
Error 560 occurred at disk power-on lifetime: 28893 hours (1203 days + 21 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 12d+01:31:16.334 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:15.803 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:13.683 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:13.683 READ FPDMA QUEUED
61 00 08 ff ff ff 4f 00 12d+01:31:13.683 WRITE FPDMA QUEUED
Error 559 occurred at disk power-on lifetime: 28893 hours (1203 days + 21 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 12d+01:31:10.402 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:07.982 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:07.982 READ FPDMA QUEUED
61 00 08 ff ff ff 4f 00 12d+01:31:07.982 WRITE FPDMA QUEUED
ef 10 02 00 00 00 a0 00 12d+01:31:07.922 SET FEATURES [Enable SATA feature]
Error 558 occurred at disk power-on lifetime: 28893 hours (1203 days + 21 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 12d+01:31:04.755 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:04.755 READ FPDMA QUEUED
61 00 08 ff ff ff 4f 00 12d+01:31:04.755 WRITE FPDMA QUEUED
ef 10 02 00 00 00 a0 00 12d+01:31:04.694 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 e0 00 12d+01:31:04.694 READ NATIVE MAX ADDRESS
EXT [OBS-ACS-3]
Error 557 occurred at disk power-on lifetime: 28893 hours (1203 days + 21 hours)
When the command that caused the error occurred, the device was
active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 08 ff ff ff 4f 00 12d+01:31:01.457 READ FPDMA QUEUED
60 00 08 ff ff ff 4f 00 12d+01:31:01.457 READ FPDMA QUEUED
61 00 08 ff ff ff 4f 00 12d+01:31:01.457 WRITE FPDMA QUEUED
ef 10 02 00 00 00 a0 00 12d+01:31:01.444 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 e0 00 12d+01:31:01.444 READ NATIVE MAX ADDRESS
EXT [OBS-ACS-3]
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 1 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Amit Biswas
Lab Manager
CSE Department
NYU Tandon School Of Engineering
Office: 1-646-997-3023
On Tue, Jul 19, 2016 at 3:57 PM, Wols Lists <antlists@youngman.org.uk> wrote:
> Another bit of useful information - can you post the output of smartctl
> on all your drives?
>
> smartctl -x /dev/sd[a,b,c...]
>
> Seeing as the drives are Seagate 1TB drives, I suspect they do support
> ERC and timeout mismatch is not the problem, but this will tell us.
>
> I'll let others chime in with recovery info, but this information will
> definitely help them.
>
> Cheers,
> Wol
>
> On 19/07/16 17:29, Amit Biswas wrote:
>> Greetings!
>>
>> Backup server was acting up and the issue was the drives (all of them)
>> :( Could use some guidance or verdict.
>>
>> It has a total of 6 drives: sda,b,c,d,e,f. From the superblock info
>> (attached), there is a raid 1, and a raid 10 volume. Problem is all
>> the disks are part of both raid volumes (according to superblock).
>>
>> I am currently booted into an ubuntu live disk shell.
>>
>
^ permalink raw reply
* Re: [PATCH] raid10: improve random reads performance
From: Shaohua Li @ 2016-07-19 22:20 UTC (permalink / raw)
To: Tomasz Majchrzak; +Cc: linux-raid
In-Reply-To: <1466770816-5227-1-git-send-email-tomasz.majchrzak@intel.com>
On Fri, Jun 24, 2016 at 02:20:16PM +0200, Tomasz Majchrzak wrote:
> RAID10 random read performance is lower than expected due to excessive spinlock
> utilisation which is required mostly for rebuild/resync. Simplify allow_barrier
> as it's in IO path and encounters a lot of unnecessary congestion.
>
> As lower_barrier just takes a lock in order to decrement a counter, convert
> counter (nr_pending) into atomic variable and remove the spin lock. There is
> also a congestion for wake_up (it uses lock internally) so call it only when
> it's really needed. As wake_up is not called constantly anymore, ensure process
> waiting to raise a barrier is notified when there are no more waiting IOs.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Patch looks good, applied. Do you have data how this improves the performance?
Thanks,
Shaohua
^ permalink raw reply
* Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().
From: NeilBrown @ 2016-07-19 22:19 UTC (permalink / raw)
To: Alexander Lyakas
Cc: 马建朋, linux-raid, Jes Sorensen, Shaohua Li
In-Reply-To: <CAGRgLy6QhpWr5f07w3jT04oX4aA-aKTAr44JOih-DkK+dn5ABQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5330 bytes --]
On Tue, Jul 19 2016, Alexander Lyakas wrote:
> Hello Neil,
> Thank you for your response.
>
> On Fri, Jul 15, 2016 at 2:18 AM, NeilBrown <neilb@suse.com> wrote:
>> On Thu, Jul 14 2016, Alexander Lyakas wrote:
>>
>>>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
>>>> index 32e282f4c83c..c528102b80b6 100644
>>>> --- a/drivers/md/raid10.c
>>>> +++ b/drivers/md/raid10.c
>>>> @@ -1288,7 +1288,7 @@ read_again:
>>>> sectors_handled;
>>>> goto read_again;
>>>> } else
>>>> - generic_make_request(read_bio);
>>>> + bio_list_add_head(¤t->bio_list, read_bio);
>>>> return;
>>>> }
>>>
>>> Unfortunately, this patch doesn't work. It is super elegant, and seems
>>> like it really should work. But the problem is that the "rdev", to
>>> which we want to send the READ bio, might also be a remapping device
>>> (dm-linear, for example). This device will create its own remapped-bio
>>> and will call generic_make_request(), which will stick the bio onto
>>> current->bio_list TAIL:(:(:( So we are back at square one. This patch
>>> would work if *all* the remapping drivers in the stack were doing
>>> bio_list_add_head() instead of generic_make_request() :(:(:(
>>>
>>> It seems the real fix should be that generic_make_request() would use
>>> bio_list_add_head(), but as pointed in
>>> http://www.spinics.net/lists/raid/msg52756.html, there are some
>>> concerns about changing the order of remapped bios.
>>>
>>
>> While those concerns are valid, they are about hypothetical performance
>> issues rather than observed deadlock issues. So I wouldn't be too
>> worried about them.
> I am thinking of a hypothetical driver that splits say a 12Kb WRITE
> into 3x4kb WRITEs, and submits them in a proper order, hoping they
> will get to the disk in the same order, and the disk will work
> sequentially. But now we are deliberately hindering this. But I see
> that people much smarter than me are in this discussion, so I will
> leave it to them:)
Sure, that is the concern and ideally we would keep things in order.
But the elevator should re-order things in most cases so it shouldn't
matter too much.
For upstream, we obviously aim for best possible. For stable backports,
we sometimes accept non-ideal code when the change is less intrusive.
If we do backport something to -stable, I would do it "properly" using
something very similar to the upstream version. You don't seem to want
that for your code so I'm suggesting options that, while not 100% ideal,
should suit your needs - and obviously you will test your use cases.
>
>> However I think you said that you didn't want to touch core code at all
>> (maybe I misunderstood) so that wouldn't help you anyway.
> Yes, this is correct. Recompiling the kernel is a bit of a pain for
> us. We were smart enough to configure the md_mod as loadable module,
> so at least now I can patch MD code easily:)
>
>>
>> One option would be to punt the request requests to raidXd:
>>
>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>> index 40b35be34f8d..f795e27b2124 100644
>> --- a/drivers/md/raid1.c
>> +++ b/drivers/md/raid1.c
>> @@ -1229,7 +1229,7 @@ read_again:
>> sectors_handled;
>> goto read_again;
>> } else
>> - generic_make_request(read_bio);
>> + reschedule_retry(r1_bio);
>> return;
>> }
>>
>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
>> index 32e282f4c83c..eec38443075b 100644
>> --- a/drivers/md/raid10.c
>> +++ b/drivers/md/raid10.c
>> @@ -1288,7 +1288,7 @@ read_again:
>> sectors_handled;
>> goto read_again;
>> } else
>> - generic_make_request(read_bio);
>> + reschedule_retry(r10_bio);
>> return;
>> }
> This is more or less what my rudimentary patch is doing, except it is
> doing it only when we really need to wait for the barrier.
>
>>
>>
>> That might hurt performance, you would need to measure.
>> The other approach would be to revert the patch that caused the problem.
>> e.g.
>> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
>> index 40b35be34f8d..062bb86e5fd8 100644
>> --- a/drivers/md/raid1.c
>> +++ b/drivers/md/raid1.c
>> @@ -884,7 +884,8 @@ static bool need_to_wait_for_sync(struct r1conf *conf, struct bio *bio)
>> wait = false;
>> else
>> wait = true;
>> - }
>> + } else if (conf->barrier)
>> + wait = true;
>>
>> return wait;
>> }
>>
>>
> I am not sure how this patch helps. You added another condition, and
> now READs will also wait in some cases. But still if array_frozen is
> set, everybody will wait unconditionally, which is the root cause for
> the deadlock I think.
Maybe you're right. I was thinking that array_frozen only causes
problems if there are read requests in the generic_make_request queue,
and this change would keep them out. But I might have dropped a ball
somewhere.
>
> I see that there will be no magic solution for this problem:(
>
Not really.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply
* Re: Recovering RAID Volumes from 6 Disks
From: Wols Lists @ 2016-07-19 19:57 UTC (permalink / raw)
To: Amit Biswas, linux-raid
In-Reply-To: <CADsVfeyiiAgxeeATrX9UqmWb+Hr3MCf2_eMPjL8hbD7Gpj5Ksg@mail.gmail.com>
Another bit of useful information - can you post the output of smartctl
on all your drives?
smartctl -x /dev/sd[a,b,c...]
Seeing as the drives are Seagate 1TB drives, I suspect they do support
ERC and timeout mismatch is not the problem, but this will tell us.
I'll let others chime in with recovery info, but this information will
definitely help them.
Cheers,
Wol
On 19/07/16 17:29, Amit Biswas wrote:
> Greetings!
>
> Backup server was acting up and the issue was the drives (all of them)
> :( Could use some guidance or verdict.
>
> It has a total of 6 drives: sda,b,c,d,e,f. From the superblock info
> (attached), there is a raid 1, and a raid 10 volume. Problem is all
> the disks are part of both raid volumes (according to superblock).
>
> I am currently booted into an ubuntu live disk shell.
>
^ permalink raw reply
* Re: [PATCH] md: add missing sysfs_notify on array_state update
From: Shaohua Li @ 2016-07-19 18:28 UTC (permalink / raw)
To: Tomasz Majchrzak; +Cc: linux-raid
In-Reply-To: <1467276429-9359-1-git-send-email-tomasz.majchrzak@intel.com>
On Thu, Jun 30, 2016 at 10:47:09AM +0200, Tomasz Majchrzak wrote:
> Changeset 6791875e2e53 has added early return from a function so there is no
> sysfs notification for 'active' and 'clean' state change.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] Fix kernel module refcount handling
From: Shaohua Li @ 2016-07-19 18:21 UTC (permalink / raw)
To: Alexey Obitotskiy; +Cc: linux-raid
In-Reply-To: <1466676661-1564-1-git-send-email-aleksey.obitotskiy@intel.com>
On Thu, Jun 23, 2016 at 12:11:01PM +0200, Alexey Obitotskiy wrote:
> md loads raidX modules and increments module refcount each time level
> has changed but does not decrement it. You are unable to unload raid0
> module after reshape because raid0 reshape changes level to raid4
> and back to raid0.
>
> Signed-off-by: Aleksey Obitotskiy <aleksey.obitotskiy@intel.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] md: use seconds granularity for error logging
From: Shaohua Li @ 2016-07-19 17:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-raid, Hannes Reinecke, y2038, NeilBrown, linux-kernel,
Jens Axboe, Guoqing Jiang, Goldwyn Rodrigues
In-Reply-To: <20160617153347.380722-1-arnd@arndb.de>
On Fri, Jun 17, 2016 at 05:33:10PM +0200, Arnd Bergmann wrote:
> The md code stores the exact time of the last error in the
> last_read_error variable using a timespec structure. It only
> ever uses the seconds portion of that though, so we can
> use a scalar for it.
>
> There won't be an overflow in 2038 here, because it already
> used monotonic time and 32-bit is enough for that, but I've
> decided to use time64_t for consistency in the conversion.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks!
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ 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