new ext4

[Yankee]

http://kernelnewbies.org/Linux_3.5#head-e8ea0d70436ea63590eac3dc25a7b417333147f8

and

http://lwn.net/Articles/469805/


All the above changes look good except if you have an older kernel
on something and enable a new feature on a new filesystem it might
only mount the new filesystem as read only when using it with an older kernel'd
OS.

Tempted to switch everything to ext3 for an instant.   This workaround
could help if OS installs with these higher kernels and ext4 capabilities
interfere with mount compatibilities of older OS partitions using older
kernels and ext4 features, trying to mount partitions with new OS's with new
kernels, and new ext4 advanced kernel and filesystem features enabled.
Could be ext5 but isn't.

To get most of the benefits of ext4 without losing compatibility mounting by
older OS partitions with coming newer OS installs.

1)  On the LiveCD or LiveUSB change /etc/mke2fs.conf lines 10-12 to :

[fs_types]
   ext3 = {
      features = has_journal,extent,uninit_bg
   }

2) proceed to install the new OS with the newest kernel and newest ext4 capabilities
in the normal manner otherwise, using ext3 as the target filesystem, and only
some basic ext4 features will be included in the installed filesystem.

This actually results in an ext3 filesystem with extents and journal checksums only
included making it a baby ext4 filesystem fully mountable with any old OS we have
whether it is a new install of KDE 5 with a 4.0 kernel forthcoming you're installing
or not AFAIK.

Of course, not enabling these current new ext4 features on the PCL standard
install program would be helpful.   Wish they closed the final ext4 patches as the ext4
filesystem by definition and started ext5 patches by definition for the new stuff
as a new selectable ext5 filesytem.   For the hobby/home desktop the above
potential workaround looks good to me.    Using it right now AAMOF.

Of course, if the new features available are not default or mandatory the default
ext4 filesystem created by install would remain 100% mountable by older OS
partitions.

Have a good one,

FF

P.s.  here's the workaround modified ext3 filesystem's parameters, a capable basic ext4

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nli

[menotu]

Posted by Michael Larabel on July 28, 2012

EXT4 Updates Go Into The Linux 3.6 Kernel

Two days after the Btrfs was updated with two big features for the Linux 3.6 kernel, the EXT4 file-system has now been updated for this next Linux kernel release.

Ted Ts'o mailed in the EXT4 feature pull for the Linux 3.6 kernel on Friday night followed by Linus pulling the tree in the early hours of Saturday.

The EXT4 work for the Linux 3.6 kernel isn't particularly exciting with just "the usual collection of bug fixes and optimizations." There is at least a speed-up for parallel, non-allocating DIO writes, but aside from that the fixes and other optimizations aren't anything really noteworthy.

http://www.phoronix.com/scan.php?page=news_item&px=MTE0ODM

[Yankee]

Posted by Michael Larabel on July 28, 2012

EXT4 Updates Go Into The Linux 3.6 Kernel

I think these new ext4 features forthcoming (bigalloc, inline data, and metadata checksums)
should really go into an ext5 filesystem by definition.   Same with xfs, so many fixes and
several new features, especially for xfsrepair should be in a new xfs2 filesystem by definition.

The xfs people are quite busy also hurrying patches trying to get them into the new kernels,
once again, could cause mounting problems with older kernel OS's.   So many new kernels
lately with so many people working on them.

If I use  ext4 = {features = has_journal,extent,large_file} for future formats deliberately
leaving out flex_bg and uninit_bg I think they'll all mount and also help the speed of my
flash drives which have no drive cache to store locations of block descriptors on the drive
eliminating that search for them when the flash drive needs them.   They'd all be on the
very front of the drive.   

Thanks for the response.

FF