From: Goswin von Brederlow <goswin-v-b@web.de>
To: Neil Brown <neilb@suse.de>
Cc: Steven Ellis <steven@openmedia.co.nz>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Any benefity to write intent bitmaps on Raid1
Date: Thu, 09 Apr 2009 08:26:17 +0200 [thread overview]
Message-ID: <87myaqfily.fsf@frosties.localdomain> (raw)
In-Reply-To: <18909.36541.447308.778177@notabene.brown> (Neil Brown's message of "Thu, 9 Apr 2009 15:59:25 +1000")
Neil Brown <neilb@suse.de> writes:
> (*) I've been wondering about adding another bitmap which would record
> which sections of the array have valid data. Initially nothing would
> be valid and so wouldn't need recovery. Every time we write to a new
> section we add that section to the 'valid' sections and make sure that
> section is in-sync.
> When a device was replaced, we would only need to recover the parts of
> the array that are known to be invalid.
> As filesystem start using the new "invalidate" command for block
> devices, we could clear bits for sections that the filesystem says are
> not needed any more...
> But currently it is just a vague idea.
>
> NeilBrown
If you are up for experimenting I would go for a completly new
approach. Instead of working with physical blocks and marking where
blocks are used and out of sync how about adding a mapping layer on
the device and using virtual blocks. You reduce the reported disk size
by maybe 1% to always have some spare blocks and initialy all blocks
will be unmapped (unused). Then whenever there is a write you pick out
an unused block, write to it and change the in memory mapping of the
logical to physical block. Every X seconds, on a barrier or an sync
you commit the mapping from memory to disk in such a way that it is
synchronized between all disks in the raid. So every commited mapping
represents a valid raid set. After the commit of the mapping all
blocks changed between the mapping and the last can be marked as free
again. Better use the second last so there are always 2 valid mappings
to choose from after a crash.
This would obviously need a lot more space than a bitmap but space is
(relatively) cheap. One benefit imho should be that sync/barrier would
not have to stop all activity on the raid to wait for the sync/barrier
to finish. It just has to finalize the mapping for the commit and then
can start a new in memory mapping while the finalized one writes to
disk.
Just some thoughts,
Goswin
next prev parent reply other threads:[~2009-04-09 6:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 0:24 Any benefity to write intent bitmaps on Raid1 Steven Ellis
2009-04-09 1:30 ` Bryan Mesich
2009-04-09 5:59 ` Neil Brown
2009-04-09 6:26 ` Goswin von Brederlow [this message]
2009-04-10 9:04 ` Neil Brown
2009-04-11 2:56 ` Goswin von Brederlow
2009-04-11 5:35 ` Neil Brown
2009-04-11 8:46 ` Goswin von Brederlow
2009-04-11 13:08 ` Bill Davidsen
2009-04-09 22:51 ` Bill Davidsen
2009-04-10 9:10 ` Neil Brown
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=87myaqfily.fsf@frosties.localdomain \
--to=goswin-v-b@web.de \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=steven@openmedia.co.nz \
/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