linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: linux-raid@vger.kernel.org
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
	ptb@it.uc3m.es, mingo@redhat.com,
	"james.bottomley" <james.bottomley@steeleye.com>
Subject: Re: [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes
Date: Wed, 28 Apr 2004 14:10:35 -0400	[thread overview]
Message-ID: <408FF39B.6070907@steeleye.com> (raw)
In-Reply-To: <406B1024.7BF88C@SteelEye.com>

Since there hasn't been any negative feedback, I assume that this 
version is acceptable for inclusion in mainline/-mm?

Thanks,
Paul


Paul Clements wrote:

> OK, so here it is. The changes from the previous patch are, basically:
> 
> 1) The patch is a little less intrusive now. The diffs against md/raid1
> are smaller as more of the bitmap handling code is now isolated in the
> bitmap.c and bitmap.h files. Also, the diff against mdadm, while now a
> little larger, is less intrusive as I've created a bitmap.c file in the
> mdadm sources, as well.
> 
> 2) The bitmap file I/O routines have been totally rewritten and are now
> much simpler. We now use read_cache_page, prepare_write/commit_write (to
> extend the file at init time, if necessary), and bmap/submit_bh (to
> "sync" the file pages). The use of bmap and submit_bh is due to a
> limitation in jbd that allows only one ongoing transaction per process
> (see comment in bitmap.c regarding current->journal_info).
> 
> 3) The bitmap file now has a superblock containing various configuration
> information. The bitmap superblock is checked against the md superblock
> when the array is assembled. 
> 
> Options have been added to mdadm to create and examine bitmap files, and
> also to specify the bitmap file to be used with an array:
> 
> Create a bitmap file:
> --------------------
> 
> # mdadm --create-bitmap=65536,3,580480 /tmp/bitmap --force
> 
> (this creates a bitmap file with a chunksize of 64KB, a 3 second bitmap
> daemon sleep period, and a bitmap (initially dirtied) which is
> appropriate for use with an array of 580480 blocks)
> 
> Examine a bitmap file:
> ---------------------
> 
> # mdadm --examine-bitmap /tmp/bitmap (or just: mdadm -X /tmp/bitmap)
>         Filename : /tmp/bitmap
>            Magic : 6d746962
>          Version : 2
>             UUID : 997cb579.99d31d20.3014cae8.4bb4bf9d
>           Events : 5
>            State : OK
>        Chunksize : 4 KB
>           Daemon : 5s flush period
>       Array Size : 580480 (566.88 MiB 594.41 MB)
>           Bitmap : 145120 bits (chunks), 145120 dirty (100.0%)
> 
> (in addition, mdadm -D <array> gives the bitmap information if a bitmap
> is attached to the array)
> 
> 
> Create or Assemble array using a bitmap:
> ---------------------------------------
> 
> # mdadm -C /dev/md2 -n 2 -l 1 --bitmap=/tmp/bitmap /dev/sda5 missing
> 
> # mdadm -A /dev/md2 --bitmap=/tmp/bitmap /dev/sda5 /dev/sdb5
> 
> 
> 
> Patch Location:
> --------------
> 
> Patch vs. linux 2.6.5-rc2
> =========================
> http://parisc-linux.org/~jejb/md_bitmap/md_bitmap_2_31_2_6_5_RC2.diff
> 
> Patch vs. mdadm 1.5.0
> =====================
> http://parisc-linux.org/~jejb/md_bitmap/mdadm_1_5_0-bitmap.diff
> 
> (no async write patch has been generated, these patches contain only the
> bitmap code)
> 
> 
> Notes:
> -----
> 
> 1) an is_create flag was added to do_md_run to tell bitmap_create
> whether we are creating or just assembling the array -- this is
> necessary since 0.90 superblocks do not have a UUID until one is
> generated randomly at array creation time, therefore, we must set the
> bitmap UUID equal to this newly generated array UUID when the array is
> created
> 
> 2) bitmap.h was not included in the mdadm patch, but a link (or copy)
> must be made to the kernel's include/linux/raid/bitmap.h file in order
> to build mdadm now
> 
> 3) code was added to mdadm to allow creation of arrays with
> non-persistent superblocks (also, device size calculation with
> non-persistent superblocks was fixed)
> 
> 4) a fix was made to the hot_remove code to allow a faulty device to be
> removed
> 
> 5) various typo and minor bug fixes were also included in the patches
> -
> 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
> 


  reply	other threads:[~2004-04-28 18:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29 22:51 [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes Paul Clements
2004-01-30 22:52 ` Paul Clements
2004-02-09  2:51 ` Neil Brown
2004-02-09 19:45   ` Paul Clements
2004-02-10  0:04     ` Neil Brown
2004-02-10 16:20       ` Paul Clements
2004-02-10 16:57       ` Paul Clements
2004-02-13 20:58       ` Paul Clements
2004-03-05  5:06         ` Neil Brown
2004-03-05 22:05           ` Paul Clements
2004-03-31 18:38             ` Paul Clements
2004-04-28 18:10               ` Paul Clements [this message]
2004-04-28 18:53                 ` Peter T. Breuer
2004-04-29  8:41               ` Neil Brown
2004-05-04 20:08                 ` Paul Clements
2004-06-08 20:53                 ` Paul Clements
2004-06-08 22:47                   ` Neil Brown
2004-06-14 23:39                   ` Neil Brown
2004-06-14 23:59                     ` James Bottomley
2004-06-15  6:27                   ` Neil Brown
2004-06-17 17:57                     ` Paul Clements
2004-06-18 20:48                     ` Paul Clements
2004-06-23 21:48                     ` Paul Clements
2004-06-23 21:50                       ` Paul Clements
2004-07-06 14:52                       ` Paul Clements
     [not found]                       ` <40F7E50F.2040308@steeleye.com>
     [not found]                         ` <16649.61212.310271.36561@cse.unsw.edu.au>
2004-08-10 21:37                           ` Paul Clements
2004-08-13  3:04                             ` Neil Brown
2004-09-21  3:28                               ` Paul Clements
2004-09-21 19:19                                 ` Paul Clements
2004-10-12  2:15                                   ` Neil Brown
2004-10-12 14:06                                     ` Paul Clements
2004-10-12 21:16                                       ` Paul Clements
2004-11-10  0:37                                     ` md: persistent (file-backed) bitmap Neil Brown
2004-11-10 18:28                                       ` Paul Clements

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=408FF39B.6070907@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=james.bottomley@steeleye.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=neilb@cse.unsw.edu.au \
    --cc=ptb@it.uc3m.es \
    /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).