All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Robinson <zxvdr.au@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM limits?
Date: Fri, 01 Feb 2008 15:40:21 +1000	[thread overview]
Message-ID: <47A2B0C5.6010809@gmail.com> (raw)
In-Reply-To: <479E698C.10204@cesca.es>

Jordi Prats wrote:
> Hi,
> I'm the system administrator of PADICAT (http://www.padi.cat). It
> collects Catalan (http://en.wikipedia.org/wiki/Catalonia) web sites to
> provide permanent access to them (http://www.padi.cat/en/quees.php).
> It's equivalent to Internet Archive (http://www.archive.org) but for a
> particular culture.
> 
> Our software developers require us to have one large file system,
> actually a single directory, with all this historically-classified web
> sites on a gziped file.
> 
> I'm currently studying lustre and other HPC-related file systems to get
> this large file system, but by now I have ext3 as our file system. Next
> Monday I'm planning to extend it to 3TB o 4TB, so I'm currently
> researching for restrictions because during next month I'll have between
> 3TB to 4TB more to add: so, it will become a 8TB file system.
> 
> Last time I fsck my 2'1TB file system I spend about 2 hours. Anyway, I'm
> also curious about the maximums :P

The man page for vgcreate talks a little bit about limits:

"If the volume group metadata uses lvm1 format, extents can vary in size 
from 8KB to 16GB and there is a limit of 65534 extents in each logical 
volume. The default of 4 MB leads to a maximum logical volume size of 
around 256GB.
If the volume group metadata uses lvm2 format those restrictions do not 
apply, but having a large number of extents will slow down the tools but 
have no impact on I/O performance to the logical volume."

In short, you're more likely to reach filesystem limits before LVM's. 
EXT3 has a theoretical limit of 32 TB, but 32 GB its not practical. 
Creating an EXT3 filesystem larger than 8 TB is umm, brave - as you have 
noticed the tools (eg. fsck) do not scale well w/ EXT3.

GFS or XFS (or others) may be more suitable, but it depends on your 
requirements.

--Dave

  parent reply	other threads:[~2008-02-01  5:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 10:23 [linux-lvm] LVM limits? Jordi Prats
2008-01-28 19:24 ` Jordi Prats
2008-01-28 17:38   ` Chris Cox
2008-01-28 18:01     ` Ehud Karni
2008-01-28 19:08       ` Chris Cox
2008-01-28 19:53       ` Vesa-Pekka Palmu
2008-01-28 21:52       ` Joseph L. Casale
2008-01-28 23:38         ` Ehud Karni
2008-01-29  0:27           ` Chris Cox
2008-01-29 10:04             ` Ehud Karni
2008-01-29 16:16               ` Chris Cox
2008-01-29  0:16         ` Jordi Prats
2008-01-28 23:47     ` Jordi Prats
2008-01-29  6:58       ` Michael Eisenkölbl
2008-01-29 17:38       ` Lars Ellenberg
2008-02-01  5:40       ` David Robinson [this message]
2008-02-01 13:08         ` [linux-lvm] LVM limits? OT Steeve McCauley

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=47A2B0C5.6010809@gmail.com \
    --to=zxvdr.au@gmail.com \
    --cc=linux-lvm@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.