From: Theodore Tso <tytso@mit.edu>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Rupesh Thakare <rupesh@clusterfs.com>,
linux-ext4@vger.kernel.org, Kalpak Shah <kalpak@clusterfs.com>
Subject: Re: [RFC] store RAID stride in superblock
Date: Thu, 31 May 2007 17:33:01 -0400 [thread overview]
Message-ID: <20070531213301.GC13660@thunk.org> (raw)
In-Reply-To: <20070531201902.GF5181@schatzie.adilger.int>
On Thu, May 31, 2007 at 02:19:02PM -0600, Andreas Dilger wrote:
> Ah, we've been doing it the other way around here. It makes sense to keep
> the s_raid_stripe_width fields together. I think this code is preliminary
> enough that nobody has actually started using it yet. Can you please post
> what the end of ext2_super_block looks like (whether you decide to reorder
> the fields or not).
Oops, I just pushed a set of bugfixes to Linux that included the
superblock field reservations. I was going back and forth about
whether to keep them together, or whether to keep the extra u16 s_pad
and then have to reserve another u16 field plus another u16 field for
MMP seconds field. Since you guys had been talking about the MMP code
for longer period of time (I think you first made the proposal a few
months ago), I had assumed it had precedence (and had possibly already
been in use at some customer somewhere), so I used Kalpak's original
MMP superblock field reservations.
I don't think it's worth changing at this point. (If no one is using
it yet, it won't be too hard to switch around so we're all doing the
same thing. :-) What is in the e2fsprogs hg repository as well as the
for_linus branch of ext4.git is:
..
__u16 s_raid_stride; /* RAID stride */
__u16 s_mmp_interval; /* # seconds to wait in MMP checking */
__u64 s_mmp_block; /* Block for multi-mount protection */
__u32 s_raid_stripe_width; /* blocks on all data disks (N*stride)*/
__u32 s_reserved[163]; /* Padding to the end of the block */
};
One question which does come to mind; is there any reason why we might
want to know the RAID level and/or the number of disks (as opposed to
just the stripe width)? And has anyone investigated where there are
magic ioctl's or libdevmapper APi's so we can get the RAID parameters
automatically? If so, patches so that mke2fs can get the information
automatically (as opposed to forcing the user to have to specify lots
of annoying options) would be most welcome....
- Ted
next prev parent reply other threads:[~2007-05-31 21:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-12 2:02 [RFC] store RAID stride in superblock Andreas Dilger
2007-05-12 2:21 ` Eric Sandeen
2007-05-12 8:11 ` Eric
2007-05-12 8:33 ` Alex Tomas
2007-05-12 9:32 ` Eric
2007-05-12 9:38 ` Alex Tomas
2007-05-12 16:14 ` Eric
2007-05-12 15:26 ` Andreas Dilger
2007-05-19 2:08 ` Theodore Tso
2007-05-24 11:44 ` Andreas Dilger
2007-05-24 14:15 ` Rupesh Thakare
2007-05-31 16:21 ` Theodore Tso
2007-05-31 20:19 ` Andreas Dilger
2007-05-31 21:02 ` Kalpak Shah
2007-05-31 21:33 ` Theodore Tso [this message]
2007-05-31 22:01 ` Eric Sandeen
2007-05-31 22:03 ` Andreas Dilger
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=20070531213301.GC13660@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@clusterfs.com \
--cc=kalpak@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
--cc=rupesh@clusterfs.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).