From: NeilBrown <neilb@suse.de>
To: "Mathias Burén" <mathias.buren@gmail.com>
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: External bitmap, questions
Date: Sat, 19 Feb 2011 16:30:18 +1100 [thread overview]
Message-ID: <20110219163018.26058ce3@notabene.brown> (raw)
In-Reply-To: <AANLkTimpQ2=EM97ELX3z4c=Yf6gDp=Ekdn6m+ws6O8rm@mail.gmail.com>
On Sat, 19 Feb 2011 04:55:32 +0000 Mathias Burén <mathias.buren@gmail.com>
wrote:
> On 19 February 2011 04:49, NeilBrown <neilb@suse.de> wrote:
> > On Sat, 19 Feb 2011 00:47:10 +0000 Mathias Burén <mathias.buren@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> >From the mdadm manual:
> >>
> >> "-b, --bitmap=
> >> [...]
> >> Note: external bitmaps are only known to work on ext2 and ext3.
> >> Storing bitmap files on other filesystems may result in serious
> >> problems."
> >>
> >> I was planning to store the external bitmap on an ext4 partition. Will
> >> this be a problem, or is the warning there because it hasn't been
> >> tested enough but no problems found?
> >
> > External bitmaps use 'BMAP' to find where the file lives on the device and
> > then writes directly to the device - not through the filesystem.
> >
> > So as long as there is no tail-packing to block migration happening it should
> > work fine.
> >
> > I haven't looked inside ext4 but I am fairly confident that external bitmaps
> > will work properly.
> >
> > NeilBrown
> >
> >
>
> Thanks, Neil. Are there any differences between using an internal or
> external bitmap? Also, does one need a bitmap at all when not planning
> to "mess" with the array? (does it provide any other purpose?)
The difference between internal and external is simply that one is stored in
the array - a copy on each device - and the other is stored externally to the
array - a single copy in a file.
External are slightly harder to work with as you need somewhere separate to
store the bitmap (it cannot be in the array) and you need to tell mdadm where
to find it (so it needs to be listed in mdadm.conf).
I don't know what you mean by "mess" with the array. The main purpose of the
bitmap is the accelerate resync after an unclean shutdown. The secondary
purpose is to accelerate recovery if you remove and then re-add a device.
Maybe that is what you mean by "mess with".
So if you don't want to "mess" with the array and you are certain that your
machine will never crash, then you don't really need a bitmap.
NeilBrown
--
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
next prev parent reply other threads:[~2011-02-19 5:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-19 0:47 External bitmap, questions Mathias Burén
2011-02-19 4:49 ` NeilBrown
2011-02-19 4:55 ` Mathias Burén
2011-02-19 5:30 ` NeilBrown [this message]
2011-02-19 5:42 ` Mathias Burén
2011-02-19 12:14 ` Roman Mamedov
2011-02-19 12:20 ` Mathias Burén
2011-02-19 12:32 ` Roman Mamedov
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=20110219163018.26058ce3@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=mathias.buren@gmail.com \
/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).