* Re: RAID Recovery
From: Phil Turmel @ 2017-03-07 15:00 UTC (permalink / raw)
To: Adam Goryachev, linux-raid
In-Reply-To: <94b4591a-bda1-529b-3af1-c451b657082f@websitemanagers.com.au>
Hi Adam,
{Please remember to trim repetitive stuff, and interleave.}
On 03/07/2017 09:06 AM, Adam Goryachev wrote:
> BTW, just some more info I've found... either almost the entire
> drives are RAID1 mirrors, or all 4 are RAID1 mirrors:
> Other option, they have been re-initialised/zero'd or similar, and
> thats why all the data is identical (useless). I was hoping to get a
> starting point for where the partition boundaries might have been
> ....
Search the devices for ext2/3/4 superblocks, like so:
dd if=/dev/sdX bs=1M 2>/dev/null |hexdump -C |grep '30 .\+ 53 ef 0'
This will take a very long time, and will generate false positives.
You probably would want to use screen or tmux to run these in
parallel in separate processes.
But superblock locations will give you hints as to the rest of data,
and make it possible to create partitions that will let you copy
stuff off into a new array.
Phil
^ permalink raw reply
* Re: [RAID recovery] Unable to recover RAID5 array after disk failure
From: Phil Turmel @ 2017-03-07 14:52 UTC (permalink / raw)
To: Olivier Swinkels; +Cc: linux-raid
In-Reply-To: <CAJ0QwkKG8_dCzTBYEPm5CpqWMQwM=f8YBAYtatNh=9U_7ygdnA@mail.gmail.com>
On 03/07/2017 03:39 AM, Olivier Swinkels wrote:
> After I used the pvcreate command to recreate pv the vgcfgrestore
> command succeeds and the lvm is available (after activating).
>
> However when I try to mount it I get the following error: sudo mount
> -t ext4 /dev/lvm-raid/lvm0 /mnt/raid mount: mount
> /dev/mapper/lvm--raid-lvm0 on /mnt/raid failed: Structure needs
> cleaning
>
> So I guess the underlying RAID array is still not ok...
No, your underlying array is very likely correct. But the intervening
incorrect --create operation stomped on your filesystems. Run fsck
while unmounted to deal with the corruption and recover what you can.
Run fsck with "-n" first, to see just how extensive the problems are,
then with "-y" to actually fix things. Based on your sequence of
events, your corruptions should be at low sector addresses (first few
Gigs) of your array. If that's what appears with "-n", proceed.
If you are unlucky, the stompage hit one or more of your filesystems'
superblocks, requiring access to backup superblocks. If you still see
no progress with either of the above, you might need to search your
array for ext2/3/4 superblocks. This grep would help:
dd if=/dev/md0 bs=1M count=16k 2>/dev/null |hexdump -C |grep '30 .\+ 53 ef 0'
(Not all hits from the grep will be superblocks, but they would be
visually distinguishable, and would have decipherable timestamps.)
Phil
^ permalink raw reply
* Re: When will Linux support M2 on RAID ?
From: Austin S. Hemmelgarn @ 2017-03-07 14:50 UTC (permalink / raw)
To: Christoph Hellwig, David F.; +Cc: linux-kernel, linux-raid@vger.kernel.org
In-Reply-To: <20170307045200.GA1708@infradead.org>
On 2017-03-06 23:52, Christoph Hellwig wrote:
> On Sun, Mar 05, 2017 at 06:09:42PM -0800, David F. wrote:
>> More and more systems are coming with M2 on RAID and Linux doesn't
>> work unless you change the system out of RAID mode. This is becoming
>> more and more of a problem. What is the status of Linux support for
>> the new systems?
>
> Your message doesn't make sense at all. MD works on absolutely any
> Linux block device, and I've used it on plenty M.2 form factor devices -
> not that the form factor has anything to do with how Linux would treat
> a device.
>
He's referring to the RAID mode most modern Intel chipsets have, which
(last I checked) Linux does not support completely and many OEM's are
setting by default on new systems because it apparently provides better
performance than AHCI even for a single device. The bigger issue with
this is that it's damn near impossible to get to the firmware on many
new systems, and even if you can, some OEM's aren't even giving the
option to use AHCI mode instead of the RAID mode.
The whole M.2 thing is absolutely bogus though, my thought is that
people are conflating the two because this switch to using RAID mode by
default is happening concurrently with a general movement towards using
M.2 devices as primary storage.
^ permalink raw reply
* RE: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t
From: Reshetova, Elena @ 2017-03-07 14:48 UTC (permalink / raw)
To: Sakari Ailus
Cc: peterz@infradead.org, linux-pci@vger.kernel.org,
target-devel@vger.kernel.org,
linux1394-devel@lists.sourceforge.net, devel@driverdev.osuosl.org,
linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-serial@vger.kernel.org, fcoe-devel@open-fcoe.org,
xen-devel@lists.xenproject.org, open-iscsi@googlegroups.com,
linux-media@vger.kernel.org, Kees Cook,
linux-raid@vger.kernel.org, linux-bcache@vger.kernel.org
In-Reply-To: <20170307085005.GH3220@valkosipuli.retiisi.org.uk>
> Hi Elena,
>
> On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> > ---
> > drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
> > include/media/videobuf2-memops.h | 3 ++-
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-
> core/videobuf2-memops.c
> > index 1cd322e..4bb8424 100644
> > --- a/drivers/media/v4l2-core/videobuf2-memops.c
> > +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> > @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > - __func__, h, atomic_read(h->refcount), vma->vm_start,
> > + __func__, h, refcount_read(h->refcount), vma->vm_start,
> > vma->vm_end);
> >
> > - atomic_inc(h->refcount);
> > + refcount_inc(h->refcount);
> > }
> >
> > /**
> > @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > - __func__, h, atomic_read(h->refcount), vma->vm_start,
> > + __func__, h, refcount_read(h->refcount), vma->vm_start,
> > vma->vm_end);
> >
> > h->put(h->arg);
> > diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-
> memops.h
> > index 36565c7a..a6ed091 100644
> > --- a/include/media/videobuf2-memops.h
> > +++ b/include/media/videobuf2-memops.h
> > @@ -16,6 +16,7 @@
> >
> > #include <media/videobuf2-v4l2.h>
> > #include <linux/mm.h>
> > +#include <linux/refcount.h>
> >
> > /**
> > * struct vb2_vmarea_handler - common vma refcount tracking handler
> > @@ -25,7 +26,7 @@
> > * @arg: argument for @put callback
> > */
> > struct vb2_vmarea_handler {
> > - atomic_t *refcount;
> > + refcount_t *refcount;
>
> This is a pointer to refcount, not refcount itself. The refcount is part of
> a memory type specific struct, the types that you change in the following
> three patches. I guess it would still compile and work as separate patches
> but you'd sure get warnings at least.
Actually it doesn't compile without this patch if I remember it correctly back in past when I was initially splitting the patches per variable.
>
> How about merging this and the three following patches that change the memop
> refcount types?
Sounds good!
Best Regards,
Elena.
>
> > void (*put)(void *arg);
> > void *arg;
> > };
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* RE: [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t
From: Reshetova, Elena @ 2017-03-07 14:45 UTC (permalink / raw)
To: Sakari Ailus
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
fcoe-devel-s9riP+hp16TNLxjTenLetw@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devel-gWbeCf7V1WCQmaza687I9uG/Ez6ZCGd0
In-Reply-To: <20170307083016.GG3220-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
> Hi Elena,
>
> On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova <elena.reshetova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Signed-off-by: Hans Liljestrand <ishkamiel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Signed-off-by: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > Signed-off-by: David Windsor <dwindsor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> ...
> > @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
> > "failed to register
> video device!\n");
> > break;
> > }
> > - atomic_inc(&dev->num_channels);
> > + refcount_set(&dev->num_channels, 1);
>
> That's not right. The loop runs four iterations and the value after the
> loop should be indeed the number of channels.
Oh, yes, I was blind here, sorry. The problem why it cannot be left as inc is because it would do increment from zero here, which is not allowed by refcount_t interface.
> atomic_t isn't really used for reference counting here, but storing out how
> many "channels" there are per hardware device, with maximum number of four
> (4). I'd leave this driver using atomic_t.
Yes, sounds like the best thing to do. I will drop this patch.
Thank you for reviews!
Best Regards,
Elena.
>
> > v4l2_info(&dev->v4l2_dev, "V4L2 device registered
> as %s\n",
> > video_device_node_name(&vc-
> >vdev));
> >
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: RAID Recovery
From: Adam Goryachev @ 2017-03-07 14:06 UTC (permalink / raw)
To: Phil Turmel, linux-raid
In-Reply-To: <7cefe670-dcea-6e04-b090-b215a6a218c9@websitemanagers.com.au>
BTW, just some more info I've found... either almost the entire drives
are RAID1 mirrors, or all 4 are RAID1 mirrors:
root@ubuntu:~# cmp /dev/sda /dev/sdb
/dev/sda /dev/sdb differ: byte 1000162959365, line 243319233
root@ubuntu:~# cmp /dev/sdc /dev/sdd
/dev/sdc /dev/sdd differ: byte 1000162971653, line 243236929
Now I'll need to compare sdb and sdc to find out if all 4 are identical...
PS, they are 1TB drives, so sure, might be a minute amount of unique
data at the very end of the drives....
Other option, they have been re-initialised/zero'd or similar, and thats
why all the data is identical (useless). I was hoping to get a starting
point for where the partition boundaries might have been ....
Regards,
Adam
On 7/3/17 20:17, Adam Goryachev wrote:
>
>
> On 7/3/17 07:10, Phil Turmel wrote:
>> On 03/06/2017 10:07 AM, Adam Goryachev wrote:
>>> Hi all,
>>>
>>> I'm trying to assist a friend to recover their RAID array, it consists
>>> of 4 drives, most likely in RAID10. It was a linux based NAS (AFAIK). I
>>> would really appreciate any tips or suggestions...
>>>
>>> First, the bad news:
>>>
>>> mdadm --misc --examine /dev/sd[abcd]
>>> /dev/sda:
>>> MBR Magic : aa55
>>> /dev/sdb:
>>> MBR Magic : aa55
>>> /dev/sdc:
>>> MBR Magic : aa55
>>> /dev/sdd:
>>> MBR Magic : aa55
>>>
>>> This really doesn't look promising.... but the disks themselves look
>>> "healthy"... at least mostly.
>> As Reindl said, this by itself is no surprise. The NAS has to boot off
>> of *something*, so partitions for /boot, /swap, /, and /data, or some
>> combination, is common for such small systems.
>>
>> The first partition is likely raid1 across all devices for /boot.
>> After that, all bets are off.
> OK, so since it looks like the partition table has been lost, is there
> something that could be used to define where the partition table
> boundaries are? eg, if the raid is marked at the beginning of each
> partition, then finding it will show that "this" is the beginning, or
> vice versa if the raid marker is at the end of the partitions....
>>> Looking at the content of the drives, it might be possible that all
>>> four
>>> drives were in RAID1 ... at least, I can find identical data on all
>>> four
>>> of the drives:
>>>
>>> Running this command for each drive:
>>>
>>> strings /dev/sdd |cat -n |less
>>>
>>> looking for some "text", and I find what looks like a log file snipped
>>> which is identical across all four drives. Thats 25 lines of output,
>>> that exists on the same output line number, matching across all 4
>>> drives. So perhaps I have a 4 drive RAID1, which I guess should make it
>>> easier to recover from.
>> Probably just a 4x raid1 mirror for the root partition.
> OK, so if I can find where the drives stop being identical, then I can
> probably identify the end of the root partition. Also, if I can
> recover the root partition (not the goal) then it might contain some
> valuable information on the original config of the rest of the
> drives.... and hence get to recover the actual data partitions.
>>> Disks are /dev/sda /dev/sdb /dev/sdc /dev/sdd, all identical
>>> "partitions" that don't seem to exist, but there is a MBR partition
>>> table
>>>
>>> gdisk -l /dev/sda
>>> GPT fdisk (gdisk) version 1.0.1
>>>
>>> Partition table scan:
>>> MBR: MBR only
>>> BSD: not present
>>> APM: not present
>>> GPT: not present
>>>
>>>
>>> ***************************************************************
>>> Found invalid GPT and valid MBR; converting MBR to GPT format
>>> in memory.
>>> ***************************************************************
>>>
>>> Disk /dev/sda: 1953525168 sectors, 931.5 GiB
>>> Logical sector size: 512 bytes
>>> Disk identifier (GUID): 145F71F0-4D0B-4941-9F9E-2C5301BF518F
>>> Partition table holds up to 128 entries
>>> First usable sector is 34, last usable sector is 1953525134
>>> Partitions will be aligned on 2048-sector boundaries
>>> Total free space is 1953525101 sectors (931.5 GiB)
>> This is worrisome. Please repost the complete output of fdisk -l
>> and gdisk -l for all of these devices. But....
>>
>>> The first two drives look like this (lots of read errors), the second
>>> two look perfectly clean...
>> Please remove the drives from the NAS box and connect to a known good
>> system. Your smartctl reports include neither re-allocated sectors
>> nor pending relocations, which would be expected if there are many
>> read errors. That means the read errors are likely due to controller,
>> cables, or power supply problems.
> The drives have already been removed from the original NAS device,
> they are now connected to a PC running from a ubuntu live CD...
>> Note, timeout mismatch *does not* apply to sda, but you trimmed
>> too much to tell for the other devices. Please submit complete output
>> from smartctl -iA -l scterc /dev/sdX for each of these devices.
> All devices are the same, but I'll include it here:
> smartctl -iA -l scterc /dev/sda
> smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local
> build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Device Model: ST1000NM0033 81Y9807 81Y3867IBM
> Serial Number: Z1W2ZG3M
> LU WWN Device Id: 5 000c50 079c48262
> Firmware Version: BB5A
> User Capacity: 1,000,204,886,016 bytes [1.00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ACS-2 (minor revision not indicated)
> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
> Local Time is: Tue Mar 7 09:11:11 2017 UTC
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> 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 081 063 044 Pre-fail
> Always - 122481432
> 3 Spin_Up_Time 0x0003 097 096 000 Pre-fail
> Always - 0
> 4 Start_Stop_Count 0x0032 100 100 020 Old_age
> Always - 80
> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
> Always - 0
> 7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail
> Always - 182098084
> 9 Power_On_Hours 0x0032 087 087 000 Old_age
> Always - 11892
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
> Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age
> Always - 65
> 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 063 051 045 Old_age
> Always - 37 (Min/Max 36/40)
> 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 - 60
> 193 Load_Cycle_Count 0x0032 100 100 000 Old_age
> Always - 559
> 194 Temperature_Celsius 0x0022 037 049 000 Old_age
> Always - 37 (0 21 0 0 0)
> 195 Hardware_ECC_Recovered 0x001a 021 007 000 Old_age
> Always - 122481432
> 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
>
> SCT Error Recovery Control:
> Read: 75 (7.5 seconds)
> Write: 75 (7.5 seconds)
>
> smartctl -iA -l scterc /dev/sdb
> smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local
> build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Device Model: ST1000NM0033 81Y9807 81Y3867IBM
> Serial Number: Z1W2ZKKD
> LU WWN Device Id: 5 000c50 079c557df
> Firmware Version: BB5A
> User Capacity: 1,000,204,886,016 bytes [1.00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ACS-2 (minor revision not indicated)
> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
> Local Time is: Tue Mar 7 09:11:11 2017 UTC
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> 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 083 063 044 Pre-fail
> Always - 225986939
> 3 Spin_Up_Time 0x0003 097 096 000 Pre-fail
> Always - 0
> 4 Start_Stop_Count 0x0032 100 100 020 Old_age
> Always - 80
> 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
> Always - 0
> 7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail
> Always - 192404045
> 9 Power_On_Hours 0x0032 087 087 000 Old_age
> Always - 11892
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
> Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 020 Old_age
> Always - 66
> 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 059 047 045 Old_age
> Always - 41 (Min/Max 40/44)
> 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 - 58
> 193 Load_Cycle_Count 0x0032 100 100 000 Old_age
> Always - 556
> 194 Temperature_Celsius 0x0022 041 053 000 Old_age
> Always - 41 (0 21 0 0 0)
> 195 Hardware_ECC_Recovered 0x001a 023 013 000 Old_age
> Always - 225986939
> 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
>
> SCT Error Recovery Control:
> Read: 75 (7.5 seconds)
> Write: 75 (7.5 seconds)
>
> smartctl -iA -l scterc /dev/sdc
> smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local
> build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Device Model: WD1003FBYX-23 81Y9807 81Y3867IBM
> Serial Number: WD-WCAW37DULJLP
> LU WWN Device Id: 5 0014ee 261450c09
> Firmware Version: WB35
> User Capacity: 1,000,204,886,016 bytes [1.00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS (minor revision not indicated)
> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
> Local Time is: Tue Mar 7 09:11:11 2017 UTC
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
> WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail
> Always - 3
> 3 Spin_Up_Time 0x0027 186 173 021 Pre-fail
> Always - 3691
> 4 Start_Stop_Count 0x0032 100 100 000 Old_age
> Always - 90
> 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail
> Always - 0
> 7 Seek_Error_Rate 0x002e 100 253 000 Old_age
> Always - 0
> 9 Power_On_Hours 0x0032 084 084 000 Old_age
> Always - 11777
> 10 Spin_Retry_Count 0x0032 100 253 000 Old_age
> Always - 0
> 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age
> Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age
> Always - 76
> 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age
> Always - 69
> 193 Load_Cycle_Count 0x0032 200 200 000 Old_age
> Always - 20
> 194 Temperature_Celsius 0x0022 103 092 000 Old_age
> Always - 44
> 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age
> Always - 0
> 197 Current_Pending_Sector 0x0032 200 200 000 Old_age
> Always - 0
> 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age
> Offline - 0
> 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age
> Always - 0
> 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age
> Offline - 0
>
> SCT Error Recovery Control:
> Read: 70 (7.0 seconds)
> Write: 70 (7.0 seconds)
>
> smartctl -iA -l scterc /dev/sdd
> smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local
> build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke,
> www.smartmontools.org
>
> === START OF INFORMATION SECTION ===
> Device Model: WD1003FBYX-23 81Y9807 81Y3867IBM
> Serial Number: WD-WCAW37DULEES
> LU WWN Device Id: 5 0014ee 26143dbd2
> Firmware Version: WB35
> User Capacity: 1,000,204,886,016 bytes [1.00 TB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: 7200 rpm
> Device is: Not in smartctl database [for details use: -P showall]
> ATA Version is: ATA8-ACS (minor revision not indicated)
> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
> Local Time is: Tue Mar 7 09:11:11 2017 UTC
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> === START OF READ SMART DATA SECTION ===
> SMART Attributes Data Structure revision number: 16
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
> WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail
> Always - 0
> 3 Spin_Up_Time 0x0027 184 173 021 Pre-fail
> Always - 3758
> 4 Start_Stop_Count 0x0032 100 100 000 Old_age
> Always - 90
> 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail
> Always - 0
> 7 Seek_Error_Rate 0x002e 100 253 000 Old_age
> Always - 0
> 9 Power_On_Hours 0x0032 084 084 000 Old_age
> Always - 11767
> 10 Spin_Retry_Count 0x0032 100 253 000 Old_age
> Always - 0
> 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age
> Always - 0
> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age
> Always - 76
> 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age
> Always - 67
> 193 Load_Cycle_Count 0x0032 200 200 000 Old_age
> Always - 22
> 194 Temperature_Celsius 0x0022 106 095 000 Old_age
> Always - 41
> 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age
> Always - 0
> 197 Current_Pending_Sector 0x0032 200 200 000 Old_age
> Always - 0
> 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age
> Offline - 0
> 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age
> Always - 0
> 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age
> Offline - 0
>
> SCT Error Recovery Control:
> Read: 70 (7.0 seconds)
> Write: 70 (7.0 seconds)
>
>> Do the fdisk & gdisk reports from the known good system, and also,
>> if you can find any partitions, run --examine on each from the same
>> system. Keep the --examine reports with the corresponding smartctl
>> report.
>>
> Looks like the partition tables are all gone... fdisk and gdisk both
> report no partitions on any drive. gdisk shows them all with MBR (as
> mdadm did, which is apparently due to the magic bytes aa55
>
> So it seems the real problem will be to work out where the various
> partitions start and end...... Then re-create the partition table, and
> hopefully the actual data will still be good.
> Any ideas on how to "find" the partitions?
>
> Thanks,
> Adam
> --
> 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: GRUB warning after replacing disk drive in RAID1
From: Reindl Harald @ 2017-03-07 13:00 UTC (permalink / raw)
To: Wols Lists, Peter Sangas, 'Phil Turmel', linux-raid
In-Reply-To: <58BEAD7B.5070709@youngman.org.uk>
Am 07.03.2017 um 13:54 schrieb Wols Lists:
> On 06/03/17 22:13, Peter Sangas wrote:
>> In addition, the wiki says " you will need to configure your distro to use an initramfs.
>>
>> here are the last few lines of my grub.cnf:
>>
>> echo 'Loading Linux 4.4.0-36-generic ...'
>> linux /vmlinuz-4.4.0-36-generic root=UUID=cddffa50-9713-4205-aab6-86745735958b ro recovery nomodeset
>> echo 'Loading initial ramdisk ...'
>> initrd /initrd.img-4.4.0-36-generic
>>
>> should I be concerned my grub.cnf uses initrd.img and not initramfs? My grub.cnf was last modified 11/2016 and I've rebooted successfully into a RAID1 since.
>
> I think your problem is right there !!!
>
> Look at the wiki, but I can NOT see the magic command "domdadm", without
> which mdadm doesn't get loaded and the array doesn't get assembled. No
> array, no root, no system ...
not really because subject is "GRUB warning after replacing disk drive
in RAID1" and so mdadm is running and the array assembled
> (Oh - initrd, initramfs, they're probably the same thing. :-)
yes
^ permalink raw reply
* Re: GRUB warning after replacing disk drive in RAID1
From: Wols Lists @ 2017-03-07 12:54 UTC (permalink / raw)
To: Peter Sangas, 'Phil Turmel', 'Reindl Harald',
linux-raid
In-Reply-To: <008401d296c6$f5ee1e80$e1ca5b80$@wnsdev.com>
On 06/03/17 22:13, Peter Sangas wrote:
> In addition, the wiki says " you will need to configure your distro to use an initramfs.
>
> here are the last few lines of my grub.cnf:
>
> echo 'Loading Linux 4.4.0-36-generic ...'
> linux /vmlinuz-4.4.0-36-generic root=UUID=cddffa50-9713-4205-aab6-86745735958b ro recovery nomodeset
> echo 'Loading initial ramdisk ...'
> initrd /initrd.img-4.4.0-36-generic
>
> should I be concerned my grub.cnf uses initrd.img and not initramfs? My grub.cnf was last modified 11/2016 and I've rebooted successfully into a RAID1 since.
I think your problem is right there !!!
Look at the wiki, but I can NOT see the magic command "domdadm", without
which mdadm doesn't get loaded and the array doesn't get assembled. No
array, no root, no system ...
(Oh - initrd, initramfs, they're probably the same thing. :-)
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
From: Sergei Shtylyov @ 2017-03-07 10:40 UTC (permalink / raw)
To: Reshetova, Elena, gregkh@linuxfoundation.org
Cc: devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
open-iscsi@googlegroups.com, Kees Cook,
linux-scsi@vger.kernel.org, David Windsor, peterz@infradead.org,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, linux-bcache@vger.kernel.org,
target-devel@vger.kernel.org, linux-serial@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B41C556E2@IRSMSX102.ger.corp.intel.com>
On 3/7/2017 10:52 AM, Reshetova, Elena wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter overflows that might lead to use-after-free
>>> situations.
>>>
>>> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
>>> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> Signed-off-by: David Windsor <dwindsor@gmail.com>
>> [...]
>>> diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
>>> index 115414c..16c1313 100644
>>> --- a/drivers/media/pci/cx88/cx88.h
>>> +++ b/drivers/media/pci/cx88/cx88.h
[...]
>>> @@ -339,7 +340,7 @@ struct cx8802_dev;
>>>
>>> struct cx88_core {
>>> struct list_head devlist;
>>> - atomic_t refcount;
>>> + refcount_t refcount;
>>
>> Could you please keep the name aligned with above and below?
>
> You mean "not aligned" to devlist, but with a shift like it was before?
I mean aligned, like it was before. :-)
> Sure, will fix. Is the patch ok otherwise?
I haven't noticed anything else...
> Best Regards,
> Elena.
[...]
MBR, Sergei
^ permalink raw reply
* Re: RAID Recovery
From: Adam Goryachev @ 2017-03-07 9:17 UTC (permalink / raw)
To: Phil Turmel, linux-raid
In-Reply-To: <e4d9724d-ab52-aa79-c600-7b287c16a182@turmel.org>
On 7/3/17 07:10, Phil Turmel wrote:
> On 03/06/2017 10:07 AM, Adam Goryachev wrote:
>> Hi all,
>>
>> I'm trying to assist a friend to recover their RAID array, it consists
>> of 4 drives, most likely in RAID10. It was a linux based NAS (AFAIK). I
>> would really appreciate any tips or suggestions...
>>
>> First, the bad news:
>>
>> mdadm --misc --examine /dev/sd[abcd]
>> /dev/sda:
>> MBR Magic : aa55
>> /dev/sdb:
>> MBR Magic : aa55
>> /dev/sdc:
>> MBR Magic : aa55
>> /dev/sdd:
>> MBR Magic : aa55
>>
>> This really doesn't look promising.... but the disks themselves look
>> "healthy"... at least mostly.
> As Reindl said, this by itself is no surprise. The NAS has to boot off
> of *something*, so partitions for /boot, /swap, /, and /data, or some
> combination, is common for such small systems.
>
> The first partition is likely raid1 across all devices for /boot.
> After that, all bets are off.
OK, so since it looks like the partition table has been lost, is there
something that could be used to define where the partition table
boundaries are? eg, if the raid is marked at the beginning of each
partition, then finding it will show that "this" is the beginning, or
vice versa if the raid marker is at the end of the partitions....
>> Looking at the content of the drives, it might be possible that all four
>> drives were in RAID1 ... at least, I can find identical data on all four
>> of the drives:
>>
>> Running this command for each drive:
>>
>> strings /dev/sdd |cat -n |less
>>
>> looking for some "text", and I find what looks like a log file snipped
>> which is identical across all four drives. Thats 25 lines of output,
>> that exists on the same output line number, matching across all 4
>> drives. So perhaps I have a 4 drive RAID1, which I guess should make it
>> easier to recover from.
> Probably just a 4x raid1 mirror for the root partition.
OK, so if I can find where the drives stop being identical, then I can
probably identify the end of the root partition. Also, if I can recover
the root partition (not the goal) then it might contain some valuable
information on the original config of the rest of the drives.... and
hence get to recover the actual data partitions.
>> Disks are /dev/sda /dev/sdb /dev/sdc /dev/sdd, all identical
>> "partitions" that don't seem to exist, but there is a MBR partition table
>>
>> gdisk -l /dev/sda
>> GPT fdisk (gdisk) version 1.0.1
>>
>> Partition table scan:
>> MBR: MBR only
>> BSD: not present
>> APM: not present
>> GPT: not present
>>
>>
>> ***************************************************************
>> Found invalid GPT and valid MBR; converting MBR to GPT format
>> in memory.
>> ***************************************************************
>>
>> Disk /dev/sda: 1953525168 sectors, 931.5 GiB
>> Logical sector size: 512 bytes
>> Disk identifier (GUID): 145F71F0-4D0B-4941-9F9E-2C5301BF518F
>> Partition table holds up to 128 entries
>> First usable sector is 34, last usable sector is 1953525134
>> Partitions will be aligned on 2048-sector boundaries
>> Total free space is 1953525101 sectors (931.5 GiB)
> This is worrisome. Please repost the complete output of fdisk -l
> and gdisk -l for all of these devices. But....
>
>> The first two drives look like this (lots of read errors), the second
>> two look perfectly clean...
> Please remove the drives from the NAS box and connect to a known good
> system. Your smartctl reports include neither re-allocated sectors
> nor pending relocations, which would be expected if there are many
> read errors. That means the read errors are likely due to controller,
> cables, or power supply problems.
The drives have already been removed from the original NAS device, they
are now connected to a PC running from a ubuntu live CD...
> Note, timeout mismatch *does not* apply to sda, but you trimmed
> too much to tell for the other devices. Please submit complete output
> from smartctl -iA -l scterc /dev/sdX for each of these devices.
All devices are the same, but I'll include it here:
smartctl -iA -l scterc /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: ST1000NM0033 81Y9807 81Y3867IBM
Serial Number: Z1W2ZG3M
LU WWN Device Id: 5 000c50 079c48262
Firmware Version: BB5A
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Mar 7 09:11:11 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
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 081 063 044 Pre-fail
Always - 122481432
3 Spin_Up_Time 0x0003 097 096 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 80
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail
Always - 182098084
9 Power_On_Hours 0x0032 087 087 000 Old_age
Always - 11892
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 65
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 063 051 045 Old_age
Always - 37 (Min/Max 36/40)
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 - 60
193 Load_Cycle_Count 0x0032 100 100 000 Old_age
Always - 559
194 Temperature_Celsius 0x0022 037 049 000 Old_age
Always - 37 (0 21 0 0 0)
195 Hardware_ECC_Recovered 0x001a 021 007 000 Old_age
Always - 122481432
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
SCT Error Recovery Control:
Read: 75 (7.5 seconds)
Write: 75 (7.5 seconds)
smartctl -iA -l scterc /dev/sdb
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: ST1000NM0033 81Y9807 81Y3867IBM
Serial Number: Z1W2ZKKD
LU WWN Device Id: 5 000c50 079c557df
Firmware Version: BB5A
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Mar 7 09:11:11 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
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 083 063 044 Pre-fail
Always - 225986939
3 Spin_Up_Time 0x0003 097 096 000 Pre-fail
Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age
Always - 80
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail
Always - 192404045
9 Power_On_Hours 0x0032 087 087 000 Old_age
Always - 11892
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail
Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age
Always - 66
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 059 047 045 Old_age
Always - 41 (Min/Max 40/44)
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 - 58
193 Load_Cycle_Count 0x0032 100 100 000 Old_age
Always - 556
194 Temperature_Celsius 0x0022 041 053 000 Old_age
Always - 41 (0 21 0 0 0)
195 Hardware_ECC_Recovered 0x001a 023 013 000 Old_age
Always - 225986939
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
SCT Error Recovery Control:
Read: 75 (7.5 seconds)
Write: 75 (7.5 seconds)
smartctl -iA -l scterc /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: WD1003FBYX-23 81Y9807 81Y3867IBM
Serial Number: WD-WCAW37DULJLP
LU WWN Device Id: 5 0014ee 261450c09
Firmware Version: WB35
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Tue Mar 7 09:11:11 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail
Always - 3
3 Spin_Up_Time 0x0027 186 173 021 Pre-fail
Always - 3691
4 Start_Stop_Count 0x0032 100 100 000 Old_age
Always - 90
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail
Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age
Always - 0
9 Power_On_Hours 0x0032 084 084 000 Old_age
Always - 11777
10 Spin_Retry_Count 0x0032 100 253 000 Old_age
Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age
Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 76
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age
Always - 69
193 Load_Cycle_Count 0x0032 200 200 000 Old_age
Always - 20
194 Temperature_Celsius 0x0022 103 092 000 Old_age
Always - 44
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age
Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age
Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age
Offline - 0
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
smartctl -iA -l scterc /dev/sdd
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.8.0-22-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: WD1003FBYX-23 81Y9807 81Y3867IBM
Serial Number: WD-WCAW37DULEES
LU WWN Device Id: 5 0014ee 26143dbd2
Firmware Version: WB35
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Tue Mar 7 09:11:11 2017 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail
Always - 0
3 Spin_Up_Time 0x0027 184 173 021 Pre-fail
Always - 3758
4 Start_Stop_Count 0x0032 100 100 000 Old_age
Always - 90
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail
Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age
Always - 0
9 Power_On_Hours 0x0032 084 084 000 Old_age
Always - 11767
10 Spin_Retry_Count 0x0032 100 253 000 Old_age
Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age
Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 76
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age
Always - 67
193 Load_Cycle_Count 0x0032 200 200 000 Old_age
Always - 22
194 Temperature_Celsius 0x0022 106 095 000 Old_age
Always - 41
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age
Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age
Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age
Offline - 0
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
> Do the fdisk & gdisk reports from the known good system, and also,
> if you can find any partitions, run --examine on each from the same
> system. Keep the --examine reports with the corresponding smartctl
> report.
>
Looks like the partition tables are all gone... fdisk and gdisk both
report no partitions on any drive. gdisk shows them all with MBR (as
mdadm did, which is apparently due to the magic bytes aa55
So it seems the real problem will be to work out where the various
partitions start and end...... Then re-create the partition table, and
hopefully the actual data will still be good.
Any ideas on how to "find" the partitions?
Thanks,
Adam
^ permalink raw reply
* Re: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t
From: Sakari Ailus @ 2017-03-07 8:50 UTC (permalink / raw)
To: Elena Reshetova
Cc: peterz, linux-pci, target-devel, linux1394-devel, devel,
linux-s390, linux-scsi, linux-serial, fcoe-devel, xen-devel,
open-iscsi, linux-media, Kees Cook, linux-raid, linux-bcache,
Hans Liljestrand, David Windsor, gregkh, linux-usb, linux-kernel,
netdev, devel
In-Reply-To: <1488810076-3754-14-git-send-email-elena.reshetova@intel.com>
Hi Elena,
On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
> drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
> include/media/videobuf2-memops.h | 3 ++-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c
> index 1cd322e..4bb8424 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
> struct vb2_vmarea_handler *h = vma->vm_private_data;
>
> pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> - __func__, h, atomic_read(h->refcount), vma->vm_start,
> + __func__, h, refcount_read(h->refcount), vma->vm_start,
> vma->vm_end);
>
> - atomic_inc(h->refcount);
> + refcount_inc(h->refcount);
> }
>
> /**
> @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct *vma)
> struct vb2_vmarea_handler *h = vma->vm_private_data;
>
> pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> - __func__, h, atomic_read(h->refcount), vma->vm_start,
> + __func__, h, refcount_read(h->refcount), vma->vm_start,
> vma->vm_end);
>
> h->put(h->arg);
> diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
> index 36565c7a..a6ed091 100644
> --- a/include/media/videobuf2-memops.h
> +++ b/include/media/videobuf2-memops.h
> @@ -16,6 +16,7 @@
>
> #include <media/videobuf2-v4l2.h>
> #include <linux/mm.h>
> +#include <linux/refcount.h>
>
> /**
> * struct vb2_vmarea_handler - common vma refcount tracking handler
> @@ -25,7 +26,7 @@
> * @arg: argument for @put callback
> */
> struct vb2_vmarea_handler {
> - atomic_t *refcount;
> + refcount_t *refcount;
This is a pointer to refcount, not refcount itself. The refcount is part of
a memory type specific struct, the types that you change in the following
three patches. I guess it would still compile and work as separate patches
but you'd sure get warnings at least.
How about merging this and the three following patches that change the memop
refcount types?
> void (*put)(void *arg);
> void *arg;
> };
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: [RAID recovery] Unable to recover RAID5 array after disk failure
From: Olivier Swinkels @ 2017-03-07 8:39 UTC (permalink / raw)
To: Phil Turmel; +Cc: linux-raid
In-Reply-To: <c3ae0e4d-dccc-9cb4-72b0-28a1bde3c752@turmel.org>
On Mon, Mar 6, 2017 at 8:50 PM, Phil Turmel <philip@turmel.org> wrote:
> On 03/06/2017 04:17 AM, Olivier Swinkels wrote:
>
>>> That sounds promising, as /etc was not on the array.
>>> I found a backup in /etc/lvm/backup/lvm-raid (contents shown below).
>
> Yay! That's exactly what you need.
>
>>> Unfortunatelly when I try to use it to restore the LVM I get the
>>> following error:
>>> vgcfgrestore -f /etc/lvm/backup/lvm-raid lvm-raid
>>> Aborting vg_write: No metadata areas to write to!
>>> Restore failed.
>
> You're command doesn't specify the device name of your reconstructed
> array.
>
>>> So I guess I also need to recreate the physical volume using:
>>
>> Correction: (Put the wrong ID in the pvcreate example):
>> pvcreate --uuid "DWv51O-lg9s-Dl4w-EBp9-QeIF-Vv60-8wt2uS" --restorefile
>> /etc/lvm/backup/lvm-raid
>>
>>> Is this correct? (I'm a bit hesitant with another 'create' command as
>>> you might understand.)
>
> I haven't actually had to do this operation but once, and I don't
> recall if the vgcfgrestore was sufficient. But either way, you simply
> didn't tell LVM where you are restoring TO.
>
> Phil
>
Hi,
Thanks for your response, as far as I can see the syntax of the
vgcfgrestore command is correct as the destination location is in the
backup file.
After I used the pvcreate command to recreate pv the vgcfgrestore
command succeeds and the lvm is available (after activating).
However when I try to mount it I get the following error:
sudo mount -t ext4 /dev/lvm-raid/lvm0 /mnt/raid
mount: mount /dev/mapper/lvm--raid-lvm0 on /mnt/raid failed: Structure
needs cleaning
So I guess the underlying RAID array is still not ok...
Is there a way for me to validate if the degraded array contains valid
data or if there is still a disk swapped or corrupted?
Thanks.
Olivier
^ permalink raw reply
* Re: [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t
From: Sakari Ailus @ 2017-03-07 8:30 UTC (permalink / raw)
To: Elena Reshetova
Cc: peterz, linux-pci, target-devel, linux1394-devel, devel,
linux-s390, linux-scsi, linux-serial, fcoe-devel, xen-devel,
open-iscsi, linux-media, Kees Cook, linux-raid, linux-bcache,
Hans Liljestrand, David Windsor, gregkh, linux-usb, linux-kernel,
netdev, devel
In-Reply-To: <1488810076-3754-13-git-send-email-elena.reshetova@intel.com>
Hi Elena,
On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> ---
...
> @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
> "failed to register video device!\n");
> break;
> }
> - atomic_inc(&dev->num_channels);
> + refcount_set(&dev->num_channels, 1);
That's not right. The loop runs four iterations and the value after the
loop should be indeed the number of channels.
atomic_t isn't really used for reference counting here, but storing out how
many "channels" there are per hardware device, with maximum number of four
(4). I'd leave this driver using atomic_t.
> v4l2_info(&dev->v4l2_dev, "V4L2 device registered as %s\n",
> video_device_node_name(&vc->vdev));
>
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
From: Sakari Ailus @ 2017-03-07 8:22 UTC (permalink / raw)
To: Elena Reshetova
Cc: peterz, linux-pci, target-devel, linux1394-devel, devel,
linux-s390, linux-scsi, linux-serial, fcoe-devel, xen-devel,
open-iscsi, linux-media, Kees Cook, linux-raid, linux-bcache,
Hans Liljestrand, David Windsor, gregkh, linux-usb, linux-kernel,
netdev, devel
In-Reply-To: <1488810076-3754-12-git-send-email-elena.reshetova@intel.com>
On Mon, Mar 06, 2017 at 04:20:58PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* RE: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t
From: Reshetova, Elena @ 2017-03-07 7:52 UTC (permalink / raw)
To: Sergei Shtylyov, gregkh@linuxfoundation.org
Cc: devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
open-iscsi@googlegroups.com, Kees Cook,
linux-scsi@vger.kernel.org, David Windsor, peterz@infradead.org,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org, linux-bcache@vger.kernel.org,
target-devel@vger.kernel.org, linux-serial@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <c6987419-f708-9923-0f9f-87b715600045@cogentembedded.com>
> Hello.
>
> On 03/06/2017 05:20 PM, Elena Reshetova wrote:
>
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> > Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: David Windsor <dwindsor@gmail.com>
> [...]
> > diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
> > index 115414c..16c1313 100644
> > --- a/drivers/media/pci/cx88/cx88.h
> > +++ b/drivers/media/pci/cx88/cx88.h
> > @@ -24,6 +24,7 @@
> > #include <linux/i2c-algo-bit.h>
> > #include <linux/videodev2.h>
> > #include <linux/kdev_t.h>
> > +#include <linux/refcount.h>
> >
> > #include <media/v4l2-device.h>
> > #include <media/v4l2-fh.h>
> > @@ -339,7 +340,7 @@ struct cx8802_dev;
> >
> > struct cx88_core {
> > struct list_head devlist;
> > - atomic_t refcount;
> > + refcount_t refcount;
>
> Could you please keep the name aligned with above and below?
You mean "not aligned" to devlist, but with a shift like it was before?
Sure, will fix. Is the patch ok otherwise?
Best Regards,
Elena.
>
> >
> > /* board name */
> > int nr;
> >
>
> MBR, Sergei
^ permalink raw reply
* RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
From: Reshetova, Elena @ 2017-03-07 7:50 UTC (permalink / raw)
To: Johannes Thumshirn,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
fcoe-devel-s9riP+hp16TNLxjTenLetw@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
target-devel-u79uwXL29TZNg+MwTxZMZA
In-Reply-To: <536a58ba-8896-5639-cab9-bd2f13bed325-l3A5Bk7waGM@public.gmane.org>
> On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
>
> The subject is wrong, should be something like "scsi: libfc convert
> fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.
Very sorry about this: the error in the subject got from the time when I was trying to break the bigger drivers patch set into per-variable part and trying to automate the process too much :(
I will fix it in the end version!
Best Regards,
Elena
>
> Other than that
> Acked-by: Johannes Thumshirn <jth-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> --
> Johannes Thumshirn Storage
> jthumshirn-l3A5Bk7waGM@public.gmane.org +49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 1/2] md: add bad block flag to disk state
From: Hannes Reinecke @ 2017-03-07 6:54 UTC (permalink / raw)
To: jes.sorensen, Shaohua Li; +Cc: Tomasz Majchrzak, linux-raid
In-Reply-To: <wrfjlgsim9xv.fsf@gmail.com>
On 03/06/2017 09:23 PM, jes.sorensen@gmail.com wrote:
> Shaohua Li <shli@kernel.org> writes:
>> On Wed, Feb 01, 2017 at 10:53:52AM +0100, Tomasz Majchrzak wrote:
>>> On Mon, Jan 30, 2017 at 03:33:41PM -0800, Shaohua Li wrote:
>>>> On Tue, Jan 24, 2017 at 01:03:38PM +0100, Tomasz Majchrzak wrote:
>>>>> Add a new flag to report that bad blocks are present on a disk. It will
>>>>> allow userspace to notify the user of the problem.
>>>>>
>>>>> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
>>>>> ---
>>>>> drivers/md/md.c | 2 ++
>>>>> include/uapi/linux/raid/md_p.h | 1 +
>>>>> 2 files changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>>>>> index 0abb147..1a807ec 100644
>>>>> --- a/drivers/md/md.c
>>>>> +++ b/drivers/md/md.c
>>>>> @@ -6034,6 +6034,8 @@ static int get_disk_info(struct mddev *mddev, void __user * arg)
>>>>> info.state |= (1<<MD_DISK_WRITEMOSTLY);
>>>>> if (test_bit(FailFast, &rdev->flags))
>>>>> info.state |= (1<<MD_DISK_FAILFAST);
>>>>> + if (rdev->badblocks.count)
>>>>> + info.state |= (1<<MD_DISK_BB_PRESENT);
>>>>
>>>> Userspace can find if a disk has badblocks by reading the bad_blocks sysfs
>>>> file. Why adds another interface?
>>>>
>>>> Thanks,
>>>> Shaohua
>>>
>>> Yes, indeed, it can. I have chosen to do it this way to keep it consistent
>>> with mdadm which uses GET_DISK_INFO ioctl to get disk information. All data
>>> provided in this ioctl is also available in sysfs file (rdev state), however
>>> ioctl is still used (legacy). The same applies for details subcommand of
>>> mdadm. To answer your question - yes, I could avoid new flag but it would
>>> make mdadm side of my improvement much more complicated.
>>
>> I intended to avoid adding new user interface if possible. Not sure about this
>> case though. How complicated in the mdadm side if we use the bad_block sysfs
>> file?
>>
>> Jes, how do you think from the mdadm side?
>
> Hi,
>
> Sorry for being so late getting back on this, I am just getting back to
> this now.
>
> I am really split on this - if we have spare flags available, I guess
> it's not the end of the World. On the other hand there is something to
> be said for not adding any more using the old interface.
>
> Right now mdadm relies heavily on the ioctl interfaces. In order to
> migrate away from that, we need to spend a fair amount of time to
> rewriting the general interface first. Something I think we should
> invest some time into doing, but having to handle both in parallel seems
> a bad idea to me.
>
Personally I would positively _love_ a consistent interface.
ATM we have about 3 (or was it 4?) different interfaces, all of which
providing _different_ information.
(Not to mention the odd stall when reading that information...)
Coalescing all of that into _one_ set, or, better still, make sure that
one interface (sysfs?) provides all information would be a massive bonus.
And would finally enable us to provide an API for library usage.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: When will Linux support M2 on RAID ?
From: Christoph Hellwig @ 2017-03-07 4:52 UTC (permalink / raw)
To: David F.; +Cc: linux-kernel, linux-raid@vger.kernel.org
In-Reply-To: <CAGRSmLsqBF_7eGHdeA=FQbgbjSLMrbRK14mNQxyBcV0PoGYaRQ@mail.gmail.com>
On Sun, Mar 05, 2017 at 06:09:42PM -0800, David F. wrote:
> More and more systems are coming with M2 on RAID and Linux doesn't
> work unless you change the system out of RAID mode. This is becoming
> more and more of a problem. What is the status of Linux support for
> the new systems?
Your message doesn't make sense at all. MD works on absolutely any
Linux block device, and I've used it on plenty M.2 form factor devices -
not that the form factor has anything to do with how Linux would treat
a device.
^ permalink raw reply
* [PATCH v2] mdadm:add checking clustered bitmap in assemble mode
From: Zhilong Liu @ 2017-03-07 3:13 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, Zhilong Liu
In-Reply-To: <wrfjzigyks66.fsf@gmail.com>
mdadm:Both clustered and internal array don't need
to specify --bitmap when assembling array.
Signed-off-by: Zhilong Liu <zlliu@suse.com>
Acked-by: Coly Li <colyli@suse.de>
diff --git a/mdadm.c b/mdadm.c
index b5ac061..d6ad8dc 100644
--- a/mdadm.c
+++ b/mdadm.c
@@ -1095,8 +1095,10 @@ int main(int argc, char *argv[])
pr_err("bitmap file needed with -b in --assemble mode\n");
exit(2);
}
- if (strcmp(optarg, "internal") == 0) {
- pr_err("there is no need to specify --bitmap when assembling arrays with internal bitmaps\n");
+ if (strcmp(optarg, "internal") == 0 ||
+ strcmp(optarg, "clustered") == 0) {
+ pr_err("no need to specify --bitmap when assembling"
+ " arrays with internal or clustered bitmap\n");
continue;
}
bitmap_fd = open(optarg, O_RDWR);
--
2.10.2
^ permalink raw reply related
* RE: GRUB warning after replacing disk drive in RAID1
From: Peter Sangas @ 2017-03-06 22:13 UTC (permalink / raw)
To: 'Wols Lists', 'Phil Turmel',
'Reindl Harald', linux-raid
In-Reply-To: <58B81B80.6020708@youngman.org.uk>
> On March 02, 2017 5:18 AM, Wols Lists wrote :
> Look at the raid wiki
>
> https://raid.wiki.kernel.org/index.php/Converting_an_existing_system
>
> it mentions grub.
Wol, I'm trying to understand what you and others are suggesting is causing this grub warning.
according to the raid.wiki you referenced the last line of grub.cnf should look like this to support booting from RAID:
initrd /boot/initramfs-genkernel-x86_64-4.4.6-gentoo
In addition, the wiki says " you will need to configure your distro to use an initramfs.
here are the last few lines of my grub.cnf:
echo 'Loading Linux 4.4.0-36-generic ...'
linux /vmlinuz-4.4.0-36-generic root=UUID=cddffa50-9713-4205-aab6-86745735958b ro recovery nomodeset
echo 'Loading initial ramdisk ...'
initrd /initrd.img-4.4.0-36-generic
should I be concerned my grub.cnf uses initrd.img and not initramfs? My grub.cnf was last modified 11/2016 and I've rebooted successfully into a RAID1 since.
Finally, on Friday 3/3 I swapped one of the disks (sdc) in this RAID1 with a brand new identical disk. After creating the partitions and syncing I issued
install-grub /dev/sdc and there were no warnings. If my grub was broken why would there be no warning but a week ago doing the exact disk swap/same sequence of commands I got a warning. Nothing on the system was changed during that time.
Thank you.
^ permalink raw reply
* Re: [PATCH] mdadm:add man page for --symlinks
From: jes.sorensen @ 2017-03-06 21:34 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1488767997-21594-1-git-send-email-zlliu@suse.com>
Zhilong Liu <zlliu@suse.com> writes:
> In build and create mode:
> --symlinks
> Auto creation of symlinks in /dev to /dev/md, option --symlinks
> must be 'no' or 'yes' and work with --create and --build.
> In assemble mode:
> --symlinks
> See this option under Create and Build options.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH - mdadm] examine: tidy up some code.
From: jes.sorensen @ 2017-03-06 21:34 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid, Michael Shigorin
In-Reply-To: <878tonnsfn.fsf@notabene.neil.brown.name>
NeilBrown <neilb@suse.com> writes:
> Michael Shigorin reports that the 'lcc' compiler isn't able
> to deduce that 'st' must be initialized in
>
> if (c->SparcAdjust)
> st->ss->update_super(st, NULL, "sparc2.2",
>
> just because the only times it isn't initialised, 'err' is set non-zero.
>
> This results in a 'possibly uninitialised' warning.
> While there is no bug in the code, this does suggest that maybe
> the code could be made more obviously correct.
>
> So this patch:
> 1/ moves the "err" variable inside the for loop, so an error in
> one device doesn't stop the other devices from being processed
> 2/ calls 'continue' early if the device cannot be opened, so that
> a level of indent can be removed, and so that it is clear that
> 'st' is always initialised before being used
> 3/ frees 'st' if an error occured in load_super or load_container.
>
> Reported-by: Michael Shigorin <mike@altlinux.org>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
> Examine.c | 75 +++++++++++++++++++++++++++++++++------------------------------
> 1 file changed, 39 insertions(+), 36 deletions(-)
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH v1] mdadm: add checking clustered bitmap in assemble mode
From: jes.sorensen @ 2017-03-06 21:32 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1488425157-24582-1-git-send-email-zlliu@suse.com>
Zhilong Liu <zlliu@suse.com> writes:
> Both clustered and internal array don't need to specify
> --bitmap when assembling array.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>
> diff --git a/mdadm.c b/mdadm.c
> index b5d89e4..4087f77 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -1095,8 +1095,10 @@ int main(int argc, char *argv[])
> pr_err("bitmap file needed with -b in --assemble mode\n");
> exit(2);
> }
> - if (strcmp(optarg, "internal") == 0) {
> - pr_err("there is no need to specify --bitmap when assembling arrays with internal bitmaps\n");
> + if (strcmp(optarg, "internal") == 0 ||
> + strcmp(optarg, "clustered") == 0) {
> + pr_err("no need to specify --bitmap when assembling
> + arrays with internal or clustered bitmap\n");
> continue;
> }
> bitmap_fd = open(optarg, O_RDWR);
This doesn't build - could you please send me a working patch.
Thanks,
Jes
cc -Wall -Werror -Wstrict-prototypes -Wextra -Wno-unused-parameter -ggdb -DSendmail=\""/usr/sbin/sendmail -t"\" -DCONFFILE=\"/etc/mdadm.conf\" -DCONFFILE2=\"/etc/mdadm/mdadm.conf\" -DMAP_DIR=\"/run/mdadm\" -DMAP_FILE=\"map\" -DMDMON_DIR=\"/run/mdadm\" -DFAILED_SLOTS_DIR=\"/run/mdadm/failed-slots\" -DNO_COROSYNC -DNO_DLM -DVERSION=\"4.0-6-g8383db9\" -DVERS_DATE="\"2017-03-06\"" -DUSE_PTHREADS -DBINDIR=\"/sbin\" -c -o mdadm.o mdadm.c
mdadm.c: In function ‘main’:
mdadm.c:1100:12: error: missing terminating " character [-Werror]
pr_err("no need to specify --bitmap when assembling
^
mdadm.c:1101:48: error: missing terminating " character [-Werror]
arrays with internal or clustered bitmap\n");
^ permalink raw reply
* Re: [PATCH] mdadm:check the nodes when operate clustered array
From: jes.sorensen @ 2017-03-06 21:28 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1488364953-20456-1-git-send-email-zlliu@suse.com>
Zhilong Liu <zlliu@suse.com> writes:
> It doesn't make sense to write_bitmap with less than 2 nodes,
> in order to avoid 'write_bitmap' received invalid nodes number,
> it would be better to do checking nodes in getopt operations.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
> ---
> such as following method would reproduce the issue.
> # mdadm -CR /dev/md0 -l1 -n2 --bitmap=internal /dev/sda /dev/sdb
> # mdadm --grow /dev/md0 --bitmap=none
> # mdadm --grow /dev/md0 --bitmap=clustered --nodes=1
> # mdadm -X /dev/sda, it would be written internal bitmap.
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH] mdadm:fix typo in comment
From: jes.sorensen @ 2017-03-06 21:27 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1488357873-19495-1-git-send-email-zlliu@suse.com>
Zhilong Liu <zlliu@suse.com> writes:
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
>
> diff --git a/mdadm.c b/mdadm.c
> index b5d89e4..16fd49a 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -1268,7 +1268,7 @@ int main(int argc, char *argv[])
> * hopefully it's mostly right but there might be some stuff
> * missing
> *
> - * That is mosty checked in the per-mode stuff but...
> + * That is mostly checked in the per-mode stuff but...
> *
> * For @,B,C and A without -s, the first device listed must be
> * an md device. We check that here and open it.
Applied!
Thanks,
Jes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox