linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul McKenney <Paul.McKenney@us.ibm.com>
To: Andries.Brouwer@cwi.nl
Cc: Andries.Brouwer@cwi.nl, James.Bottomley@steeleye.com,
	linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org,
	linux-scsi@vger.kernel.org, pbadari@us.ibm.com
Subject: Re: [patch for playing] Patch to support 4000 disks and maintain backward compatibility
Date: Fri, 11 Apr 2003 18:13:24 -0700	[thread overview]
Message-ID: <OFAD4FBC86.382E53DF-ON88256D06.0006AAF3@us.ibm.com> (raw)





> > It would also be nice for numeric compatibility to be a compile time
option
>
> It sounds as if you expect a lot of old cruft.
> But the compatibility code is just ten lines or so.
> Internally the kernel has an index. Externally there is a dev_t.
> At open() time the dev_t is converted. At registration time
> sd announces interest in three or four dev_t regions.
> That is all.

Some compatibility needs more code than other compatibility.
The desired compatibility includes the following, much of which
has been noted earlier in this thread, and some of which may
need to wait for multipath I/O and other of which might be best
provided by a volume manager:

o     It must be possible to switch between 2.4 and 2.5/6
      kernels without a given disk's name changing.

o     New 2.5/6 installations should se a clean disk naming
      scheme without historical cruft.

o     Removing or adding one disk should not affect the
      names of other disks.  Ideally, moving a given disk
      from one place to another should not change its
      name.  "The good news is that we repaired your
      disk.  The bad news is that, due to the resulting
      name changes, your application thoroughly
      corrupted all of its data."

o     Adding or removing a FC or SCSI adapter should not
      affect the names of disks hanging off of other
      FC or SCSI controllers.  Ideally, the name of
      a disk should not change when its FC or SCSI
      controller is moved from one slot to another.

o     Failures of or repairs to the FC fabric should
      not change the names of any of the disks (though
      a sufficiently thorough failure might make some
      of the disks unreachable).

o     Cluster nodes should ideally have the same name
      for a given disk.  Extra credit, though greatly
      appreciated by anyone who has ever had to deal
      with a cluster where different nodes have different
      names for the same disk.  ;-)

                              Thanx, Paul


             reply	other threads:[~2003-04-12  1:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-12  1:13 Paul McKenney [this message]
2003-04-12 14:14 ` [patch for playing] Patch to support 4000 disks and maintain backward compatibility James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2003-04-13 13:59 Paul McKenney
2003-04-11 21:13 Andries.Brouwer
2003-04-11 19:45 Andries.Brouwer
2003-04-11 20:14 ` James Bottomley
2003-04-11 23:21   ` Joel Becker
2003-04-11 18:07 Andries.Brouwer
2003-04-11 19:12 ` James Bottomley
2003-04-11 11:42 Andries.Brouwer
2003-04-11 14:33 ` James Bottomley
2003-04-11 16:21   ` Badari Pulavarty
2003-04-11  0:13 Andries.Brouwer
2003-04-10 23:53 Andries.Brouwer
2003-04-11  1:09 ` Badari Pulavarty
2003-04-11 10:09   ` Douglas Gilbert
2003-04-11 16:12     ` Badari Pulavarty
2003-04-10 23:33 Andries.Brouwer
2003-04-10 23:37 ` Badari Pulavarty
2003-04-10 23:09 Andries.Brouwer
2003-04-10 23:16 ` Badari Pulavarty
2003-04-10 22:09 Andries.Brouwer
2003-04-10 22:22 ` Badari Pulavarty
2003-04-10 23:57 ` Roman Zippel
2003-04-10 20:39 Badari Pulavarty
2003-04-10 20:54 ` Randy.Dunlap
2003-04-11  0:08 ` Roman Zippel
2003-04-11  1:25   ` Badari Pulavarty
2003-04-11 15:43     ` Joel Becker

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=OFAD4FBC86.382E53DF-ON88256D06.0006AAF3@us.ibm.com \
    --to=paul.mckenney@us.ibm.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=James.Bottomley@steeleye.com \
    --cc=linux-kernel-owner@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pbadari@us.ibm.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).