From: David Greaves <david@dgreaves.com>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Bill Davidsen <davidsen@tmr.com>,
neilb@suse.de, linux-raid@vger.kernel.org
Subject: Re: [PATCH] Use new sb type
Date: Sun, 10 Feb 2008 12:27:25 +0000 [thread overview]
Message-ID: <47AEEDAD.5050405@dgreaves.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0802101311320.7176@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
> On Feb 10 2008 10:34, David Greaves wrote:
>> Jan Engelhardt wrote:
>>> On Jan 29 2008 18:08, Bill Davidsen wrote:
>>>
>>>>> IIRC there was a discussion a while back on renaming mdadm options
>>>>> (google "Time to deprecate old RAID formats?") and the superblocks
>>>>> to emphasise the location and data structure. Would it be good to
>>>>> introduce the new names at the same time as changing the default
>>>>> format/on-disk-location?
>>>> Yes, I suggested some layout names, as did a few other people, and
>>>> a few changes to separate metadata type and position were
>>>> discussed. BUT, changing the default layout, no matter how "better"
>>>> it seems, is trumped by "breaks existing setups and user practice."
>>> Layout names are a different matter from what the default sb type should
>>> be.
>> Indeed they are. Or rather should be.
>>
>> However the current default sb includes a layout element. If the default sb is
>> changed then it seems like an opportunity to detach the data format from the
>> on-disk location.
>
> I do not see anything wrong by specifying the SB location as a metadata
> version. Why should not location be an element of the raid type?
> It's fine the way it is IMHO. (Just the default is not :)
There was quite a discussion about it.
For me the main argument is that for most people seeing superblock versions
(even the manpage terminology is version and subversion) will correlate
incremental versions with improvement.
They will therefore see v1.2 as 'the latest and best'.
We had our first 'in the wild' example just a few days ago.
Feel free to argue that the manpage is clear on this - but as we know, not
everyone reads the manpages in depth...
It's misleading and I would submit that *if* Neil decides to change the default
then changing the terminology at the same time would mean a single change that
ushers in broader benefit.
I acknowledge that I am only talking semantics - OTOH I think semantics can be a
very important aspect of communication.
David
PS I would love to send a patch to mdadm in - I am currently being heavily
nagged to sort out our house electrics and get lunch. It may happen though :)
next prev parent reply other threads:[~2008-02-10 12:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 17:22 [PATCH] Use new sb type Jan Engelhardt
2008-01-28 18:19 ` David Greaves
2008-01-28 18:47 ` Peter Rabbitson
2008-01-28 19:32 ` David Greaves
2008-01-29 4:09 ` Tim Southerwood
2008-01-29 9:37 ` Peter Rabbitson
2008-01-29 11:25 ` Yes, but please provide the clue (was Re: [PATCH] Use new sb type) Moshe Yudkowsky
2008-01-28 19:10 ` [PATCH] Use new sb type Jan Engelhardt
2008-01-29 23:08 ` Bill Davidsen
2008-01-30 12:53 ` David Greaves
2008-02-08 0:23 ` Jan Engelhardt
2008-02-10 10:34 ` David Greaves
2008-02-10 12:12 ` Jan Engelhardt
2008-02-10 12:27 ` David Greaves [this message]
2008-02-10 12:30 ` Jan Engelhardt
2008-02-11 3:32 ` Bill Davidsen
2008-02-11 8:21 ` David Greaves
2008-02-11 18:28 ` Bill Davidsen
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=47AEEDAD.5050405@dgreaves.com \
--to=david@dgreaves.com \
--cc=davidsen@tmr.com \
--cc=jengelh@computergmbh.de \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).