-O inline_data not supported by Ubuntu e2fsprogs

[Claes Wallin]

Since kernel version 3.8, ext4 supports the file system option inline_data to put file content into the inode itself as an extended attribute. However, this feature cannot be enabled using the included e2fsprogs in Trusty Tahr. If it has been enabled for a file system, boot e2fsck fails.

Support for this is currently being worked on upstream in https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/log/?h=pu . Adding this bug to track when this is merged into mainline and/or the ubuntu e2fsprogs.

[Claes Wallin (clacke)]

`pu` was merged into `next`/`master` early March 2014.

[Claes Wallin (clacke)]

... so this will be fixed whenever 1.43 is released.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel Mehrmann (daniel-mehrmann)]

I build a personal Ubuntu PPA for this tools collection (e2fsprogs).

I did a snapshot of git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git and used the master trunk maint. I will update my personal PPA monthly or if tytso tells me it's time to do so. :-)

I build deb packages for trusty, utopic and vivet and/or you can use my bzr branch for these packages.

You can add my PPA to your Ubuntu system with:

sudo add-apt-repository ppa:daniel-mehrmann/admin
sudo apt-get update
sudo apt-get upgrade

Happy testing!!

(And don't forget to report bugs to linux-ext4 and help developers to get this feature more stable)

Links:

PPA: https://launchpad.net/~daniel-mehrmann/+archive/ubuntu/admin
BZR branch: https://code.launchpad.net/~daniel-mehrmann/e2fsprogs/maint

[Theodore Ts'o (tytso)]

Note: if you want to use inline data, please strongly consider using the upstream kernel; there are a lot of bugs that we're only now shaking out.

[Claes Wallin (clacke)]

Thank you Daniel and Theodore for your feedback!

I tried merging pu into maint the other day, but it didn't apply cleanly. I will try again later.

When I get around to trying it out, I will go with your recommendation and use the latest mainline.

[Theodore Ts'o (tytso)]

Just use the master branch of e2fsprogs; the pu branch is currently not actually active, and when it is, it has experiments in it that might not necessarily be ready for primetime.

The master branch should be good enough for both the inline data and metadata checksum features.

[Daniel Mehrmann (daniel-mehrmann)]

Clarification: I used branch 'master' for my packages and bzr branch as well.

First i thought it would be a good idea to use the branch 'maint'.
But later on i decided to use the branch 'master'. After uploading
the bzr branch to lp i notice that i used the wrong label (naming) in lp and it was
to late for a correction , because i announced it already.

[Theodore Ts'o (tytso)]

To explain the e2fsprogs git branch naming scheme in terms of Debian releases:

* maint == stable (and currently has a few bug fixes beyond what is in 1.42.12, although it's unlikely we will have a 1.42.13 release unless something really serious comes up)
* master == testing (and has the inline data and metadata csum feature support)
* next == unstable (and every few days to 1-2 weeks master will get moved up to the current unstable before I add new commits)
* pu == experimental (not currently active)

After 1.43 gets released, master will track 1.43 development for a while, and then maint will get renamed oldmaint, maint will get reset to master, and master and next will start tracking new development for the eventual 1.44 release.

We have not decided yet whether mke2fs will create file systems with metadata_csum and inline data by default in the 1.43 release series, although the answer is "probably not", at least not at first. Individual sysadmins can edit /etc/mke2fs.conf to change the defaults.

(File system developers tend to be *very* conservative, because while users will tolerate kernel crashes, bugs that lead to data loss tend to make end users very cranky indeed, and we try rather hard as a point of pride not to avoid such eventualities.)

[Daniel Mehrmann (daniel-mehrmann)]

My e2fsprogs ppa got an update :-)

* New upstream snapshot from master branch (23-02-2015)

  - libext2fs: fix potential buffer overflow in closefs()
  - e2fsck: salvage under-sized dirents by removing them
  - e2fsck: improve the inline directory detector
  - e2fsck: inspect inline dir data as two directory blocks
  - e2fsck: decrement bad count _after_ remapping a duplicate block
  - e2fsck: handle multiple *ind block collisions with critical metadata
  - e2fsck: fix message when the journal is deleted and regenerated
  - e2fsck: on read error, don't rewrite blocks past the end of the fs
  - e2fsck: clear i_block[] when there are too many bad mappings on a special inode
  - tune2fs: direct user to resize2fs for 64bit conversion
  - tune2fs: abort when trying to enable/disable metadata_csum on mounted fs
  - tune2fs: disable csum verification before resizing inode
  - resize2fs: fix regression test to not depend on ext4.ko being loaded
  - libext2fs: fix tdb.c mmap leak
  - libext2fs: strengthen i_extra_isize checks when reading/writing xattrs
  - libext2fs: avoid pointless EA block allocation
  - libext2fs: initialize i_extra_isize when writing EAs
  - debugfs: fix crash in ea_set argument handling
  - debugfs: document new commands
  - misc: fix minor testcase problems
  - Reserve the codepoints for the new INCOMPAT feature ENCRYPT
  - buildsystem: use 'chmod a-w' instead of 'chmod -w'
  - e2fsck: fix corruption of Hurd filesystems
  - e2fuzz: fix clang warning
  - Fix clang warning and a resource leak
  - e2fsck: close the progress_fd in the logfile child process
  - libext2fs: add sanity check for an invalid itable_used value in inode scan code

New bzr branch is: https://code.launchpad.net/~daniel-mehrmann/e2fsprogs/master

[Claes Wallin (clacke)]

This feature is in e2fsprogs 1.43, which is in yakkety (16.10). The bug can be closed.

[Claes Wallin (clacke)]

Have verified that `mkfs.ext4 -O inline_data` works with the yakkety e2fsprogs.