Kernel compile-time switch issues affecting ext4

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

Kernel compile-time switch issues affecting ext4

#1 Post by Sit Heel Speak »

I have been combing through the kernel compile-time config switches, with the aid of Debian developer "cate's" encyclopedia at
http://cateee.net/lkddb/web-lkddb/
and have observed a few switches which bear upon ext4 support and concerning which Puppy k2.6.29.6 is, as Linus would say, at present both ugly and stupid. These are in addition to the well-known inode blocksize=256 versus 128 issue which has been giving Puppyists fits at
http://www.murga-linux.com/puppy/viewtopic.php?p=293877
and other threads which a Google-Puppy-forum search finds if you search on "inode 256 Ubuntu":

# CONFIG_EXT4DEV_COMPAT is not set
should be CONFIG_EXT4DEV_COMPAT=y
Help text from http://cateee.net/lkddb/web-lkddb/:
Starting with 2.6.28, the name of the ext4 filesystem was renamed from ext4dev to ext4. Unfortunately there are some legacy userspace programs (such as klibc's fstype) have "ext4dev" hardcoded. To enable backwards compatibility so that systems that are still expecting to mount ext4 filesystems using ext4dev, chose Y here. This feature will go away by 2.6.31, so please arrange to get your userspace programs fixed!

# CONFIG_LBDAF is not present
should be CONFIG_LBDAF=y
Help text from http://cateee.net/lkddb/web-lkddb/:
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.

# CONFIG_X86_INTERNODE_CACHE_BYTES is not present
not sure how this should be set, and don't know whether it bears upon the inode blocksize=256 issue; in Ubuntu 9.10-alpha-5 and Fedora 12-alpha it's
CONFIG_X86_INTERNODE_CACHE_BYTES=64

There are many, many CONFIG_CRYPTO... switches available which are not set in Puppy, dunno if this affects ext4 or not. However, one possible-error in particular caught my eye:

CONFIG_BLK_DEV_CRYPTOLOOP=m
should be changed to "is not set"
Help text from http://cateee.net/lkddb/web-lkddb/:
WARNING: This device is not safe for journalled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device.

The Device Mapper crypto module referred to above is CONFIG_DM_CRYPT, it is =m in Puppy, perhaps needs to be in the kernel (=y) for ext4.

HTH, SHS

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

1. CONFIG_EXT4DEV_COMPAT You shouldn't need this unless you are running one of the programs mentioned (not likely)

2. CONFIG_LBDAF You onyl need this if you have partitions which are >= 2TB (not likely)

3. CONFIG_X86_INTERNODE_CACHE_BYTES I don't know anything about this, but I don't think it has anything to do with ext4. If so, just try the values you found. To know if it is really necessary, check the slackware kernel config file. If slack doesn't use it it is most likely irrelevant to mortals...

4. CONFIG_BLK_DEV_CRYPTOLOOP ext4 *is* a journalled filesystem, so this should not be set.

Post Reply