Linus Torvalds announced yesterday on the Linux kernel mailing list the official release of Linux 2.6.27. This release includes some nice improvements and follows roughly three months after the release of 2.6.26.
This new version adds the ath9k wireless driver from Atheros, the gspca driver, which will significantly extend the number of webcam devices supported on Linux, a new function tracing framework and memory-mapped IO tracing tool that will simplify debugging, support for delayed allocation (a performance improvement) in the Ext4 filesystem, and UBIFS, a new filesystem designed for flash storage devices. Scalability got a boost in this release because of the lockless page cache feature and newly added support for systems with up to 4096 processors.
Additional Ext4 improvements, preemptible spinlocks, and support for syslets are areas of focus for upcoming releases, according to the Linux Foundation’s Linux Weather Forecast.
Here is a short and unsorted list of some of UBIFS features:
* write-back support – this dramatically improves the throughput of the file system comparing to JFFS2, which is write-through;
* fast mount time – unlike JFFS2, UBIFS does not have to scan whole media when mounting, it takes milliseconds for UBIFS to mount the media, and this does not depend on flash size; however, UBI initialization time depends on flash size and has to be taken into account (see here for more details);
* tolerance to unclean reboots – UBIFS is a journaling file system and it tolerates sudden crashes and unclean reboots; UBIFS just replays the journal and recovers from the unclean reboot; mount time is a little bit slower in this case, because of the need to replay the journal, but UBIFS does not need to scan whole media, so it anyway takes fractions of a second;
* fast I/O – even with write-back disabled (e.g., if UBIFS is mounted with -o sync mount flag) UBIFS shows good performance which is close to JFFS2 performance; bear in mind, it is extremely difficult to compete with JFFS2 in synchronous I/O, because JFFS2 does not maintain indexing data structures on flash, so it does not have the maintenance overhead, while UBIFS does have it; this is because of the way UBIFS commits the journal – it does not move the data physically from one place to another but instead, it just adds corresponding information to the file system index and picks different eraseblocks for the new journal (i.e., UBIFS has sort of “wandering” journal);
* on-the-flight compression – the data is stored in compressed form on the flash media, which makes it possible to put considerably more data to the flash than if the data was not compressed; this is very similar to what JFFS2 has; UBIFS also allows to switch the compression on/off on per-inode basis, which is very flexible; for example, one may switch the compression off by default and enable it only for certain files which are supposed to compress well; or one may switch compression on by default but disable it for supposedly uncompressible data like multimedia files; at the moment UBIFS supports only Zlib and LZO compressors and it is not difficult to add more