mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ben Rafanello" <benr@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org, lmb@suse.de
Subject: Re: [RFC] Multi-path IO in 2.5/2.6 ? [OFF TOPIC]
Date: Tue, 10 Sep 2002 12:27:03 -0500	[thread overview]
Message-ID: <OFC567F6B3.F9CC93E2-ON85256C30.005CADEB@pok.ibm.com> (raw)


On Tue, 2002-09-10 at 11:33, Christoph Hellwig wrote:
>>       Support at least 1024 disks
>>       Support at least 1024 volumes
>>       Support at least 32 partitions per disk
>
>At least those criterias aren't archived.

EVMS has no design limit on the number of disks
that it can support, and, the way it is coded,
the only limiting factor on the number of disks
it can support is the amount of memory available.
Any limits on the number of disks that EVMS can
use come from Linux itself, and, as such, are
beyond the control of the EVMS Team.  We are not
out to rewrite the kernel and the device drivers -
we are just trying to meet the requirements we
were given.

As for 1024 volumes, that limit is due to the
fact that EVMS has only 1 major number, as
discussed in the original post.  If EVMS were
allowed more major numbers, then this criteria
could be reached or exceeded.  However, we thought
it extremely unlikely that EVMS would be given
enough major numbers under 2.4x to reach this goal,
so we coded accordingly.  Should a miracle occur
and EVMS be given another three major numbers,
we could easily update our code to make use of
these extra major numbers and achieve 1023 volumes.

As for partitions, EVMS has no fixed limit on the
number of partitions per disk.  The limit for
partitions on a disk depends upon the size of the
disk and the disk partitioning scheme used.  I
currently run a stress test on EVMS where I create
405 partitions on a single SCSI disk.  These
partitions are then combined in various ways to
form volumes, which are then formatted and have
I/O tests performed on them.  All 405 partitions
are used.  Under EVMS, you could take any of
those partitions and turn it into a volume, which
makes it accessible. The only limit on EVMS is
the number of volumes it can create, and this is
due to EVMS having only 1 major number under 2.4x.
So not only did we meet this requirement, we greatly
exceeded this requirement.

Regards,

Ben Rafanello
EVMS Team Lead
IBM Linux Technology Center
(512) 838-4762
benr@us.ibm.com



             reply	other threads:[~2002-09-10 17:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-10 17:27 Ben Rafanello [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-09-10 15:59 Ben Rafanello
2002-09-10 16:12 ` Alan Cox
2002-09-10 16:33 ` Christoph Hellwig

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=OFC567F6B3.F9CC93E2-ON85256C30.005CADEB@pok.ibm.com \
    --to=benr@us.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmb@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

all inboxes | Powered by JetHome®