Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

i receive the following error when i try to mount my raid 6 on Ubuntu Linux

mount /dev/md3 /mnt/md3
mount: File too large

i have another raid 1 existing (2TB only) and working fine .. any ideas?

When i tried

./mke2fs -O 64bit,has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize /dev/md3

i received the following output

mke2fs 1.43-WIP (22-Sep-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
274700288 inodes, 4395201024 blocks
219760051 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2248146944
134131 block groups
32768 blocks per group, 32768 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
        2560000000, 3855122432

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

and when i try to mount still receive the following error

mount: File too large

The error from dmesg

EXT4-fs (md3): filesystem too large to mount safely on this system
share|improve this question
    
What FS is it? Many don't deal with >16TB volumes. –  Chopper3 Dec 31 '12 at 21:32
    
right now it is ext4, i also tried xfs but with no luck –  BluesRhythm Dec 31 '12 at 21:36
    
What filesystem is the root partition? –  Joel E Salas Dec 31 '12 at 22:25
    
@JoelESalas the root file system is ext4 –  BluesRhythm Jan 1 '13 at 15:45

2 Answers 2

up vote 12 down vote accepted

This is an issue with your current version of e2fsprogs which is included with mke2fs. Version 1.41 and lower will error out for operations on volumes larger than 16TB.

That said, the workaround to this is to compile the current branch of e2fsprogs from the Linux kernel repository and create the filesystem using these tools (as of this writing 1.43-WIP 22-Sep-2012 will be installed).

Note that these are dev tools and may not be completely stable. Also, 'git', 'gcc' (or another C compiler) and 'make' will need to be installed in order to build the tools.

[root@gauss ~] git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
[root@gauss ~]# cd e2fsprogs
[root@gauss e2fsprogs]# mkdir build ; cd build/
[root@gauss build]# ../configure
[root@gauss build]# make
[root@gauss build]# make install
[root@gauss misc]# cd misc
[root@gauss misc]# ./mke2fs -O 64bit,has_journal,extents,huge_file,flex_bg,uninit_bg,dir_nlink,extra_isize /dev/md3

Additionally, Ronny Egners Blog has some useful insights regarding using the work in progress branch of e2fsprogs with large filesystems.

share|improve this answer
    
Unfortunately i have already tried this and it didn't work .. I'll edit the question to include the output of running the command from the blog. –  BluesRhythm Jan 1 '13 at 15:48
    
Is there any additional error information in /var/log/syslog or dmesg besides the "mount: File too large" error? Also, just to clarify, are you running a 32 or 64 bit kernel? –  esquireofoz Jan 1 '13 at 16:29
    
the error from syslog and dmesg kernel: [1011248.433311] EXT4-fs (md3): filesystem too large to mount safely on this system and the kernel is 32 –  BluesRhythm Jan 1 '13 at 16:43
2  
The errors indicate this is a limitation of a 32-bit kernel. Unfortunately the only way to resolve this is to migrate/reburn to a 64-bit kernel. –  esquireofoz Jan 1 '13 at 17:01
    
I'm willing to do that .. but are you positive it is related to the 32-bit kernel!? ... i searched and found no limitations on the 32-bit capacity .. and may i ask you, from what of the error messages you reach the conclusion it is a 32-bit limitations issue? –  BluesRhythm Jan 1 '13 at 17:08

32 bit kernels are limited to 16 TiB because the page cache entry index is only 32 bits.

This is a kernel limitation, not a filesystem limitation!

Some filesystems are also 32 bit (or less) limited by design. Some filesystems are also limited by their utilities (example: mkfs, fsck). Also note that running fsck on a very large filesystem may require a lot of RAM (depends on the filesystem and utilities).

To use a filesystem >16 TiB, you must use a 64 bit kernel and a filesystem that supports >16 TiB (example: EXT4, JFS, XFS).

Note that an EXT4 filesystem created on a 32 bit system cannot be resized >16 TiB even on a 64 bit system. The EXT4 filesystem must be created on a 64 bit system, so that it gets the "64bit" feature flag, and enlarged inodes.

You can use LVM2 to create multiple volumes on a large device. Use a large extent size like 64 MiB or larger so that the number extents can be kept low. You do not need to partition a data-only device; you can format an entire device as a LVM2 physical volume (PV).

You only need to partition boot devices, because the BIOS won't understand LVM2 and the BIOS needs to find and load the bootstrap. You can use MSDOS or GPT (or whatever) for partitioning your smaller boot device.

Example: I have a server with 2x 64 GB SSD for the OS (one for the current OS, one for the new OS when upgrading), and 10x 4 TB drives formatted as a single a LVM2 physical volume, and containing a single EXT4 filesystem. The drives sit on a raid controller card that does RAID-6, but this can also be done in software by the kernel with a small performance penalty.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.