Microsoft Edge, Microsoft, Browser Internet Firefox, Mozilla, estensioni OpenOffice, software libero, Writer, Impress, Calc PadFone, smartphone Matroska, multimedia Avast, antivirus, sicurezza html5, flash, giochi iPhone, iPod touch e iPad infografica, internet browsers, opera, mozilla firefox, chrome, internet explorer cloud computing, internet

martedì 16 giugno 2009

Linus Torvalds annuncia il rilascio della versione 2.6.30 del kernel di Linux

Aggiornamenti al post: ultime versioni.

Ultima versione stabile: 2.6.31.4. Changelog in questa pagina

Release Candidate 5 della versione 2.6.32. (mainline) Changelog in questa pagina

Release Candidate 5 git1 della versione 2.6.32. (snapshot) Patch in questa pagina

Next - 20091016 (Linux next) Patch in questa pagina


Linus Torvalds ha annunciato il rilascio della versione 2.6.30 del kernel di Linux.

Numerose sono le novità introdotte in questa nuova release:

  • supporto al filesystem NILFS2, oltre a supporto preliminare per NFS 4.1, EXOFS, e FS-Cache;
  • implementazione del supporto allo standard wireless 802.11w;
  • numerose nuove funzionalità incluse nel kernel, nonchè supporto a nuove tipologie di hardware, miglioramenti alla velocità di boot e supporto a alle architetture Microblaze.
Tutti i cambi riportati nella home page del progetto kernelnewbies.org:

Prominent features (the cool stuff)

1.1. NILFS2, a log-structured filesystem

Contributor: NTT Labs (Nippon Telegraph and Telephone Corporation)

NILFS2 is a new filesystem which uses a log-structured design. What makes log-structured filesystems different is that they treat the whole disk as a consecutive list of blocks (called log). All the operations append data at the end of the log, they never rewrite blocks (except when there's no space left - in that case, new blocks are reclaimed from the start of the log). The advantage of this approach is that all modifications an creations are converted into sequential operations, which are faster. Crashes can't corrupt the filesystem. On mount, the filesystem detects the real end of the log, and continues working from that point.

Another advantage of this approach is that the log offers a coherent historical view of all the operations done in the disk in the past. This is called "continuous snapshotting" - snapshots of modifications done in all the filesystem at any time are created automatically due to the log-structure design, with no requirement of intervention from an admin, and with the filesystem size as the only limit. NILFS2 allows to access those snapshots and even mount them (on read-only mode).

NILFS2 is under development. Code: fs/nilfs2/. Filesystem web page: www.nilfs.org

1.2. POHMELFS and DST

Contributor: Evgeniy Polyakov

Recommended LWN articles: Distributed storage and CRFS and POHMELFS

  • POHMELFS stands for Parallel Optimized Host Message Exchange Layered File System. It is a high performance and network distributed filesystem with ability to balance reading from multiple hosts and simultaneously write data to different remote nodes, with a local writeback cache of data and metadata, which greatly speeds up every IO operation. It beats NFS by a big margin in most, if not all, operations. You can find more details and benchmarks about it in its home page. POHMELFS is hosted in the "staging" section of the kernel code, although it's already quite mature. Code: drivers/staging/pohmelfs/

  • DST stands for Distributed (network) STorage. DST allows the creation of high-performance storage networks in a reliable and easy manner. DST allows to form a storage on top of local and remote nodes and combine them into linear or mirroring setup, which in turn can be exported to remote nodes, an equivalent of much of the functionality offered by the device mapper, iSCSI, and network block device (NBD) layers. It works on top of any network media and protocol. DST may fully encrypt the data channel in case of untrusted channel and implement strong checksum of the transferred data. DST is hosted in the "staging" section of the kernel code. Code: drivers/staging/dst/

1.3. Reliable Datagram Sockets (RDS) protocol support

Contributor: www.openfabrics.org (Particularly, Oracle)

RDS provides a high bandwidth, low latency, reliable inter-process communication protocol and transport system between the servers in a cluster. It provides a reliable connection between any two nodes in the cluster. This allows applications to use a single socket to talk to any other process in the cluster - so in a cluster with N processes you need N sockets, in contrast to N*N if you use a connection-oriented socket transport like TCP. In beta testing, RDS over infiniBand provided up to 60 percent performance improvement over Gigabit Ethernet for interconnect-intensive applications. RDS is already used by some products like Oracle and in Silverstorm's Quicksilver.

Code: net/rds/

1.4. Fastboot

Recommended LWN article: An asynchronous function call infrastructure

Contributor: Intel

Some parts of the kernel boot process can delay the whole process too many time (by kernel's standards): scanning in search of storage devices for a given controller, and searching for partitions, for example, can be slow, because the scanning is synchronous, only one device is scanned at a time, and the kernel has to wait for the devices. With this feature, those steps are done asynchronously, so the kernel can keep booting the rest of the kernel while the storage devices are scanned in parallel. This feature speeds up the total kernel boot time significantly

Code: (commit)

1.5. IEEE 802.11w (wireless management frame protection support)

Contributor: Atheros

The IEEE 802.11w standard is a proposed (still not approved) amendment to the IEEE 802.11 standard (wifi) that increase the security of its management frames. In this version Linux adds a preliminary implementation for this future standard, developed according to the current drafts.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13)

1.6. preadv()/pwritev() system calls

Recommended LWN article: Some new system calls

Contributor: Red Hat

These syscalls are a pretty straightforward combination of pread/pwrite and readv/pwrite. BSD systems have such system calls too, for example NetBSD

Code: (commit 1, 2, 3)

1.7. EXOFS, a filesystem for Object-Based Storage Devices

Recommended LWN article: Linux and object storage devices

Contributor: Panasas

Traditional storage devices offer a block-based interface. However, there's a new generation of experimental storage devices that are trying to offload some work from the host, and offer a higher-level interface: an array of objects. The OS interfaces with the objects, and the drive hides all the storage details, removing most of the low-level details of the filesystem. A traditional filesystem can then be easily implemented on top of this interface. The OSD interface works on top of SCSI.

In this release Linux adds support for the OSD protocol on the SCSI stack, and exofs, an implementation of a traditional unix filesystem that works on top of OSD storage devices.

libosd: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16),

EXOFS: fs/exofs/

1.8. NFS 4.1 preliminary support

Contributors: Panasas, Netapp and IBM.

NFS 4.1 is being developed at the IETF. From the many new features in NFSv4.1, this Linux version adds the mandatory-to-implement NFSv4.1 Sessions. Other features, Parallel NFS in particular, are still under development out of tree and will be added in later releases.

To enable this experimental new protocol (which is disabled by default) you need an updated nfs-utils.

1.9. FS-Cache, a caching filesystem

Recommended LWN article: A general caching filesystem

Contributor: Red Hat

FS-Cache is the Linux implementation of a cache layer for networking filesystems, similar to the CacheFS of other Unixes. With FS-Cache, data from the networked filesystems can be cached on the disk, speeding up operations.

This version adds support for NFS and AFS, but it's a generic layer that could be used by other networking filesystems or even non-networking (such as ISO9660).

Code: Slow-work related changes: (commit 1, 2, 3, 4), FS-cache (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16, 17 18, 19); AFS and NFS changes: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16, 17 18), Documentation: Documentation/filesystems/caching/fscache.txt.

1.10. Tomoyo, an alternative Mandatory Access Control

Recommended LWN article: TOMOYO Linux and pathname-based security

Contributor: NTT DATA CORPORATION

There're currently two security subsystems: Selinux and Smack. Tomoyo is a new pathname-based access control.

(commit 1, 2, 3, 4, 5, 6, 7)

Tomoyo Web Site: http://tomoyo.sourceforge.jp/wiki-e/

1.11. Filesystems performance improvements

Shortly after the 2.6.29 release, lots of discussions occurred on LKML about disk I/O (summary available at LWN), how (and why) a fsync () call can take minutes, and the effect of getting a file zeroed rebooting just after a rename or a truncate. Some changes have been done to fix those problems: implicit internal fsync of a file after a rename or truncate in ext3, ext4 and btrfs, faster fsync() in ext3, default to data=writeback mode in Ext3, and improvements to CFQ. The flame has also brought the topic of atimes updates, and which has resulted into merging relatime and making it a default.

1.12. LZMA/BZIP2 kernel image compression

Contributor: Alain Knaff

The kernel compresses the kernel with GZIP, but this version adds support to compress the kernel image with the LZMA or BZIP2 compression algorithms. The kernel size is about 10 per cent smaller with bzip2 in comparison to gzip, and about 33 per cent smaller with lzma.

Code: (commit 1, 2, 3, 4, 5)

1.13. Microblaze CPU architecture

Contributor: Michal Simek, with donations from PetaLogix and Xilinx

This release adds support for the MMU-less Microblaze CPU architecture. It has been

Code: arch/microblaze/

1.14. Integrity Management Architecture

Contributor: IBM

Recommended LWN article: Integrity management in the kernel

The Trusted Computing Group(TCG) runtime Integrity Measurement Architecture(IMA) maintains a list of hash values of executables and other sensitive system files, as they are read or executed. If an attacker manages to change the contents of an important system file being measured, we can tell. If your system has a TPM chip, then IMA also maintains an aggregate integrity value over this list inside the TPM hardware, so that the TPM can prove to a third party whether or not critical system files have been modified.

Code: (commit 1, 2, 3, 4, 5, 6, 7)

Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:


Nessun commento:
Scrivi commenti

Random Posts