lkml.org 
[lkml]   [2006]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
    From
    Date
    On Thu, 2006-03-30 at 10:40 -0700, Andreas Dilger wrote:
    > On Mar 29, 2006 17:38 -0800, Mingming Cao wrote:
    > > Have verified these two patches on a 64 bit machine with 10TB ext3
    > > filesystem, fsx runs fine for a few hours. Also testes on 32 bit machine
    > > with <8TB ext3.
    >
    > Have you done tests _near_ 8TB with a 32-bit machine, even without these
    > patches?
    No I haven't. The >8TB right now is attached to a 64 bit machine, but we
    should able to move it to a 32 bit machine.

    > In particular, filling up the filesystem to be close to full
    > so that we really depend on the > 2TB code to work properly?

    I made a kernel patch to allow a file to specify which block group it
    wants it's blocks to allocate from(using ioctl to set the goal
    allocation block group). I set the goal block group falls to somewhere
    >8TB, and did dd tests on that file. Verified this with debugfs, the
    allocated block numbers are beyond 2**31.

    Also before run fsx tests, created many directories (32768 at most:) and
    verified one directory's inode is located in block group >8TB space. So
    when we do fsx test on files under that directory, we are
    creating/testing files >8TB.

    BTW, do you think this ioctl is useful in general for other users? I
    attached the patch here.

    I also plan to hack the code of inode allocation to force all files's
    inode is put in the block group >8TB, so that we could do a full
    filesystem tests there.


    > Also, in
    > theory with these patches even a 32-bit machine could run > 8TB, right?
    >
    > There have been sporadic reports of failure for large ext3 filesystems,
    > and some of them say that 32-bit systems fail and 64-bit systems work.
    > There is a kernel bugzilla bug open for this, but it was never really
    > identified what the source of the problem was.
    >

    Sure, I will verify that on my 32 bit machine with >8TB.

    > Cheers, Andreas
    > --
    > Andreas Dilger
    > Principal Software Engineer
    > Cluster File Systems, Inc.
    >

    Thanks,

    Mingming

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-30 21:19    [W:2.073 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site