* Re: Disk Monitoring
From: Johannes Truschnigg @ 2017-06-28 10:45 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: linux-raid
In-Reply-To: <CAJH6TXgvrVckHDmh1oiN9mupLrsS2NP3J44bG1_wE9Nnx4=yHQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
Hi Gandalf,
On Wed, Jun 28, 2017 at 12:25:55PM +0200, Gandalf Corvotempesta wrote:
> Hi to all
> I always used hardwre raid but with my next server I would like to use mdadm.
>
> Some questions:
>
> 1) all raid controllers have proactive monitoring features, like
> patrol read, consistency check and (more or less) some SMART
> integration.
> Any counterpart in mdadm?
mdmon(8) is what you seek. Also, monitoring the kernel debug ringbuffer I can
highly recommend.
> 2) thanks to this features, raid controller are usually able to detect
> disk issues before they cause data-loss. what about mdadm ?
>
> How and when do you replace disks ? Based on which params? Do you
> always wait for a total failure before replacing the disk?
>
> Is mdadm able to notify some possible bad-things before they happens ?
md doesn't do low-level management of block devices/disks; that's the job of
other parts of the kernel. The block layer will report errors that you may
want to act upon before md itself complains and/or the disk gets kicked from
its array (which renders your array degraded, but otherwise operational), but
that's usually not necessary.
There's generally no need to replace a disk without any indication of serious
problems (like it getting booted from the array due to I/O timeouts, for
instance).
> Many times in the past our raid controllers forced a bad sector
> reallocation during proactive tasks like patrol read. This saved me
> many times before. I've tried to not replace a disks when this
> reallocation was made (it was a test server) and after some weeks the
> disk failed totally.
You can initiate the resilvering of array data via sysfs; check md(4) for
details.
--
with best regards:
- Johannes Truschnigg ( johannes@truschnigg.info )
www: https://johannes.truschnigg.info/
phone: +43 650 2 133337
xmpp: johannes@truschnigg.info
Please do not bother me with HTML-email or attachments. Thank you.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 1/2] bcache: silence static checker warning
From: Dan Carpenter @ 2017-06-28 11:47 UTC (permalink / raw)
To: Kent Overstreet, Jens Axboe
Cc: Shaohua Li, Eric Wheeler, Ming Lei, NeilBrown, Coly Li,
Yijing Wang, Jan Kara, Michal Hocko, linux-bcache, linux-raid,
kernel-janitors
In olden times, closure_return() used to have a hidden return built in.
We removed the hidden return but forgot to add a new return here. If
"c" were NULL we would oops on the next line, but fortunately "c" is
never NULL. Let's just remove the if statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 8352fad765f6..78004c54f4f6 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1374,9 +1374,6 @@ static void cache_set_flush(struct closure *cl)
struct btree *b;
unsigned i;
- if (!c)
- closure_return(cl);
-
bch_cache_accounting_destroy(&c->accounting);
kobject_put(&c->internal);
^ permalink raw reply related
* [PATCH 2/2] bcache: Update continue_at() documentation
From: Dan Carpenter @ 2017-06-28 11:48 UTC (permalink / raw)
To: Kent Overstreet
Cc: Shaohua Li, Jens Axboe, Ingo Molnar, Coly Li, Yijing Wang,
linux-bcache, linux-raid, linux-kernel, kernel-janitors
In-Reply-To: <20170628114707.5oy4wmslmrethlzn@mwanda>
continue_at() doesn't have a return statement anymore.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
index 1ec84ca81146..295b7e43f92c 100644
--- a/drivers/md/bcache/closure.h
+++ b/drivers/md/bcache/closure.h
@@ -312,8 +312,6 @@ static inline void closure_wake_up(struct closure_waitlist *list)
* been dropped with closure_put()), it will resume execution at @fn running out
* of @wq (or, if @wq is NULL, @fn will be called by closure_put() directly).
*
- * NOTE: This macro expands to a return in the calling function!
- *
* This is because after calling continue_at() you no longer have a ref on @cl,
* and whatever @cl owns may be freed out from under you - a running closure fn
* has a ref on its own closure which continue_at() drops.
@@ -340,8 +338,6 @@ do { \
* Causes @fn to be executed out of @cl, in @wq context (or called directly if
* @wq is NULL).
*
- * NOTE: like continue_at(), this macro expands to a return in the caller!
- *
* The ref the caller of continue_at_nobarrier() had on @cl is now owned by @fn,
* thus it's not safe to touch anything protected by @cl after a
* continue_at_nobarrier().
^ permalink raw reply related
* Re: Disk Monitoring
From: Wols Lists @ 2017-06-28 12:43 UTC (permalink / raw)
To: Gandalf Corvotempesta, linux-raid
In-Reply-To: <CAJH6TXgvrVckHDmh1oiN9mupLrsS2NP3J44bG1_wE9Nnx4=yHQ@mail.gmail.com>
On 28/06/17 11:25, Gandalf Corvotempesta wrote:
> Hi to all
> I always used hardwre raid but with my next server I would like to use mdadm.
>
> Some questions:
>
> 1) all raid controllers have proactive monitoring features, like
> patrol read, consistency check and (more or less) some SMART
> integration.
> Any counterpart in mdadm?
>
> 2) thanks to this features, raid controller are usually able to detect
> disk issues before they cause data-loss. what about mdadm ?
>
> How and when do you replace disks ? Based on which params? Do you
> always wait for a total failure before replacing the disk?
Not wise. mdadm has the --replace option which will copy a failing
drive. This ensures redundancy is not lost during a disk replacement
(unless other stuff goes wrong too).
You need to use stuff like SMART to monitor disk health, read up on
smartctl. Okay, disks often fail unexpectedly even when SMART says
they're healthy, but if things like the relocate count start climbing
it's an indication of trouble ...
Some people are very aggressive and replace disks at the first hint of
trouble. Other people only replace disks when things start going badly
wrong. Your call. The whole point of raid is to enable recovery when
things have otherwise gone irretrievably wrong, but it's best not to
push your luck that far as many people have found out ...
>
> Is mdadm able to notify some possible bad-things before they happens ?
You probably need to turn on kernel logging. And monitor the logs!
Also keep an eye on /proc/mdstat.
I don't know what state xosview is in at the moment but that's my
favourite monitoring tool. Run it on the server with the array, use X to
display it on your local desktop. Last I checked, the raid monitoring
stuff was broken, but the author knows and was fixing it.
>
> Many times in the past our raid controllers forced a bad sector
> reallocation during proactive tasks like patrol read. This saved me
> many times before. I've tried to not replace a disks when this
> reallocation was made (it was a test server) and after some weeks the
> disk failed totally.
Read up on how disks fail. If you tell mdadm to do a "scrub" it will
read the array from end to end. This should cause any dodgy sectors to
be rewritten. Note that this doesn't mean anything is wrong - just as
RAM decays and needs to be refreshed every few nanoseconds, so disk
decays and needs to be refreshed every few years. It's only when the
magnetic coating begins to physically decay that you need to worry about
the health of the disk on that score.
Cheers,
Wol
^ permalink raw reply
* Re: Disk Monitoring
From: Wolfgang Denk @ 2017-06-28 13:19 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: linux-raid
[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]
Dear Gandalf,
In message <CAJH6TXgvrVckHDmh1oiN9mupLrsS2NP3J44bG1_wE9Nnx4=yHQ@mail.gmail.com> you wrote:
>
> 1) all raid controllers have proactive monitoring features, like
> patrol read, consistency check and (more or less) some SMART
> integration.
> Any counterpart in mdadm?
As Wol already pointed out, you should use smaartctl to monitor
the state of the disk drives, ideally on a regular base. Changes
(increases) of numbers like "Reallocated Sectors", ""Current Pending
Sectors" or ""Offline Uncorrectable Sectors" are always suspicious.
If they increase just by one, and then stay constant for weeks you
can probably ignore it. But if you see I/O errors in the system
logs and/or "Reallocated Sectors" increasing every few days then you
should not wait much longer and replace the respective drive.
Attached are two very simple scripts I use for this purpose;
"disk-test" simply runs smartctl on all /dev/sd? devices and parses
the output. The result is something like this:
$ sudo disk-test
=== /dev/sda : ST1000NM0011 S/N Z1N2RA6E *** ERRORS ***
Reallocated Sectors: 1
=== /dev/sdb : ST2000NM0033-9ZM175 S/N Z1X1J1K9 OK
=== /dev/sdc : ST2000NM0033-9ZM175 S/N Z1X1JEF6 OK
=== /dev/sdd : ST2000NM0033-9ZM175 S/N Z1X4XSN9 OK
=== /dev/sde : ST2000NM0033-9ZM175 S/N Z1X4X6G8 OK
=== /dev/sdf : ST2000NM0033-9ZM175 S/N Z1X54EA1 OK
=== /dev/sdg : ST2000NM0033-9ZM175 S/N Z1X5443W OK
=== /dev/sdh : ST2000NM0033-9ZM175 S/N Z1X4XAHQ OK
=== /dev/sdi : ST2000NM0033-9ZM175 S/N Z1X4X6NB OK
=== /dev/sdj : TOSHIBA MK1002TSKB S/N 32E3K0K2F OK
=== /dev/sdk : TOSHIBA MK1002TSKB S/N 32F3K0PRF OK
=== /dev/sdl : TOSHIBA MK1002TSKB S/N 32H3K10CF *** ERRORS ***
Reallocated Sectors: 1
=== /dev/sdm : TOSHIBA MK1002TSKB S/N 32H3K0ZLF OK
=== /dev/sdn : TOSHIBA MK1002TSKB S/N 32H3K104F OK
=== /dev/sdo : TOSHIBA MK1002TSKB S/N 32H1K31DF OK
=== /dev/sdp : TOSHIBA MK1002TSKB S/N 32F3K0PUF OK
=== /dev/sdq : TOSHIBA MK1002TSKB S/N 32E3K0JZF OK
Here I have two drives with 1 reallocated sector each, which I
consider harmeless as it has stayed constant for several months.
The second script "disk-watch" is intended to be run as a cron job
on a regular base (here usually twice per day). It will send out
email whenever the state changes (don't forget to adjust the MAIL_TO
setting). You may also want to clean up the entries in /var/log/diskwatch
every now and then (or better add it to your logrotate
configuration).
HTH.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Yes, it's a technical challenge, and you have to kind of admire
people who go to the lengths of actually implementing it, but at the
same time you wonder about their IQ...
-- Linus Torvalds in <5phda5$ml6$1@palladium.transmeta.com>
[-- Attachment #2: disk-test --]
[-- Type: text/plain , Size: 1083 bytes --]
#!/bin/sh
DISKS="$(echo /dev/sd?)"
PATH=$PATH:/sbin:/usr/sbin
for i in ${DISKS}
do
SMARTDATA=$(smartctl -a $i | \
egrep 'Device Model:|Serial Number:|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|failed|Unknown USB' | \
grep -v ' - *0$')
LINES=$(echo "${SMARTDATA}" | wc -l)
HEAD=$(echo "${SMARTDATA}" | \
sed -n -e 's/Device Model: //p' \
-e 's!Serial Number:!S/N!p')
BODY=$(echo "${SMARTDATA}" | \
awk '$2 ~ /Reallocated_Sector_Ct/ { printf "Reallocated Sectors: %3d\n", $10 }
$2 ~ /Current_Pending_Sector/ { printf "Current Pending Sect: %3d\n", $10 }
$2 ~ /Offline_Uncorrectable/ { printf "Offline Uncorrectable: %3d\n", $10 }
$0 ~ /failed:.*AMCC/ { printf "Unsupported AMCC/3ware controller\n" }
$0 ~ /SMART command failed/ { printf "Device does not support SMART\n" }
$0 ~ /Unknown USB bridge/ { printf "Unknown USB bridge\n" }
'
)
if [ $LINES -eq 2 ]
then
echo === $i : ${HEAD} OK
else
echo === $i : ${HEAD} "*** ERRORS ***"
echo "${BODY}" | sed -e 's/^/ /'
fi
done
[-- Attachment #3: disk-watch --]
[-- Type: text/plain , Size: 683 bytes --]
#!/bin/sh
D_TEST=/usr/local/sbin/disk-test
D_LOGDIR=/var/log/diskwatch
MAIL_TO="root"
[ -x ${D_TEST} ] || { echo "ERROR: cannot execute ${D_TEST}" >&2 ; exit 1 ; }
[ -d ${D_LOGDIR} ] || \
mkdir -p ${D_LOGDIR} || \
{ echo "ERROR: cannot create ${D_LOGDIR}" >&2 ; exit 1 ; }
cd ${D_LOGDIR} || { echo "ERROR: cannot cd ${D_LOGDIR}" >&2 ; exit 1 ; }
rm -f previous
[ -L latest ] && mv latest previous
NOW=$(date "+%F-%T")
${D_TEST} >${NOW}
ln -s "${NOW}" latest
DIFF=''
[ -r previous ] && DIFF=$(diff -u previous latest)
[ -z "${DIFF}" ] && exit 0
mailx -s "$(hostname): SMART DISK WARNING" ${MAIL_TO} <<+++
Disk status change:
${DIFF}
Recent results:
$(cat latest)
+++
^ permalink raw reply
* Big Endian RAID discovery problem (metadata 1!)
From: Rolf Eike Beer @ 2017-06-28 16:46 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1.1: Type: text/plain, Size: 3693 bytes --]
=2D-nextPart23791692.RIh9smj9x1
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
I have an issue with a RAID1 array on my Sparc T5120. The superblocks of 3
partitions are attached. The array was created as degraded RAID1 on sda2, then
extended to sdb2 and sdc2, and then sda2 was removed from the array. I'm not
entirely sure about the mdadm version used to extend the array, but it is
likely 3.4 (current Gentoo stable).
From=20what I see the super_offset is written in big endian, which is consistent
with the error message about super_offset being wrong when I run "mdadm -Asv".
My luck is that the system on sda2 is still valid, so after reboot I ended up
in an old copy of my data.
My plan is to change the GUID on sda2 and fix the super_offset on sd[bc]2, then
reboot and hope the array(s) come up correctly.
Any thoughts on this, anything you want to test me, anything to make my life
easier instead of poking with a hexeditor on the raw partitions?
Eike
=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sda.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sda.dump"
/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAAAUDM6AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAD1RMzoAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcv6l
b1V39rRpfuAbH/0XagAAAAAAAAAADK46WQAAAABJ1AgAAAAAAP//////////8ar9MIAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=
=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sdb.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sdb.dump"
/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAD8H2t0AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAPwfa3QAAAAAAAAAAAAAAAgAAAAAAAAAAAIAAAAAAAAATLg0
bUBbJv9cB5JOvTEzrQAACABIAAAAGj8kWQAAAACj0wgAAAAAAP//////////rTXsaoAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7//v8BAAAA/v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=
=2D-nextPart23791692.RIh9smj9x1
Content-Disposition: attachment; filename="sdc.dump"
Content-Transfer-Encoding: base64
Content-Type: application/octet-stream; name="sdc.dump"
/E4rqQEAAAAAAAAAAAAAAIl7+wBEXquogtrHH1RpEEljYXN0b3I6MAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAExVo1gAAAAAAQAAAAAAAAD8H2t0AAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAQAAAAAAPwfa3QAAAAAAAAAAAAAAAgAAAAAAAAAAAMAAAAAAAAAXNSO
ZCX2AWhlEKuNODfLrQAACABIAAAAGj8kWQAAAACj0wgAAAAAAP//////////J/vSCoAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7//v8BAAAA/v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+
//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7/
/v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v/+//7//v8=
=2D-nextPart23791692.RIh9smj9x1--
This is a multi-part message in MIME format.
[-- Attachment #1.2: Type: text/plain, Size: 891 bytes --]
I have an issue with a RAID1 array on my Sparc T5120. The superblocks of 3
partitions are attached. The array was created as degraded RAID1 on sda2, then
extended to sdb2 and sdc2, and then sda2 was removed from the array. I'm not
entirely sure about the mdadm version used to extend the array, but it is
likely 3.4 (current Gentoo stable).
From what I see the super_offset is written in big endian, which is consistent
with the error message about super_offset being wrong when I run "mdadm -Asv".
My luck is that the system on sda2 is still valid, so after reboot I ended up
in an old copy of my data.
My plan is to change the GUID on sda2 and fix the super_offset on sd[bc]2, then
reboot and hope the array(s) come up correctly.
Any thoughts on this, anything you want to test me, anything to make my life
easier instead of poking with a hexeditor on the raw partitions?
Eike
[-- Attachment #1.3: sda.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]
[-- Attachment #1.4: sdb.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]
[-- Attachment #1.5: sdc.dump --]
[-- Type: application/octet-stream, Size: 512 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Big Endian RAID discovery problem (metadata 1!)
From: Rolf Eike Beer @ 2017-06-28 20:14 UTC (permalink / raw)
To: Adam Thompson; +Cc: linux-raid
In-Reply-To: <AE3DE84B-9DF9-40DD-8DE2-1DD3D3CE3650@athompso.net>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
Am Mittwoch, 28. Juni 2017, 13:55:09 schrieb Adam Thompson:
> If you search the archives, I had a very similar problem a few months ago.
> There is already an option to mdadm to update a v1 superblock in the wrong
> byte order. It just wasn't obvious when looking at the mdadm man page.
> Going from memory, search for "byte order" instead of "endian" to find the
> option. -Adam
If you refer to --update=byteorder, the documentation says it is only for
v0.90 metadata. Also it's only the super_offset field so far, other fields like
magic are correct.
Greetings,
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] mdadm/test: Refactor and revamp 'test' script
From: Anthony Youngman @ 2017-06-28 22:20 UTC (permalink / raw)
To: Zhilong Liu, Jes.Sorensen; +Cc: linux-raid
In-Reply-To: <1497445373-27985-2-git-send-email-zlliu@suse.com>
On 14/06/17 14:02, Zhilong Liu wrote:
> Improve functions:
> cleanup()
> clear dmesg and remove the /vat/tmp/mdtest* files.
c/vat/var/ ???
Cheers,
Wol
^ permalink raw reply
* Re: [PATCH v2 11/51] md: raid1: initialize bvec table via bio_add_page()
From: Guoqing Jiang @ 2017-06-29 1:36 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Christoph Hellwig, linux-kernel, linux-block,
Shaohua Li, linux-raid
In-Reply-To: <20170627162242.GA19610@ming.t460p>
On 06/28/2017 12:22 AM, Ming Lei wrote:
>
>> Seems above section is similar as reset_bvec_table introduced in next patch,
>> why there is difference between raid1 and raid10? Maybe add reset_bvec_table
>> into md.c, then call it in raid1 or raid10 is better, just my 2 cents.
> Hi Guoqing,
>
> I think it is a good idea, and even the two patches can be put into
> one, so how about the following patch?
Looks good.
Acked-by: Guoqing Jiang <gqjiang@suse.com>
Thanks,
Guoqing
>
> Shaohua, what do you think of this one?
>
> ---
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 3d957ac1e109..7ffc622dd7fa 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -9126,6 +9126,24 @@ void md_reload_sb(struct mddev *mddev, int nr)
> }
> EXPORT_SYMBOL(md_reload_sb);
>
> +/* generally called after bio_reset() for reseting bvec */
> +void reset_bvec_table(struct bio *bio, struct resync_pages *rp, int size)
> +{
> + /* initialize bvec table again */
> + rp->idx = 0;
> + do {
> + struct page *page = resync_fetch_page(rp, rp->idx++);
> + int len = min_t(int, size, PAGE_SIZE);
> +
> + /*
> + * won't fail because the vec table is big
> + * enough to hold all these pages
> + */
> + bio_add_page(bio, page, len, 0);
> + size -= len;
> + } while (rp->idx < RESYNC_PAGES && size > 0);
> +}
> +
> #ifndef MODULE
>
> /*
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index 991f0fe2dcc6..f569831b1de9 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -783,4 +783,6 @@ static inline struct page *resync_fetch_page(struct resync_pages *rp,
> return NULL;
> return rp->pages[idx];
> }
> +
> +void reset_bvec_table(struct bio *bio, struct resync_pages *rp, int size);
> #endif /* _MD_MD_H */
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 3febfc8391fb..6ae2665ecd58 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -2086,10 +2086,7 @@ static void process_checks(struct r1bio *r1_bio)
> /* Fix variable parts of all bios */
> vcnt = (r1_bio->sectors + PAGE_SIZE / 512 - 1) >> (PAGE_SHIFT - 9);
> for (i = 0; i < conf->raid_disks * 2; i++) {
> - int j;
> - int size;
> blk_status_t status;
> - struct bio_vec *bi;
> struct bio *b = r1_bio->bios[i];
> struct resync_pages *rp = get_resync_pages(b);
> if (b->bi_end_io != end_sync_read)
> @@ -2098,8 +2095,6 @@ static void process_checks(struct r1bio *r1_bio)
> status = b->bi_status;
> bio_reset(b);
> b->bi_status = status;
> - b->bi_vcnt = vcnt;
> - b->bi_iter.bi_size = r1_bio->sectors << 9;
> b->bi_iter.bi_sector = r1_bio->sector +
> conf->mirrors[i].rdev->data_offset;
> b->bi_bdev = conf->mirrors[i].rdev->bdev;
> @@ -2107,15 +2102,8 @@ static void process_checks(struct r1bio *r1_bio)
> rp->raid_bio = r1_bio;
> b->bi_private = rp;
>
> - size = b->bi_iter.bi_size;
> - bio_for_each_segment_all(bi, b, j) {
> - bi->bv_offset = 0;
> - if (size > PAGE_SIZE)
> - bi->bv_len = PAGE_SIZE;
> - else
> - bi->bv_len = size;
> - size -= PAGE_SIZE;
> - }
> + /* initialize bvec table again */
> + reset_bvec_table(b, rp, r1_bio->sectors << 9);
> }
> for (primary = 0; primary < conf->raid_disks * 2; primary++)
> if (r1_bio->bios[primary]->bi_end_io == end_sync_read &&
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 5026e7ad51d3..72f4fa07449b 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -2087,8 +2087,8 @@ static void sync_request_write(struct mddev *mddev, struct r10bio *r10_bio)
> rp = get_resync_pages(tbio);
> bio_reset(tbio);
>
> - tbio->bi_vcnt = vcnt;
> - tbio->bi_iter.bi_size = fbio->bi_iter.bi_size;
> + reset_bvec_table(tbio, rp, fbio->bi_iter.bi_size);
> +
> rp->raid_bio = r10_bio;
> tbio->bi_private = rp;
> tbio->bi_iter.bi_sector = r10_bio->devs[i].addr;
>
> Thanks,
> Ming
>
^ permalink raw reply
* Re: [PATCH v2 1/3] mdadm/test: Refactor and revamp 'test' script
From: Zhilong Liu @ 2017-06-29 2:42 UTC (permalink / raw)
To: Anthony Youngman, Jes.Sorensen; +Cc: linux-raid
In-Reply-To: <79db0bf0-c370-c3ae-737a-3d7886e1e0b9@youngman.org.uk>
On 06/29/2017 06:20 AM, Anthony Youngman wrote:
>
>
> On 14/06/17 14:02, Zhilong Liu wrote:
>> Improve functions:
>> cleanup()
>> clear dmesg and remove the /vat/tmp/mdtest* files.
>
> c/vat/var/ ???
>
Thanks for pointing it out, will do.
Regards,
Zhilong
> Cheers,
> Wol
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Disk Monitoring
From: Gandalf Corvotempesta @ 2017-06-29 9:52 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-raid
In-Reply-To: <20170628131917.BF1911235B6@gemini.denx.de>
2017-06-28 15:19 GMT+02:00 Wolfgang Denk <wd@denx.de>:
> As Wol already pointed out, you should use smaartctl to monitor
> the state of the disk drives, ideally on a regular base. Changes
> (increases) of numbers like "Reallocated Sectors", ""Current Pending
> Sectors" or ""Offline Uncorrectable Sectors" are always suspicious.
> If they increase just by one, and then stay constant for weeks you
> can probably ignore it. But if you see I/O errors in the system
> logs and/or "Reallocated Sectors" increasing every few days then you
> should not wait much longer and replace the respective drive.
Sure, but smart is not always reliable.
My personal experience was that Patrol Read feature on LSI controllers [1]
saved me multiple times. During a patrol read some bad sectors where found
(probably in an unallocated part of the array, thus the OS doesn't
know anything about that).
I've proactive replaced the drive and the day after resync, another
disk failed totally.
Without "Patrol Read" that scrubs all disks, one by one (consistency
check is a different thing),
probably this server would fails totally with data loss
Linux kernels detect something bad only by accessing to the failed
sector. If that sector is not used,
kernel knows nothing. HW RAID like LSI are able to read the whole
disks, block by block, even the unused part,
detecting failures before something is trying to write to that sector.
If you have a bad sector on an unused part of the array, when you have
to rebuild due to another disk failure, you'll
hit a URE and the whole array is failed.
Simple example:
disk0 has sector X (unused) failed.
It's unused, thus, kernel knows nothing about that and is operting
normally, no warning message or anything. If you don't access sector
X, you wont be notified.
Now, disk1 hard-fail. You have to replace that.
During the resync, you have to resync the whole array, but disk0,
sectorX is unreadable.
The resync will fail and the whole array is down.
Am I missing something?
[1] http://www.dell.com/downloads/global/power/ps1q06-20050212-Habas.pdf
^ permalink raw reply
* Re: Disk Monitoring
From: Reindl Harald @ 2017-06-29 10:10 UTC (permalink / raw)
To: Gandalf Corvotempesta, Wolfgang Denk; +Cc: linux-raid
In-Reply-To: <CAJH6TXhJ8HoH=tnxreZ4EAFYQYDh05KHAQxwoLqp1f7zQM4N0g@mail.gmail.com>
Am 29.06.2017 um 11:52 schrieb Gandalf Corvotempesta:
> Linux kernels detect something bad only by accessing to the failed
> sector. If that sector is not used,
> kernel knows nothing. HW RAID like LSI are able to read the whole
> disks, block by block, even the unused part,
> detecting failures before something is trying to write to that sector
>
> If you have a bad sector on an unused part of the array, when you have
> to rebuild due to another disk failure, you'll
> hit a URE and the whole array is failed
there is nothing like "unused part of the array" since the
linux-raid-layer knows nothing about the filesystem on top and hence a
raid-check (scrub) reads every block as said hardware controller
^ permalink raw reply
* Re: Disk Monitoring
From: Andreas Klauer @ 2017-06-29 10:14 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <CAJH6TXhJ8HoH=tnxreZ4EAFYQYDh05KHAQxwoLqp1f7zQM4N0g@mail.gmail.com>
On Thu, Jun 29, 2017 at 11:52:01AM +0200, Gandalf Corvotempesta wrote:
> disk0 has sector X (unused) failed.
> It's unused, thus, kernel knows nothing about that and is operting
> normally, no warning message or anything. If you don't access sector
> X, you wont be notified.
>
> Now, disk1 hard-fail. You have to replace that.
> During the resync, you have to resync the whole array, but disk0,
> sectorX is unreadable.
> The resync will fail and the whole array is down.
> Am I missing something?
Not really. It's just that you have to set up the monitoring yourself,
whichever way you feel comfortable with.
SMART has a selftest feature which causes the disk to read sectors.
You can do whole disk at once (long selftest) or in segments
(selective selftest). I prefer the selective since that allows you
to place the selftest in the time window of least activity.
Instead of spending an entire day (or two) testing the whole drive
you can put in an hour or two of testing every night and have it
cover the entire drive over X days.
mdadm can also perform RAID checks, reading everything including
parity, RAID layer would attempt to fix read errors then, and you
can also check mismatch_cnt.
The mdadm checks can also done region by region to distribute
load over several days but I think it's still not a direct option
for mdadm, the region can be set via /proc or /sys somewhere...
Both smartmontools and mdadm should be set up to run such checks
periodically, and instantly notify you by email if any problem occurs.
If a disk has problems, replace it, otherwise it's a gamble.
Whatever promises RAID makes regarding redundancy, it always
assumes the other drives to work 100%.
It's very unlikely to encounter read errors during rebuild if
you ran regular checks and didn't forcibly keep bad drives.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Disk Monitoring
From: Gandalf Corvotempesta @ 2017-06-29 10:14 UTC (permalink / raw)
To: Reindl Harald; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <38899f11-c6d2-cab7-eb25-093cfa802b40@thelounge.net>
2017-06-29 12:10 GMT+02:00 Reindl Harald <h.reindl@thelounge.net>:
> there is nothing like "unused part of the array" since the linux-raid-layer
> knows nothing about the filesystem on top and hence a raid-check (scrub)
> reads every block as said hardware controller
Yes, this during a scrub.
Without a scrub, kernel know nothing about an unused part of the array.
Let's assume a unreadable sector is found during a scrub. What
happens? mdadm kick-out the disk from the array? It tried to
reallocate the failed sector somewhere keeping the disk up and running
(and thus, resolving the URE that would prevent a successful resync?)
^ permalink raw reply
* Re: Disk Monitoring
From: Mateusz Korniak @ 2017-06-29 10:14 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <CAJH6TXhJ8HoH=tnxreZ4EAFYQYDh05KHAQxwoLqp1f7zQM4N0g@mail.gmail.com>
On Thursday 29 of June 2017 11:52:01 Gandalf Corvotempesta wrote:
> During a patrol read some bad sectors where found
> (probably in an unallocated part of the array, thus the OS doesn't
> know anything about that).
One can read of all disks/partitions used by RAIDs by script
/usr/share/mdadm/checkarray
In many distros it is set to be performed monthly out-of-box.
--
Mateusz Korniak
"(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś,
krótko mówiąc - podpora społeczeństwa."
Nikos Kazantzakis - "Grek Zorba"
^ permalink raw reply
* Re: Disk Monitoring
From: Gandalf Corvotempesta @ 2017-06-29 10:16 UTC (permalink / raw)
To: Mateusz Korniak; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <2113365.0QvyMCaQ9I@matkor-lenovo>
2017-06-29 12:14 GMT+02:00 Mateusz Korniak <mateusz-lists@ant.gliwice.pl>:
> One can read of all disks/partitions used by RAIDs by script
> /usr/share/mdadm/checkarray
>
> In many distros it is set to be performed monthly out-of-box.
I know this and I'm running weekly. (just to be sure)
What Is unclear to me is why an hardware raid controller like LSI, has
two different kind of checks: patrol read and consistency check.
^ permalink raw reply
* Re: Disk Monitoring
From: Mateusz Korniak @ 2017-06-29 10:20 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <CAJH6TXhJ8HoH=tnxreZ4EAFYQYDh05KHAQxwoLqp1f7zQM4N0g@mail.gmail.com>
On Thursday 29 of June 2017 11:52:01 Gandalf Corvotempesta wrote:
> During a patrol read some bad sectors where found
> (probably in an unallocated part of the array, thus the OS doesn't
> know anything about that).
Also SMART long test should perform "read/verify scan of all of the user data
area", so it is good idea to do it periodically and monitor results.
--
Mateusz Korniak
"(...) mam brata - poważny, domator, liczykrupa, hipokryta, pobożniś,
krótko mówiąc - podpora społeczeństwa."
Nikos Kazantzakis - "Grek Zorba"
^ permalink raw reply
* Re: Disk Monitoring
From: Gandalf Corvotempesta @ 2017-06-29 10:25 UTC (permalink / raw)
To: Mateusz Korniak; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <7688279.9aYLlOU3Xu@matkor-lenovo>
2017-06-29 12:20 GMT+02:00 Mateusz Korniak <mateusz-lists@ant.gliwice.pl>:
> Also SMART long test should perform "read/verify scan of all of the user data
> area", so it is good idea to do it periodically and monitor results.
I'm already using this, but is not very reliable.
I had some disks failed by hw raid controller due to unreadable sector
(3/11) still passing the smart long test
and some failed smart long test still passing the hw raid check
^ permalink raw reply
* Re: Disk Monitoring
From: Reindl Harald @ 2017-06-29 10:34 UTC (permalink / raw)
To: Gandalf Corvotempesta, Mateusz Korniak; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <CAJH6TXgp4CdrJ9a3Ku-R8Tj5Am+zeyRO_Bc_hFidWVLZW1f9vQ@mail.gmail.com>
Am 29.06.2017 um 12:25 schrieb Gandalf Corvotempesta:
> 2017-06-29 12:20 GMT+02:00 Mateusz Korniak <mateusz-lists@ant.gliwice.pl>:
>> Also SMART long test should perform "read/verify scan of all of the user data
>> area", so it is good idea to do it periodically and monitor results.
>
> I'm already using this, but is not very reliable.
> I had some disks failed by hw raid controller due to unreadable sector
> (3/11) still passing the smart long test
> and some failed smart long test still passing the hw raid check
hence you do both - in any case, software-raid as well as hardware-raid
* scheduled smart check
* scheduled scrub
i had enough cases where while the scrub was running smartd alerted
about a disk going bad - at the end of the day it don't matter which of
both cries, the point is that you get (hopefully) a alert that you
should replace a specific disk before a second one starts to go bad
^ permalink raw reply
* Re: Disk Monitoring
From: Reindl Harald @ 2017-06-29 10:37 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: Wolfgang Denk, linux-raid
In-Reply-To: <CAJH6TXi8L-x7NiyAqG+22xosqAJ39LB0e_N6b-9PiMrhA2jnjg@mail.gmail.com>
Am 29.06.2017 um 12:14 schrieb Gandalf Corvotempesta:
> 2017-06-29 12:10 GMT+02:00 Reindl Harald <h.reindl@thelounge.net>:
>> there is nothing like "unused part of the array" since the linux-raid-layer
>> knows nothing about the filesystem on top and hence a raid-check (scrub)
>> reads every block as said hardware controller
>
> Yes, this during a scrub.
> Without a scrub, kernel know nothing about an unused part of the array.
>
> Let's assume a unreadable sector is found during a scrub. What
> happens? mdadm kick-out the disk from the array? It tried to
> reallocate the failed sector somewhere keeping the disk up and running
> (and thus, resolving the URE that would prevent a successful resync?)
it tries to re-write the data block (depending if repair is enabled)
normally the disk firmware itself is aware of that event and realloctes
a spare block so the rewrite just suceeds until the disk runs out of
spare sectors
but well, even if it just kicks out the disk soon enough you can replace
it, the array rebuilds and nothing happened - without smart-check/scrub
sooner or later it's detected due rebuild after a disk failed and the
array is gone
^ permalink raw reply
* Re: Disk Monitoring
From: Wols Lists @ 2017-06-29 14:28 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: linux-raid
In-Reply-To: <CAJH6TXi8L-x7NiyAqG+22xosqAJ39LB0e_N6b-9PiMrhA2jnjg@mail.gmail.com>
On 29/06/17 11:14, Gandalf Corvotempesta wrote:
> 2017-06-29 12:10 GMT+02:00 Reindl Harald <h.reindl@thelounge.net>:
>> there is nothing like "unused part of the array" since the linux-raid-layer
>> knows nothing about the filesystem on top and hence a raid-check (scrub)
>> reads every block as said hardware controller
>
> Yes, this during a scrub.
> Without a scrub, kernel know nothing about an unused part of the array.
>
> Let's assume a unreadable sector is found during a scrub. What
> happens? mdadm kick-out the disk from the array? It tried to
> reallocate the failed sector somewhere keeping the disk up and running
> (and thus, resolving the URE that would prevent a successful resync?)
As I said, read up on disk failure modes. If mdadm finds an unreadable
sector, it does a full stripe read, recalculates the unreadable sector,
and writes it back.
If the read failed because the magnetism has decayed, this will reset it
and everything will be hunky-dory again.
If the read failed because the magnetic layer is failing, it will
trigger a relocate (which SMART should pick up) and alarm bells should
start ringing. It might be benign, the magnetic properties of the layer
might be failing such that that bit can no longer record properly, or it
could be that the layer itself is starting to fail, at which point you
are heading for platter failure, a head crash, and serious pain.
Cheers,
Wol
^ permalink raw reply
* Re: Disk Monitoring
From: Wols Lists @ 2017-06-29 14:33 UTC (permalink / raw)
To: Gandalf Corvotempesta; +Cc: linux-raid
In-Reply-To: <CAJH6TXiONYigcX1CtQw86ZXUgeOLvzD_+2couNfxSwL9hHj1gA@mail.gmail.com>
On 29/06/17 11:16, Gandalf Corvotempesta wrote:
> 2017-06-29 12:14 GMT+02:00 Mateusz Korniak <mateusz-lists@ant.gliwice.pl>:
>> One can read of all disks/partitions used by RAIDs by script
>> /usr/share/mdadm/checkarray
>>
>> In many distros it is set to be performed monthly out-of-box.
>
> I know this and I'm running weekly. (just to be sure)
> What Is unclear to me is why an hardware raid controller like LSI, has
> two different kind of checks: patrol read and consistency check.
Because they're two completely different things.
A patrol check reads the entire disk. It doesn't give two hoots what the
data is, it just cares that the data can actually be retrieved from the
disk.
A consistency check, on the other hand, wants to make sure that the data
is correct. It will read both copies of a mirror and compare them. Or it
will read the data from 4/5/6, calculate the parities, then read them
from disk and compare them.
In other words, a patrol check looks for a failing disk. A consistency
check looks for corrupt data. (A consistency check does a patrol check
as a side effect, but you might not want to do just that, as it is
computationally much more expensive. You might want to do a patrol check
every day, and a consistency check of a weekend.)
Cheers,
Wol
^ permalink raw reply
* Re: raid0 vs. mkfs
From: Avi Kivity @ 2017-06-29 15:15 UTC (permalink / raw)
To: Coly Li, Shaohua Li; +Cc: NeilBrown, linux-raid, linux-block
In-Reply-To: <c384d070-457c-cfee-e35f-53b9195ace10@suse.de>
On 12/08/2016 06:44 PM, Coly Li wrote:
> On 2016/12/8 上午12:59, Shaohua Li wrote:
>> On Wed, Dec 07, 2016 at 07:50:33PM +0800, Coly Li wrote:
> [snip]
>> Thanks for doing this, Coly! For raid0, this totally makes sense. The raid0
>> zones make things a little complicated though. I just had a brief look of your
>> proposed patch, which looks really complicated. I'd suggest something like
>> this:
>> 1. split the bio according to zone boundary.
>> 2. handle the splitted bio. since the bio is within zone range, calculating
>> the start and end sector for each rdev should be easy.
>>
> Hi Shaohua,
>
> Thanks for your suggestion! I try to modify the code by your suggestion,
> it is even more hard to make the code that way ...
>
> Because even split bios for each zone, all the corner cases still exist
> and should be taken care in every zoon. The code will be more complicated.
>
Hi Coly,
Did you manage to complete this patch? We are seeing its effect, not
only with mkfs, but also with fstrim(8).
Avi
^ permalink raw reply
* Re: raid0 vs. mkfs
From: Coly Li @ 2017-06-29 15:31 UTC (permalink / raw)
To: Avi Kivity, Shaohua Li; +Cc: NeilBrown, linux-raid, linux-block
In-Reply-To: <eeae1d04-8c92-c511-8977-5124735646c4@scylladb.com>
On 2017/6/29 下午11:15, Avi Kivity wrote:
>
>
> On 12/08/2016 06:44 PM, Coly Li wrote:
>> On 2016/12/8 上午12:59, Shaohua Li wrote:
>>> On Wed, Dec 07, 2016 at 07:50:33PM +0800, Coly Li wrote:
>> [snip]
>>> Thanks for doing this, Coly! For raid0, this totally makes sense. The
>>> raid0
>>> zones make things a little complicated though. I just had a brief
>>> look of your
>>> proposed patch, which looks really complicated. I'd suggest something
>>> like
>>> this:
>>> 1. split the bio according to zone boundary.
>>> 2. handle the splitted bio. since the bio is within zone range,
>>> calculating
>>> the start and end sector for each rdev should be easy.
>>>
>> Hi Shaohua,
>>
>> Thanks for your suggestion! I try to modify the code by your suggestion,
>> it is even more hard to make the code that way ...
>>
>> Because even split bios for each zone, all the corner cases still exist
>> and should be taken care in every zoon. The code will be more
>> complicated.
>>
>
> Hi Coly,
>
> Did you manage to complete this patch? We are seeing its effect, not
> only with mkfs, but also with fstrim(8).
Hi Avi,
Shaohua makes another much better patch, which is merged into mainline
kernel in v4.12-rc2.
The commit is '29efc390b946 ("md/md0: optimize raid0 discard handling")'.
Hope this is informative.
Coly
^ permalink raw reply
* Re: raid0 vs. mkfs
From: Avi Kivity @ 2017-06-29 15:36 UTC (permalink / raw)
To: Coly Li, Shaohua Li; +Cc: NeilBrown, linux-raid, linux-block
In-Reply-To: <9a46c760-904a-8318-b06c-0cf19e0651dc@suse.de>
On 06/29/2017 06:31 PM, Coly Li wrote:
> On 2017/6/29 下午11:15, Avi Kivity wrote:
>>
>> On 12/08/2016 06:44 PM, Coly Li wrote:
>>> On 2016/12/8 上午12:59, Shaohua Li wrote:
>>>> On Wed, Dec 07, 2016 at 07:50:33PM +0800, Coly Li wrote:
>>> [snip]
>>>> Thanks for doing this, Coly! For raid0, this totally makes sense. The
>>>> raid0
>>>> zones make things a little complicated though. I just had a brief
>>>> look of your
>>>> proposed patch, which looks really complicated. I'd suggest something
>>>> like
>>>> this:
>>>> 1. split the bio according to zone boundary.
>>>> 2. handle the splitted bio. since the bio is within zone range,
>>>> calculating
>>>> the start and end sector for each rdev should be easy.
>>>>
>>> Hi Shaohua,
>>>
>>> Thanks for your suggestion! I try to modify the code by your suggestion,
>>> it is even more hard to make the code that way ...
>>>
>>> Because even split bios for each zone, all the corner cases still exist
>>> and should be taken care in every zoon. The code will be more
>>> complicated.
>>>
>> Hi Coly,
>>
>> Did you manage to complete this patch? We are seeing its effect, not
>> only with mkfs, but also with fstrim(8).
> Hi Avi,
>
> Shaohua makes another much better patch, which is merged into mainline
> kernel in v4.12-rc2.
>
> The commit is '29efc390b946 ("md/md0: optimize raid0 discard handling")'.
>
> Hope this is informative.
>
Thanks a lot, that's great news.
^ 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