From: Paul Clements <Paul.Clements@SteelEye.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: linux-raid@vger.kernel.org, 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: Tue, 10 Feb 2004 11:20:40 -0500 [thread overview]
Message-ID: <402904D8.98747590@SteelEye.com> (raw)
In-Reply-To: 16424.8182.876520.280031@notabene.cse.unsw.edu.au
Neil Brown wrote:
> >
> > > - ioctl - By changing the size of mdu_array_info_t you have changed
> > > the GET_ARRAY_INFO ioctl, so you lose backwards compatibility with
> > > user-space tools.
> >
> > Yes, unfortunately...
> >
> > > If you want to return more info with
> > > GET_ARRAY_INFO (which is reasonable) we need to handle both the old
> > > and new mdu_array_info_t sizes. Ditto for SET_ARRAY_INFO
> >
> > OK, I'll code this up and include it in the next patch. Some type of
> > versioning scheme (like what you've done with the superblock) would
> > probably do the trick.
>
> When you change the structure size, you change the ioctl number so you
> can differentiate requests based just on the ioctl.
> so you would need to define a "struct mda_array_info_s_old" and have
> #define GET_ARRAY_INFO _IOR (MD_MAJOR, 0x11, mdu_array_info_t)
> #define GET_ARRAY_INFO_OLD _IOR (MD_MAJOR, 0x11, struct mdu_array_info_s_old)
>
> and handle each ioctl separately (or translate one into the other
> early in md_ioctl).
I was thinking of leaving the original ioctls alone and just adding two
new ioctls that would handle only the new parameters, something like:
#define GET_EXTRA_ARRAY_INFO _IOR (MD_MAJOR, 0x15,
mdu_extra_array_info_t)
#define SET_EXTRA_ARRAY_INFO _IOW (MD_MAJOR, 0x2b,
mdu_extra_array_info_t)
/* The extra array info structure is flexible, to allow for future
changes */
#define EXTRA_ARRAY_INFO_VERSION 1
typedef struct mdu_extra_array_info_s {
__u32 extra_info_version; /* EXTRA_ARRAY_INFO_VERSION */
__u32 async_max_writes; /* Max outstanding async writes (0 =
sync) */
__u32 bitmap_fd; /* The bitmap file descriptor (in
only) */
__u32 bitmap_chunksize; /* The bitmap
chunksize */
__u32 bitmap_daemon_sleep; /* The bitmap daemon sleep
period */
char bitmap_path[256]; /* The bitmap filename (out
only) */
char pad[4096-256-20]; /* Allow for future additions, empty
now */
} mdu_extra_array_info_t;
So for older kernels, the ioctls would just error out and mdadm would
ignore that, and the array would be run using only the old features.
This will also allow me to get rid of the SET_BITMAP_FILE ioctl and just
use the SET_EXTRA_ARRAY_INFO ioctl for Assembling.
Sound OK?
--
Paul
next prev parent reply other threads:[~2004-02-10 16:20 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 [this message]
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
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=402904D8.98747590@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).