Linux LVM users
 help / color / mirror / Atom feed
From: Michael Marxmeier <mike@msede.com>
To: linux-lvm@msede.com
Subject: [linux-lvm] Fwd: Re: file system size limits
Date: Fri, 07 Jan 2000 13:26:48 +0100	[thread overview]
Message-ID: <3875DB88.8CF6C807@msede.com> (raw)

Forwarded to the list.

-------- Original Message --------
Sender: manfreds@colorfullife.com
Message-ID: <3875C6BD.77A307DD@colorfullife.com>
Date: Fri, 07 Jan 2000 11:58:05 +0100
Resent-Date: Fri, 07 Jan 2000 13:21:02 MEZ
From: Manfred Spraul <manfreds@colorfullife.com>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>, linux-LVM@msede.com
CC: Andrea Arcangeli <andrea@suse.de>, Andi Kleen <ak@muc.de>,
        linux-fsdevel@vger.rutgers.edu
Subject: Re: file system size limits

[I added linux-LVM to the cc list because it could be a LVM problem]

"Theodore Y. Ts'o" wrote:
> 
>    From: "Manfred Spraul" <manfreds@colorfullife.com>
>    Date:   Thu, 6 Jan 2000 20:08:59 +0100
> 
>    Ok, so the limits are even more complex:
>    * on an Alpha, you could build a 4TB ext2 volume and use it.
>    * if your Alpha crashes, and you connect your disks to an i386 box, then you
>    could corrupt your file system unless someone has added safety checks.
> 
>    I'm merely try to verify that these safety checks exist:
>    eg. ext2 on Alpha supports files > 2 GB, but linux-2.2 on i386 doesn't. If
>    you try to mount the disk on i386, then ext2 refuses to perform invalid
>    operations on these files.
> 
> We're *way* ahead of you.

I knew that, but this only means that ext2 is safe.
What about the other subsystems?
eg it seems that lvm doesn't contain the checks for lvm's > 2 TB on
32-bit platforms.

* LVM can map up to 128 TB [I only checked the header file of
LVM-0.8i]
* This would work on 64-bit platforms.
* If you attach these disks to a 32-bit platform, you'll corrupt your
data. [but perhaps LVM will refuse to mount it, but I couldn't find
such
checks at first glance].

> The on-disk format of the ext2 filesystem only allows 4 bytes for the
> block number, and it's defined to be an unsigned value.  So if you're
> using 4k blocks, the maximum theoretical filesize is 64 TB.  (i.e.,
> 4*2^10*2^32 == 2^46)

That's the ext2 limit. But the real-life limit is lowest value of
(ext2-limit, ll_rw_blk limit, LVM limit, raid limit).

I think we must check these limits, and ensure that everyone refuses
to
work with larger disks.
ext2 is OK, but this doesn't mean that the complete chain
syscall-to-disk will be OK.

--
	Manfred

             reply	other threads:[~2000-01-07 12:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-07 12:26 Michael Marxmeier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-01-07 14:10 [linux-lvm] Fwd: Re: file system size limits Michael Marxmeier
2000-01-07 15:20 ` Heinz Mauelshagen

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=3875DB88.8CF6C807@msede.com \
    --to=mike@msede.com \
    --cc=linux-lvm@msede.com \
    --cc=manfreds@colorfullife.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