From: Roman Mamedov <roman@rm.pp.ru>
To: Miles Fidelman <mfidelman@meetinghouse.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID6 and crashes (reporting back re. --bitmap)
Date: Fri, 11 Jun 2010 10:55:21 +0600 [thread overview]
Message-ID: <20100611105521.67c9658c@natsu> (raw)
In-Reply-To: <4C11BFB7.7050907@meetinghouse.net>
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
On Fri, 11 Jun 2010 00:46:47 -0400
Miles Fidelman <mfidelman@meetinghouse.net> wrote:
> Looks like my original --bitmap internal creation set a very large chunk
> size initially
>
> md3 : active raid6 sda4[0] sdd4[3] sdc4[2] sdb4[1]
> 947417088 blocks level 6, 64k chunk, algorithm 2 [4/4] [UUUU]
> bitmap: 6/226 pages [24KB], 1024KB chunk
>
> unless that --bitmap-chunk=131072 recommendation is translates to
> 131072KB (if so, are you really running 131MB chunks?)
Yes, this is correct.
This will only mean that after an unclean shutdown, at least 128MB-sized
areas of the array will be invalidated for a resync, and not smaller areas
with 1MB-granularity like on yours currently. 128 megabytes is just about 1
second of read throughput on modern drives, so I am okay with that. Several
128MB-windows here and there are still faster to resync than the whole array.
And this had an extemely good effect on write performance for me (increased it
by more than 1.5x) compared to a small chunk. Test for yourself, first without
the bitmap, then with various chunk sizes of it (ensure there's no other load
on the array, and note the speeds):
dd if=/dev/zero of=/your-raid/zerofile bs=1M count=2048 conv=notrunc,fdatasync
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-06-11 4:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-10 18:02 RAID6 and crashes Miles Fidelman
2010-06-10 18:57 ` Roman Mamedov
2010-06-10 21:22 ` RAID6 and crashes (reporting back re. --bitmap) Miles Fidelman
2010-06-10 21:41 ` Roman Mamedov
2010-06-10 22:40 ` Miles Fidelman
2010-06-11 2:51 ` Roman Mamedov
2010-06-11 4:31 ` Graham Mitchell
2010-06-11 4:41 ` Roman Mamedov
2010-06-11 12:13 ` Graham Mitchell
2010-06-11 4:42 ` Miles Fidelman
2010-06-11 4:50 ` Neil Brown
2010-06-13 14:28 ` Bernd Schubert
2010-06-13 23:05 ` Neil Brown
2010-06-14 9:01 ` Bernd Schubert
2010-06-14 9:14 ` Roman Mamedov
2010-06-14 9:47 ` Neil Brown
2010-06-14 11:53 ` Roman Mamedov
2010-06-14 21:24 ` Neil Brown
2010-06-11 4:46 ` Miles Fidelman
2010-06-11 4:55 ` Roman Mamedov [this message]
2010-06-11 20:26 ` Miles Fidelman
2010-06-11 5:08 ` Neil Brown
2010-06-11 11:10 ` John Hendrikx
2010-06-11 11:50 ` Roman Mamedov
2010-06-11 12:29 ` Graham Mitchell
2010-06-11 12:25 ` Graham Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100611105521.67c9658c@natsu \
--to=roman@rm.pp.ru \
--cc=linux-raid@vger.kernel.org \
--cc=mfidelman@meetinghouse.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).