[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Ext4 and large (>8TB) files



On 03/26/2010 03:50 PM, Arun Nair wrote:
> Eric,
> 
> Thanks for the quick reply... see my responses inline...
> 
> On Fri, Mar 26, 2010 at 12:16 PM, Eric Sandeen <sandeen redhat com
> <mailto:sandeen redhat com>> wrote:
> 
>     On 03/26/2010 01:52 PM, Arun Nair wrote:
>     > Hi -
>     >
>     > (I apologize for the ext4 question in an ext3 mailer, but I couldn't
>     > find a user list for ext4.)
> 
>     linux-ext4 vger kernel org <mailto:linux-ext4 vger kernel org> :)
>      but that's ok.
> 
> 
> Saw that but thought it was a dev-only list, sorry. Next time :)

*shrug* I think user questions are welcome too.  At least I don't mind.

...

> dd fails as mentioned above. xfs_io errors too:
> [root camanoe]# xfs_io -F -f -c "pwrite 8T 1M" bigfile2
> pwrite64: File too large

Oh.  Well, then!  Must be something else.

oh, ok:

sbi->s_bitmap_maxbytes = ext4_max_bitmap_size();

static loff_t ext4_max_size(int blkbits, int has_huge_files)
{
        loff_t res;
        loff_t upper_limit = MAX_LFS_FILESIZE;

<snip>

        /* Sanity check against vm- & vfs- imposed limits */
        if (res > upper_limit)
                res = upper_limit;

        return res;
}

and:

/* Page cache limit. The filesystems should put that into their s_maxbytes
   limits, otherwise bad things can happen in VM. */
#if BITS_PER_LONG==32
#define MAX_LFS_FILESIZE (((u64)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1)

so it's only giving us 31 bits of pages, not 32.  This limits it to 8T
on a 32-bit machine with 4k pages.

I'm not honestly sure if there is anything in the vm that can't actually
cope with a 32-bit offset... but until proven otherwise, probably not
going to change this without a lot of testing & inspection.

-Eric


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]