VMI is meant to be a common interface for virtualization vendors that use paravirtualization. VMI is described as a way to let vendors use different hypervisors to manage any Linux virtual machine with VMI enabled. Linux kernels with VMI support can boot up under a hypervisor like VMware's or they can boot up on bare metal without the benefit of a hypervisor, so vendors don't need to ship separate kernels for hypervisor support and standard machines. VMI is discussed in depth in an article on Linux Weekly News.
The 2.6.21 kernel also includes a dynamic ticks (dynticks) feature. This allows kernels to run in a "tickless" mode that allows Linux to use power-saving features in today's CPUs and thus save power on laptops when the system is idle.
According to the release notes on KernelNewbies, this kernel adds support for a framebuffer driver for the S3 Trio/Verge video card, IDE drivers for the Gigaset M101 wireless ISDN, Davicom DM9601 USB 1.1 Ethernet device, a driver to charge BlackBerry devices via USB, support for the GTCO CalComp/InterWrite USB tablet, and more. This kernel also removes support for several video drivers that were marked "BROKEN" when the 2.6.20 kernel was released.
This kernel also includes a number of filesystem improvements, including read and write support for Unix File System 2 (UFS2), as well as improvements to eCryptfs, Global File System 2 (GFS2), IPv6 support for the Network File System (NFS), and other improvements for Linux-supported filesystems. Support for the Journaling Flash File System (JFFS), version 1, was removed by Jeff Garzik, since it has been superseded by JFFS version 2, and has been unmaintained for some time.
The 2.6.21 kernel may take some time to appear in stable distros, but you can download the source and compile 2.6.21 on your systems if you're impatient. For a full description of changes in the 2.6.21 kernel, see the KernelNewbies writeup, and the ChangeLog.
Note: Comments are owned by the poster. We are not responsible for their content.
Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0). The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen below where compression does not speed things up. However, more importantly, it does not slow things down either.<tt>| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
|REISER4 | 3462 | 692 |
|EXT2 | 4092 | 816 |
|JFS | 4225 | 806 |
|EXT4 | 4408 | 816 |
|EXT3 | 4421 | 816 |
|XFS | 4625 | 779 |
|REISER3 | 6178 | 793 |
|FAT32 |12342 | 988 |
|NTFS-3g |10414 | 772 |</tt>
Each test was preformed 5 times and the average value recorded.<tt>|File |Disk |Copy |Copy |Tar |Unzip| Del |
|System |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type | (MB)| (1) | (2) |655MB|655MB| Gig |
|REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 |
|REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 |
|REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 |
|REISER4 | 692 | 148 | 55 | 67 | 25 | 56 |
|NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 |
|NTFS | 779 | 781 | 173 | X | X | X |
|REISER3 | 793 | 184 | 98 | 85 | 63 | 22 |
|XFS | 799 | 220 | 173 | 119 | 90 | 106 |
|JFS | 806 | 228 | 202 | 95 | 97 | 127 |
|EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 |
|EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 |
|EXT3 | 816 | 182 | 74 | 73 | 43 | 51 |
|EXT2 | 816 | 201 | 82 | 73 | 39 | 67 |
|FAT32 | 988 | 253 | 158 | 118 | 81 | 95 |</tt>
Thanks for the informative post about Reiser4. However, which filesystem is the "best" cannot be judged solely on the basis of performance. How sure are we that it has no bugs that will lose or corrupt data? That is the #1 criterion, for me. Only after Reiser4 has been shown, beyond reasonable doubt, to be as good as the standard filesystems on this criterion will I even consider performance.
Should never appear in stable distros
Posted by: Anonymous Coward on April 27, 2007 03:53 AMThe 2.6.21 kernel may take some time to appear in stable distros
Make that "should never appear in stable distros".
This thing has been pushed out the door with minimal testing. It's unlikely to be stable enough for general users.
#