Filesystem with huge files cannot be mounted read-write without CONFIG_LBDAF
After skipping 2.6.30 and building a new 2.6.31 I suddenly couldn't mount my ext4 drive anymore and got this rather confusing error in dmesg:
EXT4-fs (sda1): Filesystem with huge files cannot be mounted read-write without CONFIG_LBDAF
But... I don't have any huge files on that disk. Not bigger than some DVD iso anyway.After a few days I finally get the time to check the kernel configuration docs, and they say:
CONFIG_LBDAF:Enable block devices or files of size 2TB and larger.This option is required to support the full capacity of large (2TB+) block devices, including RAID, disk, Network Block Device, Logical Volume Manager (LVM) and loopback.This option also enables support for single files larger than 2TB.The ext4 filesystem requires that this feature be enabled in order to support filesystems that have the huge_file feature enabled. Otherwise, it will refuse to mount in the read-write mode any filesystems that use the huge_file feature, which is enabled by default by mke2fs.ext4.The GFS2 filesystem also requires this feature.If unsure, say Y.
Well, alright. mkfs.ext4 has said feature enabled by default. That's what you get for building your own kernels and not reading everything in make oldconfig.
Edit: The feature can be activated at Enable the block layer ---> Support for large (2TB+) block devices and files, thanks to Arix.Edit:: The feature can be removed from an existing filesystem by running the following commands:
tune2fs -O ^huge_file /dev/whatever
This should allow you to mount the drive without CONFIG_LBDAF in the kernel. Thanks Marcus!
What are the odds? I was just custom building my kernel last night (9/14/2009) and skipped this flag because my laptop has less than 10 GB dedicated to Linux and "large" files over 2TB sounded unattainable. But, like the author, not reading the entire help description and formatting the partitions with ext4, during the kernel boot message I noticed a lot of FATAL messages are being thrown around. Of course, not a single partition was mounted due to this foible, and I couldn't even run the simplest programs (no /usr, no /home, no nothing). For those that have made a similar error like we did, the location of this feature is at:
Enable the block layer -> Enable block devices or files of size 2TB and larger
Enable it for your own sake of sanity. Of course, you could have just simply `grep' the ".config" file for "CONFIG_LBDAF" or search for it in menuconfig' help console ("/").
I forgot to add, that I too was custom building the kernel version 2.6.31 (on an old Toshiba laptop).
Nice, I didn't know about the search functionality in menuconfig yet. Thanks for pointing that out!
thanks. this saved me an headache :/
I guess the feature should be automatically flagged whenever ext4 is selected.
Indeed, the fooconfig targets offer dependency checking. But I guess the kernel hackers have their reasons for not enabling it, after all not everybody uses the same mkfs options.
Since the problem is caused by mke2fs.ext4 that by default formats with the huge_file feature on, one can format a new partition giving a set of features that overrides the default and that does not include the huge_file one:
mke2fs -t ext4 -O has_journal,extents,flex_bg,uninit_bg,dir_nlink,extra_isize
Or, one could edit the /etc/mke2fs.conf file and remove the huge_file feature among the default ones, as I did on my Gentoo desktop. I don't know if one can change the features without reformatting and already formatted partition, though.
For removing the huge_file option from the filesystem without destroying it you can use this command
tune2fs -O ^huge_file /dev/sda1
and it should mount without CONFIG_LBDAF in your kernel.
Thanks for this! I'll update the article and add the info.
sorry for a lame question, but what if it is my root partition? tune2fs is unable to clear huge_file flag from it when it mounted, and I can not remount it read-only.
You can boot off a different device, some kind of rescue CD would probably be the easiest.
Thanks for the post. Figured that one myself the hard way -- been configuring kernel all weekend :( But you know nothing before you've messed a couple of kernels :)))