linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: "Tom Sightler" <ttsig@tuxyturvy.com>, <linux-kernel@vger.kernel.org>
Subject: Re: Questions about Enterprise Storage with Linux
Date: Wed, 7 Mar 2001 20:11:01 -0600	[thread overview]
Message-ID: <01030720460701.06635@tabby> (raw)
In-Reply-To: <E14an7j-0001rZ-00@the-village.bc.nu> <20010307164052.B788@wirex.com> <006301c0a765$3ca118e0$1601a8c0@zeusinc.com>
In-Reply-To: <006301c0a765$3ca118e0$1601a8c0@zeusinc.com>

On Wed, 07 Mar 2001, Tom Sightler wrote:
>Hi All,
>
>I'm seeking information in regards to a large Linux implementation we are
>planning.  We have been evaluating many storage options and I've come up
>with some questions that I have been unable to answer as far as Linux
>capabilities in regards to storage.
>
>We are looking at storage systems that provide approximately 1TB of capacity
>for now and can scale to 10+TB in the future.  We will almost certainly use
>a storage system that provides both fiber channel connectivity as well as
>NFS connectivity.
>
>The questions that have been asked are as follows (assume 2.4.x kernels):
>
>1.  What is the largest block device that linux currently supports?  i.e.
>Can I create a single 1TB volume on my storage device and expect linux to
>see it and be able to format it?

Checkout the GFS project for really large filesystems with a high capability
of "fail safe" configuration.

The block/file limits are more determined by the size of the hosts. Alpha/Sparc
based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends
on usage of the sign bit in the drivers. Most 32bit systems are limited
to 1 TB (depending on the driver of course - some allow for 2 TB).

>2.  Does linux have any problems with large (500GB+) NFS exports, how about
>large files over NFS?

I can't really say - you might clarify by what you count as large ( just > 2G
should be fine for any current kernel), not sure if "large" means 25-100GB.

>3.  What filesystem would be best for such large volumes?  We currently use
>reirserfs on our internal system, but they generally have filesystems in the
>18-30GB ranges and we're talking about potentially 10-20x that.  Should we
>look at JFS/XFS or others?

The GFS project already has tested 2TB in fiber channel array(s) with full
multi-host connectivity (shared filesystems rather than NFS). See:

http://www.sistina.com/gfs/

for details. It is not currently included in Linux distribution. The
current GFS version is 4.0 and works in kernel 2.2.18 and higher.

The big advantage with GFS is that redundant servers can be available
by having two or more NFS servers attached to the same GFS filesystem.

>4.  We're seriously considering using LVM for volume management.  Does it
>have size limits per volume or other limitations that we should be aware of?

GFS may serve better. It is a full shared filesystem with RAID target disks
(these are smart controllers) and incudes journaling.

>I'm sure these answers are out there, but I haven't been able to find
>definitive answers (it seems everyone has a different answer to each
>question).  Any assistance in pointing me to the correct information would
>be greatly appreciated.

I haven't had direct expierence with GFS, but it looks very impressive in
the documentation.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

  reply	other threads:[~2001-03-08  2:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-07 23:13 Linux 2.4.2ac14 Alan Cox
2001-03-08  0:40 ` Greg KH
2001-03-08  0:17   ` Questions about Enterprise Storage with Linux Tom Sightler
2001-03-08  2:11     ` Jesse Pollard [this message]
2001-03-08  1:20       ` Marcelo Tosatti
2001-03-08  2:35       ` Tom Sightler
2001-03-08  6:00         ` Tim Moore
2001-03-08  5:09     ` Jauder Ho
2001-03-08  7:22     ` james rich
2001-03-09  0:29     ` Thomas Davis
2001-03-08  0:59   ` Linux 2.4.2ac14 Greg KH
2001-03-08 20:43   ` andersg
2001-03-08  0:43 ` [PATCH] " Tachino Nobuhiro
2001-03-08  1:26 ` Misspelled spinlock_prefetch for MK7 (was: Linux 2.4.2ac14) junio
2001-03-08  1:56   ` junio
2001-03-08  5:20 ` Linux 2.4.2ac14 Keitaro Yosimura
2001-03-08 12:12   ` Alan Cox
2001-03-08  7:37 ` Doug Ledford
2001-03-08 13:37 Questions about Enterprise Storage with Linux Jesse Pollard
2001-03-08 16:48 ` james rich
     [not found] <Pine.LNX.4.21.0103090725030.699-100000@penguin.homenet>
2001-03-09  7:37 ` Tigran Aivazian
2001-03-09 17:30 ` Jauder Ho

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=01030720460701.06635@tabby \
    --to=jesse@cats-chateau.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ttsig@tuxyturvy.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).