* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Nix @ 2017-05-01 20:12 UTC (permalink / raw)
To: Wols Lists
Cc: Roman Mamedov, John Stoffel, Mateusz Korniak, Ron Leach,
linux-raid
In-Reply-To: <59061BFF.2070503@youngman.org.uk>
On 30 Apr 2017, Wols Lists verbalised:
> On 30/04/17 17:10, Nix wrote:
>> This is a one-off with tooling to manage it: from my perspective, I just
>> kick off the autobuilders etc and they'll automatically use transient
>> space for objdirs. (And obviously this is all scripted so it is no
>> harder than making or removing directories would be: typing 'mktransient
>> foo' to automatically create a dir in transient space and set up a bind
>> mount to it -- persisted across boots -- in the directory' foo' is
>> literally a few letters more than typing 'mkdir foo'.)
>
> This sounds like me with tmpfs. Okay, mine don't persist across reboots,
> but if it's in your build scripts, can't they create a tmpfs and do the
> builds in that?
Even though I have 128GiB RAM, I don't want a tmpfs for everything
(though I use it for a lot, oh yes). Some of the transient stuff is
things like QEMU CoW disk images that I don't want to lose on every
reboot (though rebuilding them is not too annoying, it is not totally
ignorable either); other stuff is things like vapoursynth intermediates
which can easily exceed 500GiB, which are only ever read once but
nonetheless just won't fit.
--
NULL && (void)
^ permalink raw reply
* [PATCH] md/raid10: skip spare disk as 'first' disk
From: Shaohua Li @ 2017-05-01 19:22 UTC (permalink / raw)
To: linux-raid; +Cc: Guoqing Jiang, NeilBrown
Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
a case in reshape, the first rdev could be a spare disk, which shouldn't
be accounted as the first disk since it doesn't include the offset info.
Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
Cc: Guoqing Jiang <gqjiang@suse.com>
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
---
drivers/md/raid10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 2883b72..cce23be 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4079,8 +4079,8 @@ static int raid10_start_reshape(struct mddev *mddev)
diff = 0;
if (first || diff < min_offset_diff)
min_offset_diff = diff;
+ first = 0;
}
- first = 0;
}
if (max(before_length, after_length) > min_offset_diff)
--
2.9.3
^ permalink raw reply related
* Re: fixing raid1
From: jdd @ 2017-05-01 17:43 UTC (permalink / raw)
Cc: linux-raid
In-Reply-To: <20170501221954.52b2dd76@natsu>
Le 01/05/2017 à 19:19, Roman Mamedov a écrit :
> It appears you just need to do the 2nd step as listed in that wiki,
>
> mdadm --grow /dev/md127 --raid-devices=2
>
> Did you try it?
I didn't (grow... was thinking it was to make it bigger :-()
but it works perfectly
done
Thanks
jdd
^ permalink raw reply
* Re: fixing raid1
From: Roman Mamedov @ 2017-05-01 17:19 UTC (permalink / raw)
To: jdd@dodin.org; +Cc: linux-raid
In-Reply-To: <c416bcba-7a5d-a409-42ca-2eb82eca32b7@dodin.org>
On Mon, 1 May 2017 18:34:14 +0200
"jdd@dodin.org" <jdd@dodin.org> wrote:
> I have built a three disks raid1 on openSUSE 42.2. so far so good, all
> worked perfectly
>
> but later on I had no more use of the machine with as much disks, and
> wanted to reclaim one disk. This one was in a esata dock.
>
> At the moment I didn't found a way to make this cleanly (I found it it
> too late in the linux raid wiki
> https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm#Removing_a_disk_from_an_array)
>
> so, I stopped the computer and removed the dock.
>
> The computer rebooted perfectly, but in slightly degraded mode (see below)
>
> I don't find a way to tell the system that it have to forget the third
> disk. May be it's not necessary.
It appears you just need to do the 2nd step as listed in that wiki,
mdadm --grow /dev/md127 --raid-devices=2
Did you try it?
> # mdadm --detail /dev/md127
> /dev/md127:
> Version : 1.0
> Creation Time : Wed Dec 21 22:43:31 2016
> Raid Level : raid1
> Array Size : 976758592 (931.51 GiB 1000.20 GB)
> Used Dev Size : 976758592 (931.51 GiB 1000.20 GB)
> Raid Devices : 3
> Total Devices : 2
> Persistence : Superblock is persistent
>
> Intent Bitmap : Internal
>
> Update Time : Mon May 1 15:29:48 2017
> State : clean, degraded
> Active Devices : 2
> Working Devices : 2
> Failed Devices : 0
> Spare Devices : 0
>
> Name : any:jdd-raid
> UUID : 4d57c009:5d7fc724:07376d9a:8ecb39a2
> Events : 9592
>
> Number Major Minor RaidDevice State
> 0 8 1 0 active sync /dev/sda1
> 1 8 17 1 active sync /dev/sdb1
> - 0 0 2 removed
> --
> 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
--
With respect,
Roman
^ permalink raw reply
* fixing raid1
From: jdd @ 2017-05-01 16:34 UTC (permalink / raw)
To: linux-raid
Hello,
I'm new to this mailing list, so forgive me if I break some etiquette
I have an academic problem. I mean that the target computer in not in
production and do not hold any essential data. I try to learn some
aspects of linux raid.
I have built a three disks raid1 on openSUSE 42.2. so far so good, all
worked perfectly
but later on I had no more use of the machine with as much disks, and
wanted to reclaim one disk. This one was in a esata dock.
At the moment I didn't found a way to make this cleanly (I found it it
too late in the linux raid wiki
https://raid.wiki.kernel.org/index.php/A_guide_to_mdadm#Removing_a_disk_from_an_array)
so, I stopped the computer and removed the dock.
The computer rebooted perfectly, but in slightly degraded mode (see below)
I don't find a way to tell the system that it have to forget the third
disk. May be it's not necessary.
Do you have a clue?
thanks
jdd
# mdadm --detail /dev/md127
/dev/md127:
Version : 1.0
Creation Time : Wed Dec 21 22:43:31 2016
Raid Level : raid1
Array Size : 976758592 (931.51 GiB 1000.20 GB)
Used Dev Size : 976758592 (931.51 GiB 1000.20 GB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon May 1 15:29:48 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : any:jdd-raid
UUID : 4d57c009:5d7fc724:07376d9a:8ecb39a2
Events : 9592
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
- 0 0 2 removed
^ permalink raw reply
* Fast Loans
From: Loans Service @ 2017-05-01 11:28 UTC (permalink / raw)
To: Recipients
Do you need a loan to pay up bill or to start a business? Email Us
^ permalink raw reply
* Re: [dm-devel] [mdadm PATCH 4/4] Create: tell udev device is not ready when first created.
From: NeilBrown @ 2017-05-01 4:35 UTC (permalink / raw)
To: Peter Rajnoha, Jes Sorensen; +Cc: linux-raid, dm-devel
In-Reply-To: <f9977410-5a8e-1a78-1406-fc9875f83d13@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 7671 bytes --]
On Fri, Apr 28 2017, Peter Rajnoha wrote:
> On 04/28/2017 05:55 AM, NeilBrown wrote:
>> On Wed, Apr 26 2017, Peter Rajnoha wrote:
>>
>>> On 04/20/2017 11:35 PM, NeilBrown wrote:
>>>> If we wanted an more permanent udev rule, we would need to record the
>>>> devices that should be ignored in the filesystem somewhere else.
>>>> Maybe in /run/mdadm.
>>>> e.g.
>>>>
>>>> KERNEL=="md*", TEST="/run/mdadm/creating-$kernel", ENV{SYSTEMD_READY}="0"
>>>>
>>>> Then we could have something like the following (untested) in mdadm.
>>>> Does that seem more suitable?
>>>>
>>>
>>> Yes, please, if possible, go for a permanent udev rule surely - this
>>> will make it much easier for other foreign tools to hook in properly if
>>> needed and it would also be much easier to debug.
>>
>> I'm leaning towards the files-in-/run/mdadm approach too. I'll make a
>> proper patch.
>>
>>>
>>> But, wouldn't it be better if we could just pass this information ("not
>>> initialized yet") as RUN_ARRAY md ioctl parameter? In that case the md
>>> driver in kernel could add the variable to the uevent it generates which
>>> userspace udev rules could check for easily. This way, we don't need to
>>> hassle with creating files in filesystem and the information would be
>>> directly a part of the uevent the md kernel driver generates (so
>>> directly accessible in udev rules too). Also, possibly adding more
>>> variables for other future scenarios if needed.
>>
>> When would we clear the "not initialised yet" flag in the kernel, and
>> how? And would that be enough.
>
> The flag wouldn't be stored in kernel, md kernel driver would just pass
> the flag with the uevent as it received in with ioctl/sysfs request to
> create a new dev. The udev in userspace would handle the state
> transition then from "flagged as not-initialized" state to "initilized"
> by checking the sequence of events as they come.
>
> We should have this sequence I assume:
>
> 1) "add" (creating dev, not usable yet)
> 2) "change" (activated dev, but not initialized yet)
> 3) "synthetic change" (after wiping the dev and closing it, the WATCH
> rule fires)
>
"Should" is arguable, but there are no guarantees of this sequence.
A particular cause of irregular sequencing is when an array is assembled
by the initrd, then after the real root is mounted, something runs
udevadm trigger --action=add
(e.g. systemd-udev-triggger.service).
In that case, 'add' is the first and only message that the
full-root-available udev sees, so it is not safe to ignore the array as
"not usable yet".
>>
>> When mdadm creates an md array, at least 3 uevents get generated.
>> The first is generated when the md device object is created, either by
>> opening the /dev/mdXX file, or by writing magic to somewhere in sysfs.
>> The second is generated when the array is started and the content is
>> visible.
>> The third is generated when mdadm closes the file descriptor. It opens
>> /dev/mdXX for O_RDWR and performs ioctls on this, and then closes it.
>> Because udev uses inotify to watch for a 'close for a writable file
>> descriptor', this generates another event.
>>
>> We need to ensure that none of these cause udev to run anything that
>> inspects the contents of the array.
>> Of the three, only the second one is directly under the control of the
>> md module, so only that one can add an environment variable.
>>
>> It might be possible to avoid the last one (by not opening for write),
>> but I cannot see a way to avoid the first one.
>
> So the first event is the "add" event ("md device object created") - in
> this case, the device is not yet usable anyway I suppose, so we can skip
> udev scans for this event right away (unless it's the synthetic "add"
> event which is generated by writing "add" to /sys/block/.../uevent file
> or alternatively using udevadm trigger - but we should be able to
> recognize this event "synthetic add event" because it always comes after
> the activating "change" event, otherwise we can skip scans).
"not yet usable anyway" is not reliable. It is very easy for mdadm to
finish making the array usable before udev gets around to processing the
initial "add" event.
You seem to be suggesting that udev rules should try to reverse-engineer
the sequence of events and deduce what is meant from that sequence. I
doubt that would be very robust.
>
> The second event, which is the "change" event, would be marked with the
> new "not initialized" flag. And so we skip the scans in udev too.
(one obvious problem with this approach is that it cannot work with old
kernels, while my approach only requires an update to mdadm)
>
> Then mdadm opens the devive, clears any old content/signatures the data
> area may contain, then closes it - this generates the third event -
> which is the "synthetic change" event (as a result of the inotify WATCH
> rule). And this one would drop the "not initialized" flag in udev db and
> the scans in udev are now enabled.
Nope, it would be incorrect for mdadm to clear any old content.
Sometimes people want to ignore old content. Sometimes they very
definitely want to use it. It would be wrong for any code to try to
guess what is wanted.
>
> So we should be able to handle all three kinds of events I think.
>
> Now, as for even better synthetic event recognition, I've proposed a
> patch recently where udev as well as any other tool generating these
> synthetic events can add variables for more detailed event
> identification, so this one should help us in the future even more in
> these situations: https://lkml.org/lkml/2017/3/15/461. With this, we can
> even disable the WATCH rule till the device is properly initialized and
> the tool can generate the event itself by writing the
> /sys/block/.../uevent file with a variable that the tool can then wait
> for even (so the tool doesn't exit till the device is not properly
> initialized). Once this initialization is all done, the WATCH rule can
> be enabled for the dev. Also, with this, we don't need to be afraid that
> some other tool fired the WATCH rule by chance if it opened the dev for
> RW and closed it by mistake before we had a chance to initialize it
> (which would fire the synthetic change event before the
> wiping/initialization).
It sounds to me like you are adding a lot of complexity to an
already-fragile system. I'm not filled with confidence - sorry.
Thanks,
NeilBrown
>
>>
>> I don't think that making a file appear in /run is really very different
>> from making a variable appear in a uevent. If the variable were
>> describing the event itself there would be a different, but it would be
>> describing the state of the device. So the only important difference is
>> "which is easier to work with". I think creating an deleting a file is
>> easier to setting and clearing a variable.
>>
>
> Yes, I agree that it's an alternative solution - it definitely and
> surely improves current situation, either if we choose to write the file
> or pass the flag in the uevent directly. It's just that with the
> information written in filesystem, we have something external to check
> for in addition to processing the uevent variables while we don't need
> to, I think. As I described the sequence of events above, I think we
> should be able to recognize the events properly and we should be able to
> drop the flag automatically.
>
> --
> Peter
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Wols Lists @ 2017-04-30 17:16 UTC (permalink / raw)
To: Nix, Roman Mamedov; +Cc: John Stoffel, Mateusz Korniak, Ron Leach, linux-raid
In-Reply-To: <87fugpkhap.fsf@esperi.org.uk>
On 30/04/17 17:10, Nix wrote:
> This is a one-off with tooling to manage it: from my perspective, I just
> kick off the autobuilders etc and they'll automatically use transient
> space for objdirs. (And obviously this is all scripted so it is no
> harder than making or removing directories would be: typing 'mktransient
> foo' to automatically create a dir in transient space and set up a bind
> mount to it -- persisted across boots -- in the directory' foo' is
> literally a few letters more than typing 'mkdir foo'.)
This sounds like me with tmpfs. Okay, mine don't persist across reboots,
but if it's in your build scripts, can't they create a tmpfs and do the
builds in that?
My system maxes out at 16GB ram, so twice ram per disk as swap gives me
32GB swap/disk by 2 disks gives me 64GB of swap for all my transient
stuff. Running gentoo, I need that space to build gcc, LO etc :-)
Cheers,
Wol
^ permalink raw reply
* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Roman Mamedov @ 2017-04-30 16:47 UTC (permalink / raw)
To: Nix; +Cc: John Stoffel, Mateusz Korniak, Ron Leach, linux-raid
In-Reply-To: <87fugpkhap.fsf@esperi.org.uk>
On Sun, 30 Apr 2017 17:10:22 +0100
Nix <nix@esperi.org.uk> wrote:
> > It's not like the difference between the so called "fast" and "slow" parts is
> > 100- or even 10-fold. Just SSD-cache the entire thing (I prefer lvmcache not
> > bcache) and go.
>
> I'd do that if SSDs had infinite lifespan. They really don't. :)
> lvmcache doesn't cache everything, only frequently-referenced things, so
> the problem is not so extreme there -- but
Yes I was concerned the lvmcache will over-use the SSD by mistakenly caching
streaming linear writes and the like -- and it absolutely doesn't. (it can
during the initial fill-up of the cache, but not afterwards).
Get an MLC-based SSD if that gives more peace of mind, but tests show even the
less durable TLC-based ones have lifespan measuring in hundreds of TB.
http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead
One SSD that I have currently has 19 TB written to it over its entire 4.5 year
lifespan. Over the past few months of being used as lvmcache for a 14 TB
bulk data array and a separate /home FS, new writes average at about 16 GB/day.
Given a VERY conservative 120 TBW endurance estimate, this SSD should last me
all the way into year 2034 at least.
> the fact that it has to be set up anew for *each LV* is a complete killer
> for me, since I have encrypted filesystems and things that *have* to be on
> separate LVs and I really do not want to try to figure out the right balance
> between distinct caches, thanks (oh and also you have to get the metadata
> size right, and if you get it wrong and it runs out of space all hell breaks
> loose, AIUI). bcaching the whole block device avoids all this pointless
> complexity. bcache just works.
Oh yes I wish they had a VG-level lvmcache. Still, it feels more mature than
bcache, the latter barely has any userspace management and monitoring tools
(having to fiddle with "echo > /sys/..." and "cat /sys/..." is not the state
of something you'd call a finished product). And the killer for me was that
there is no way to stop using bcache on a partition, once it's a "bcache
backing device" there is no way to migrate back to a raw partition, you're
stuck with it.
> This is a one-off with tooling to manage it: from my perspective, I just
> kick off the autobuilders etc and they'll automatically use transient
> space for objdirs. (And obviously this is all scripted so it is no
> harder than making or removing directories would be: typing 'mktransient
> foo' to automatically create a dir in transient space and set up a bind
> mount to it -- persisted across boots -- in the directory' foo' is
> literally a few letters more than typing 'mkdir foo'.)
Sorry for being rather blunt initially, still IMO the amount if micromanagement
required (and complexity introduced) is staggering compared to the benefits
reaped -- and it all appears to stem from underestimating the modern SSDs.
I'd suggest just get one and try "killing" it with your casual daily usage,
you'll find (via TBW numbers you will see in SMART compared even to vendor
spec'd ones, not to mention what tech sites' field tests show) that you just
can't, not until deep into a dozen of years later into the future.
--
With respect,
Roman
^ permalink raw reply
* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Nix @ 2017-04-30 16:10 UTC (permalink / raw)
To: Roman Mamedov; +Cc: John Stoffel, Mateusz Korniak, Ron Leach, linux-raid
In-Reply-To: <20170430182134.0e8c6dc0@natsu>
On 30 Apr 2017, Roman Mamedov spake thusly:
> On Sun, 30 Apr 2017 13:04:36 +0100
> Nix <nix@esperi.org.uk> wrote:
>
>> Aside: the storage server I've just set up has a different rationale for
>> having multiple mds. There's one in the 'fast part' of the rotating
>> rust, and one in the 'slow part' (for big archival stuff that is rarely
>> written to); the slow one has an LVM PV directly atop it, but the fast
>> one has a bcache and then an LVM PV built atop that. The fast disk also
>> has an md journal on SSD. Both are joined into one LVM VG. (The
>> filesystem journals on the fast part are also on the SSD.)
>
> It's not like the difference between the so called "fast" and "slow" parts is
> 100- or even 10-fold. Just SSD-cache the entire thing (I prefer lvmcache not
> bcache) and go.
I'd do that if SSDs had infinite lifespan. They really don't. :)
lvmcache doesn't cache everything, only frequently-referenced things, so
the problem is not so extreme there -- but the fact that it has to be
set up anew for *each LV* is a complete killer for me, since I have
encrypted filesystems and things that *have* to be on separate LVs and I
really do not want to try to figure out the right balance between
distinct caches, thanks (oh and also you have to get the metadata size
right, and if you get it wrong and it runs out of space all hell breaks
loose, AIUI). bcaching the whole block device avoids all this pointless
complexity. bcache just works.
>> So I have a chunk of 'slow space' for things like ISOs and video files
>> that are rarely written to (so a RAID journal is needless) and never
>> want to be SSD-cached, and another (bigger) chunk of space for
>> everything else, SSD-cached for speed and RAID-journalled for powerfail
>> integrity.
>>
>> (... actually it's more complex than that: there is *also* a RAID-0
>> containing an ext4 sans filesystem journal at the start of the disk for
>> transient stuff like build trees that are easily regenerated, rarely
>> needed more than once, and where journalling the writes or caching the
>> reads on SSD is a total waste of SSD lifespan. If *that* gets corrupted,
>> the boot machinery simply re-mkfses it.)
>
> You have too much time on your hands if you have nothing better to do than
> to babysit all that b/s.
This is a one-off with tooling to manage it: from my perspective, I just
kick off the autobuilders etc and they'll automatically use transient
space for objdirs. (And obviously this is all scripted so it is no
harder than making or removing directories would be: typing 'mktransient
foo' to automatically create a dir in transient space and set up a bind
mount to it -- persisted across boots -- in the directory' foo' is
literally a few letters more than typing 'mkdir foo'.)
Frankly the annoyance factor of having to replace the SSD years in
advance because every test build does several gigabytes of objdir writes
that I'm not going to care about in fifteen minutes would be far higher
than the annoyance factor of having to, uh, write three scripts about
fifteen lines long to manage the transient space.
--
NULL && (void)
^ permalink raw reply
* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Roman Mamedov @ 2017-04-30 13:21 UTC (permalink / raw)
To: Nix; +Cc: John Stoffel, Mateusz Korniak, Ron Leach, linux-raid
In-Reply-To: <87o9veje3v.fsf@esperi.org.uk>
On Sun, 30 Apr 2017 13:04:36 +0100
Nix <nix@esperi.org.uk> wrote:
> Aside: the storage server I've just set up has a different rationale for
> having multiple mds. There's one in the 'fast part' of the rotating
> rust, and one in the 'slow part' (for big archival stuff that is rarely
> written to); the slow one has an LVM PV directly atop it, but the fast
> one has a bcache and then an LVM PV built atop that. The fast disk also
> has an md journal on SSD. Both are joined into one LVM VG. (The
> filesystem journals on the fast part are also on the SSD.)
It's not like the difference between the so called "fast" and "slow" parts is
100- or even 10-fold. Just SSD-cache the entire thing (I prefer lvmcache not
bcache) and go.
> So I have a chunk of 'slow space' for things like ISOs and video files
> that are rarely written to (so a RAID journal is needless) and never
> want to be SSD-cached, and another (bigger) chunk of space for
> everything else, SSD-cached for speed and RAID-journalled for powerfail
> integrity.
>
> (... actually it's more complex than that: there is *also* a RAID-0
> containing an ext4 sans filesystem journal at the start of the disk for
> transient stuff like build trees that are easily regenerated, rarely
> needed more than once, and where journalling the writes or caching the
> reads on SSD is a total waste of SSD lifespan. If *that* gets corrupted,
> the boot machinery simply re-mkfses it.)
You have too much time on your hands if you have nothing better to do than
to babysit all that b/s.
--
With respect,
Roman
^ permalink raw reply
* Re: Recovery on new 2TB disk: finish=7248.4min (raid1)
From: Nix @ 2017-04-30 12:04 UTC (permalink / raw)
To: John Stoffel; +Cc: Mateusz Korniak, Ron Leach, linux-raid
In-Reply-To: <22786.16524.435313.304834@quad.stoffel.home>
On 27 Apr 2017, John Stoffel spake thusly:
> No, big MD devices are sync'd in parallel assuming MD thinks they're
> on seperate devices. Now in this case I admit I might have jumped the
> gun, but I'm mostly commenting on the use of multiple MD RAID setups
> on a single pair of disks.
>
> It's inefficient. It's a pain to manage. You lose flexibility to
> resize.
Aside: the storage server I've just set up has a different rationale for
having multiple mds. There's one in the 'fast part' of the rotating
rust, and one in the 'slow part' (for big archival stuff that is rarely
written to); the slow one has an LVM PV directly atop it, but the fast
one has a bcache and then an LVM PV built atop that. The fast disk also
has an md journal on SSD. Both are joined into one LVM VG. (The
filesystem journals on the fast part are also on the SSD.)
So I have a chunk of 'slow space' for things like ISOs and video files
that are rarely written to (so a RAID journal is needless) and never
want to be SSD-cached, and another (bigger) chunk of space for
everything else, SSD-cached for speed and RAID-journalled for powerfail
integrity.
You can't do that with one big md array, since you can't have one array
which is partially journalled and partially not. (You *can*, with the
aid of dm, have one array which is partially bcached and partially not,
but frankly messing about with direct dm linears seemed pointlessly
painful. It's annoying enough to set up an md->bcache->LVM setup at
boot: adding dmsetup to that as well seemed like pain beyond the call of
duty.)
(... actually it's more complex than that: there is *also* a RAID-0
containing an ext4 sans filesystem journal at the start of the disk for
transient stuff like build trees that are easily regenerated, rarely
needed more than once, and where journalling the writes or caching the
reads on SSD is a total waste of SSD lifespan. If *that* gets corrupted,
the boot machinery simply re-mkfses it.)
--
NULL && (void)
^ permalink raw reply
* Re: How important is SCTERC?
From: Ram Ramesh @ 2017-04-29 23:45 UTC (permalink / raw)
To: Peter Grandi, Linux RAID
In-Reply-To: <22787.16039.574815.87299@tree.ty.sabi.co.uk>
On 04/28/2017 08:07 AM, Peter Grandi wrote:
>> [ ... ] I do run tler.sh that sets 180s timeout for drives
>> that do not have scterc from /etc/rc.local. Am I putting my
>> data in serious danger?
> No.
>
>> I only have videos and tv recordings in this md
> The problem with SCT/ERC absence is that the 2-3 minutes of
> retries suspend IO for that long, and for people running
> interactive applications (usually LAMP-style web applications)
> that is a bad idea, but in your case you seem to have just a
> personal archive of entertainment files.
>
> For interactive "enterprise" applications the common practice is
> to reduce the error timeout to 1-2 seconds, so the failing drive
> drops out of the MD set quickly and can be replaced, minimizing
> delays.
Interestingly, the drives did not pass SMART test and mkfs.ext4 -c -c
checks. So, I returned them. I plan to buy WD gold (the other extreme in
price point :-)
>
>> which can be replaced with significant effort (about 12TB of
>> movies and tv shows will take some time to copy from my
>> DVDs/BDs)
> Backups are very important, and RAID is not an alternative to
> backups. You can buy and use SMR disk drives as if they were
> tapes (or with a filesystem like NILFS2) to do that backup, and
> they are quite cheap.
I am using my actual DVDs as backup. For TV shows they are available in
Netflix, if I really want to watch them again.
However, your point is well taken. I will think about backup as my
collection has grown over the years and it will be really a pain to go
back to DVDs to populate my media server.
> --
> 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: Recover array after I panicked
From: Andreas Klauer @ 2017-04-29 9:56 UTC (permalink / raw)
To: Patrik Dahlström; +Cc: Brad Campbell, linux-raid
In-Reply-To: <4c5d312b-fba6-da20-e08f-ed1a4ba5c313@powerlamerz.org>
On Sat, Apr 29, 2017 at 12:46:15AM +0200, Patrik Dahlström wrote:
> mdadm: cannot open /dev/sda: Device or resource busy
Well, normally you're not supposed to do this. :-)
Easy to wreck your data if you do.
> My overlay setup is keeping /dev/sd[abdce] busy. How do I setup the
> overlay to keep it from occupying the disks?
You could create the RAID first and the overlay afterwards.
Or you can create loop devices on the busy devices and use those.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Recover array after I panicked
From: Patrik Dahlström @ 2017-04-28 22:46 UTC (permalink / raw)
To: Andreas Klauer; +Cc: Brad Campbell, linux-raid
In-Reply-To: <20170427231242.GA5138@metamorpher.de>
On 04/28/2017 01:12 AM, Andreas Klauer wrote:
> On Thu, Apr 27, 2017 at 09:57:20PM +0200, Patrik Dahlström wrote:
> The quick and dirty method is... grow using dd from 5disk raid (overlay)
> to 6disk raid (no overlay) starting from the correct offset (verify!).
> That resumes your reshape in an offline-ish, hackish manner, and once
> it's done you have the whole thing. That's the theory anyway.
>
> Pseudocode:
>
> mdadm --create /dev/md5 --assume-clean /dev/overlay/{a,b,c}
> mdadm --create /dev/md6 --assume-clean /dev/{a,b,c,d} # +1 drive
I'm stuck at this step
$ mdadm --create --assume-clean /dev/md1 --data-offset=126464K --level=5 --raid-devices=6 /dev/sda /dev/sdb /dev/sdd /dev/sdc /dev/sde /dev/sdf
mdadm: cannot open /dev/sda: Device or resource busy
My overlay setup is keeping /dev/sd[abdce] busy. How do I setup the
overlay to keep it from occupying the disks?
Overlays are currently created like this:
$ dmsetup create ${b} --table "0 $size_bkl snapshot $d $loop P 8"
Best regards
// Patrik
^ permalink raw reply
* 15592 linux-raid
From: mdavis @ 2017-04-28 19:45 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: 46.zip --]
[-- Type: application/zip, Size: 4195 bytes --]
^ permalink raw reply
* Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-28 19:01 UTC (permalink / raw)
To: Herbert Xu
Cc: dri-devel, Stephen Bates, dm-devel, target-devel,
Christoph Hellwig, devel, James E.J. Bottomley, linux-scsi,
linux-nvdimm, linux-rdma, Sumit Semwal, Ross Zwisler, open-iscsi,
linux-media, intel-gfx, sparmaintainer, linux-raid, Dan Williams,
megaraidlinux.pdl, Jens Axboe, Martin K. Petersen, netdev,
Matthew Wilcox, linux-mmc, linux-kernel, linux-crypto,
Greg Kroah-Hartman
In-Reply-To: <20170428175147.GA9596@gondor.apana.org.au>
On 28/04/17 11:51 AM, Herbert Xu wrote:
> On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>>
>>
>> On 28/04/17 12:30 AM, Herbert Xu wrote:
>>> You are right. Indeed the existing code looks buggy as they
>>> don't take sg->offset into account when doing the kmap. Could
>>> you send me some patches that fix these problems first so that
>>> they can be easily backported?
>>
>> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
>> both do have the sg->offset accounted for. I'll send a patch for the
>> buggy one shortly.
>
> I think they're all buggy when sg->offset is greater than PAGE_SIZE.
Yes, technically. But that's a _very_ common mistake. Pretty nearly
every case I looked at did not take that into account. I don't think
sg's that point to more than one continuous page are all that common.
Fixing all those cases without making a common function is a waste of
time IMO.
Logan
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
From: Herbert Xu @ 2017-04-28 17:51 UTC (permalink / raw)
To: Logan Gunthorpe
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, James E.J. Bottomley,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
Martin K. Petersen, netdev-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
David S. Miller
In-Reply-To: <5a08708b-c3b8-41fe-96de-607a109eacbd-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>
>
> On 28/04/17 12:30 AM, Herbert Xu wrote:
> > You are right. Indeed the existing code looks buggy as they
> > don't take sg->offset into account when doing the kmap. Could
> > you send me some patches that fix these problems first so that
> > they can be easily backported?
>
> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
> both do have the sg->offset accounted for. I'll send a patch for the
> buggy one shortly.
I think they're all buggy when sg->offset is greater than PAGE_SIZE.
Thanks,
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] md/raid5: make use of spin_lock_irq over local_irq_disable + spin_lock
From: Julia Cartwright @ 2017-04-28 17:41 UTC (permalink / raw)
To: Shaohua Li, Sebastian Andrzej Siewior
Cc: linux-raid, linux-rt-users, linux-kernel, Alexander GQ Gerasiov
In-Reply-To: <20170427185719.708758b6@brick.gerasiov.net>
On mainline, there is no functional difference, just less code, and
symmetric lock/unlock paths.
On PREEMPT_RT builds, this fixes the following warning, seen by
Alexander GQ Gerasiov, due to the sleeping nature of spinlocks.
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:993
in_atomic(): 0, irqs_disabled(): 1, pid: 58, name: kworker/u12:1
CPU: 5 PID: 58 Comm: kworker/u12:1 Tainted: G W 4.9.20-rt16-stand6-686 #1
Hardware name: Supermicro SYS-5027R-WRF/X9SRW-F, BIOS 3.2a 10/28/2015
Workqueue: writeback wb_workfn (flush-253:0)
Call Trace:
dump_stack+0x47/0x68
? migrate_enable+0x4a/0xf0
___might_sleep+0x101/0x180
rt_spin_lock+0x17/0x40
add_stripe_bio+0x4e3/0x6c0 [raid456]
? preempt_count_add+0x42/0xb0
raid5_make_request+0x737/0xdd0 [raid456]
Reported-by: Alexander GQ Gerasiov <gq@redlab-i.ru>
Tested-by: Alexander GQ Gerasiov <gq@redlab-i.ru>
Signed-off-by: Julia Cartwright <julia@ni.com>
---
Hey All-
While this fixes a problem on RT primarily, the patch is equally applicable
upstream, as such probably makes sense to be pulled through the md tree. It
may also make sense to be pulled directly into rt-devel.
Alexander-
I turned your "I confirm the fix" to a 'Tested-by', let me know if that's a problem.
Thanks,
Julia
drivers/md/raid5.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index fa2c4de32a64..54dc2995aeee 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -110,8 +110,7 @@ static inline void unlock_device_hash_lock(struct r5conf *conf, int hash)
static inline void lock_all_device_hash_locks_irq(struct r5conf *conf)
{
int i;
- local_irq_disable();
- spin_lock(conf->hash_locks);
+ spin_lock_irq(conf->hash_locks);
for (i = 1; i < NR_STRIPE_HASH_LOCKS; i++)
spin_lock_nest_lock(conf->hash_locks + i, conf->hash_locks);
spin_lock(&conf->device_lock);
@@ -121,9 +120,9 @@ static inline void unlock_all_device_hash_locks_irq(struct r5conf *conf)
{
int i;
spin_unlock(&conf->device_lock);
- for (i = NR_STRIPE_HASH_LOCKS; i; i--)
- spin_unlock(conf->hash_locks + i - 1);
- local_irq_enable();
+ for (i = NR_STRIPE_HASH_LOCKS - 1; i; i--)
+ spin_unlock(conf->hash_locks + i);
+ spin_unlock_irq(conf->hash_locks);
}
/* bio's attached to a stripe+device for I/O are linked together in bi_sector
@@ -732,12 +731,11 @@ static bool is_full_stripe_write(struct stripe_head *sh)
static void lock_two_stripes(struct stripe_head *sh1, struct stripe_head *sh2)
{
- local_irq_disable();
if (sh1 > sh2) {
- spin_lock(&sh2->stripe_lock);
+ spin_lock_irq(&sh2->stripe_lock);
spin_lock_nested(&sh1->stripe_lock, 1);
} else {
- spin_lock(&sh1->stripe_lock);
+ spin_lock_irq(&sh1->stripe_lock);
spin_lock_nested(&sh2->stripe_lock, 1);
}
}
@@ -745,8 +743,7 @@ static void lock_two_stripes(struct stripe_head *sh1, struct stripe_head *sh2)
static void unlock_two_stripes(struct stripe_head *sh1, struct stripe_head *sh2)
{
spin_unlock(&sh1->stripe_lock);
- spin_unlock(&sh2->stripe_lock);
- local_irq_enable();
+ spin_unlock_irq(&sh2->stripe_lock);
}
/* Only freshly new full stripe normal write stripe can be added to a batch list */
--
2.12.0
^ permalink raw reply related
* Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-28 16:53 UTC (permalink / raw)
To: Herbert Xu
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, James E.J. Bottomley,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
Martin K. Petersen, netdev-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
David S. Miller
In-Reply-To: <20170428063039.GB6817-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On 28/04/17 12:30 AM, Herbert Xu wrote:
> You are right. Indeed the existing code looks buggy as they
> don't take sg->offset into account when doing the kmap. Could
> you send me some patches that fix these problems first so that
> they can be easily backported?
Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam
both do have the sg->offset accounted for. I'll send a patch for the
buggy one shortly.
Logan
^ permalink raw reply
* Re: [PATCH] Add a comment to indicate valid fallthrough
From: Khem Raj @ 2017-04-28 15:16 UTC (permalink / raw)
To: linux-raid; +Cc: Khem Raj
In-Reply-To: <20170419191327.5343-1-raj.khem@gmail.com>
ping
On Wed, Apr 19, 2017 at 12:13 PM, Khem Raj <raj.khem@gmail.com> wrote:
> gcc7 warns about code with fallthroughs, this patch adds
> the comment to indicate a valid fallthrough, helps gcc7
> compiler warnings
>
> This works in cross and native compilation case
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> Grow.c | 4 ++++
> bitmap.c | 8 ++++++++
> mdadm.c | 2 ++
> super-intel.c | 1 +
> util.c | 1 +
> 5 files changed, 16 insertions(+)
>
> diff --git a/Grow.c b/Grow.c
> index 455c5f9..27c73b1 100755
> --- a/Grow.c
> +++ b/Grow.c
> @@ -1257,6 +1257,7 @@ char *analyse_change(char *devname, struct mdinfo *info, struct reshape *re)
> switch (info->new_level) {
> case 4:
> delta_parity = 1;
> + /* fallthrough */
> case 0:
> re->level = 4;
> re->before.layout = 0;
> @@ -1284,10 +1285,12 @@ char *analyse_change(char *devname, struct mdinfo *info, struct reshape *re)
>
> case 4:
> info->array.layout = ALGORITHM_PARITY_N;
> + /* fallthrough */
> case 5:
> switch (info->new_level) {
> case 0:
> delta_parity = -1;
> + /* fallthrough */
> case 4:
> re->level = info->array.level;
> re->before.data_disks = info->array.raid_disks - 1;
> @@ -1343,6 +1346,7 @@ char *analyse_change(char *devname, struct mdinfo *info, struct reshape *re)
> case 4:
> case 5:
> delta_parity = -1;
> + /* fallthrough */
> case 6:
> re->level = 6;
> re->before.data_disks = info->array.raid_disks - 2;
> diff --git a/bitmap.c b/bitmap.c
> index ccedfd3..a6ff091 100644
> --- a/bitmap.c
> +++ b/bitmap.c
> @@ -82,13 +82,21 @@ static inline int count_dirty_bits_byte(char byte, int num_bits)
>
> switch (num_bits) { /* fall through... */
> case 8: if (byte & 128) num++;
> + /* fallthrough */
> case 7: if (byte & 64) num++;
> + /* fallthrough */
> case 6: if (byte & 32) num++;
> + /* fallthrough */
> case 5: if (byte & 16) num++;
> + /* fallthrough */
> case 4: if (byte & 8) num++;
> + /* fallthrough */
> case 3: if (byte & 4) num++;
> + /* fallthrough */
> case 2: if (byte & 2) num++;
> + /* fallthrough */
> case 1: if (byte & 1) num++;
> + /* fallthrough */
> default: break;
> }
>
> diff --git a/mdadm.c b/mdadm.c
> index c3a265b..2d06d3b 100644
> --- a/mdadm.c
> +++ b/mdadm.c
> @@ -148,6 +148,7 @@ int main(int argc, char *argv[])
> mode == CREATE || mode == GROW ||
> mode == INCREMENTAL || mode == MANAGE)
> break; /* b means bitmap */
> + /* fallthrough */
> case Brief:
> c.brief = 1;
> continue;
> @@ -828,6 +829,7 @@ int main(int argc, char *argv[])
>
> case O(INCREMENTAL,NoDegraded):
> pr_err("--no-degraded is deprecated in Incremental mode\n");
> + /* fallthrough */
> case O(ASSEMBLE,NoDegraded): /* --no-degraded */
> c.runstop = -1; /* --stop isn't allowed for --assemble,
> * so we overload slightly */
> diff --git a/super-intel.c b/super-intel.c
> index 4e466ff..00a2925 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -3271,6 +3271,7 @@ static void getinfo_super_imsm_volume(struct supertype *st, struct mdinfo *info,
> << SECT_PER_MB_SHIFT;
> }
> }
> + /* fallthrough */
> case MIGR_VERIFY:
> /* we could emulate the checkpointing of
> * 'sync_action=check' migrations, but for now
> diff --git a/util.c b/util.c
> index 32bd909..f2a4d19 100644
> --- a/util.c
> +++ b/util.c
> @@ -335,6 +335,7 @@ unsigned long long parse_size(char *size)
> switch (*c) {
> case 'K':
> c++;
> + /* fallthrough */
> default:
> s *= 2;
> break;
> --
> 2.12.2
>
^ permalink raw reply
* Re: How important is SCTERC?
From: Ram Ramesh @ 2017-04-28 13:18 UTC (permalink / raw)
To: Phil Turmel, Linux Raid
In-Reply-To: <82b6880d-539b-81a9-08ef-1a5bc3d9752e@turmel.org>
On 04/28/2017 07:18 AM, Phil Turmel wrote:
> On 04/27/2017 11:35 PM, Ram Ramesh wrote:
>> Experts,
>>
>> I ordered a couple of 6TB drives from goHarddrive that claimed to be NAS
>> suitable, but SMART shows that they do not support
>> scterc. I want to replace two of my 3TB drives with these in mdadm
>> raid6. I can get a replacement or return, but want to avoid the hassle,
>> if I am not seious danger.
> Depends on "serious". I would return for exchange with proper NAS
> drives. And report the vendor for false advertising.
>
>> I do run tler.sh that sets 180s timeout for drives that do not have
>> scterc from /etc/rc.local. Am I putting my data in serious danger? I
>> only have videos and tv recordings in this md which can be replaced with
>> significant effort (about 12TB of movies and tv shows will take some
>> time to copy from my DVDs/BDs)
> The 180-second timeout is a band-aid, not a solution. Keep in mind that
> your array will appear to be frozen for up to three minutes any time you
> have a URE. That will have application side-effects and especially
> consequences from impatient users.
>
> Phil
I am quite unhappy with the vendor and wanted to make sure that I am not
overreacting. Thanks. I have started the return process. Hopefully, that
is all there is to it.
Ramesh
^ permalink raw reply
* Re: How important is SCTERC?
From: Peter Grandi @ 2017-04-28 13:07 UTC (permalink / raw)
To: Linux RAID
In-Reply-To: <48135126-cd8e-6321-77e6-06ae349ecc03@gmail.com>
> [ ... ] I do run tler.sh that sets 180s timeout for drives
> that do not have scterc from /etc/rc.local. Am I putting my
> data in serious danger?
No.
> I only have videos and tv recordings in this md
The problem with SCT/ERC absence is that the 2-3 minutes of
retries suspend IO for that long, and for people running
interactive applications (usually LAMP-style web applications)
that is a bad idea, but in your case you seem to have just a
personal archive of entertainment files.
For interactive "enterprise" applications the common practice is
to reduce the error timeout to 1-2 seconds, so the failing drive
drops out of the MD set quickly and can be replaced, minimizing
delays.
> which can be replaced with significant effort (about 12TB of
> movies and tv shows will take some time to copy from my
> DVDs/BDs)
Backups are very important, and RAID is not an alternative to
backups. You can buy and use SMR disk drives as if they were
tapes (or with a filesystem like NILFS2) to do that backup, and
they are quite cheap.
^ permalink raw reply
* Re: How important is SCTERC?
From: Phil Turmel @ 2017-04-28 12:18 UTC (permalink / raw)
To: Ram Ramesh, Linux Raid
In-Reply-To: <48135126-cd8e-6321-77e6-06ae349ecc03@gmail.com>
On 04/27/2017 11:35 PM, Ram Ramesh wrote:
> Experts,
>
> I ordered a couple of 6TB drives from goHarddrive that claimed to be NAS
> suitable, but SMART shows that they do not support
> scterc. I want to replace two of my 3TB drives with these in mdadm
> raid6. I can get a replacement or return, but want to avoid the hassle,
> if I am not seious danger.
Depends on "serious". I would return for exchange with proper NAS
drives. And report the vendor for false advertising.
> I do run tler.sh that sets 180s timeout for drives that do not have
> scterc from /etc/rc.local. Am I putting my data in serious danger? I
> only have videos and tv recordings in this md which can be replaced with
> significant effort (about 12TB of movies and tv shows will take some
> time to copy from my DVDs/BDs)
The 180-second timeout is a band-aid, not a solution. Keep in mind that
your array will appear to be frozen for up to three minutes any time you
have a URE. That will have application side-effects and especially
consequences from impatient users.
Phil
^ permalink raw reply
* Re: Recover array after I panicked
From: Andreas Klauer @ 2017-04-28 11:39 UTC (permalink / raw)
To: Patrik Dahlström; +Cc: Brad Campbell, linux-raid
In-Reply-To: <CAHKno4DWXfOw-ejU5zfh_A8WiG7haSafNTbJLM4Ue1oTCFksyw@mail.gmail.com>
On Fri, Apr 28, 2017 at 12:31:43PM +0200, Patrik Dahlström wrote:
> Can't I reduce my risks by doing it the other way around?
Not like this.
> dd if=/dev/md6 bs=1M count=X/1M of=/dev/md5
Writes into data you haven't read yet, so you end up reading data
you just wrote and write that again... the result will be garbage.
ddrescue has a reverse mode but implementation details matter a lot.
It might be tempting because your progress is just 10-20%ish but
going forwards is a lot safer here.
If you must go backwards you should use mdadm's revert-reshape
for which you need RAID metadata that properly represents the
current mid-grow state of your RAID (the elegant approach).
You can produce such metadata by
truncate -s <drivesize> a b c d e f
losetup --find -show
mdadm --create 5disk
mdadm --grow 6disk
<fallocate punchhole in the background>
<adapt sync_speed_min/max in the background>
<watch progress until X>
mdadm --stop
mdadm --examine <verify correct offsets and reshape pos'n>
Tadaa.
Regards
Andreas Klauer
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox