ZFS: 0.6.1

Today the ZFS on Linux project reached an important milestone with the
official 0.6.1 release! Over two years of use by real users has
convinced us ZoL is ready for wide scale deployment on everything from
desktops to super computers.

As always tarballs are available from zfsonlinux.org.

http://archive.zfsonlinux.org/downloads/zfsonlinux/spl/spl-0.6.1.tar.gz
http://archive.zfsonlinux.org/downloads/zfsonlinux/zfs/zfs-0.6.1.tar.gz

To simplify the installation and management of ZFS we have set up new
repositories for Debian, Fedora, and RHEL/CentOS. They can be found at
the following URLs.

Debian: Add to /etc/apt/sources.list
deb http://archive.zfsonlinux.org/debian wheezy main
deb-src deb http://archive.zfsonlinux.org/debian wheezy main

Fedora: See http://zfsonlinux.org/fedora for directions.
rpm http://archive.zfsonlinux.org/fedora/$releasever/$basearch
srpm http://archive.zfsonlinux.org/fedora/$releasever/SRPMS

RHEL/CentOS: See http://zfsonlinux.org/epel for directions.
rpm http://archive.zfsonlinux.org/epel/$releasever/$basearch
spms http://archive.zfsonlinux.org/epel/$releasever/SRPMS

In addition to the usual bug fixes the 0.6.1 release introduces a new
property called 'snapdev'. The 'snapdev' property was introduced to
control the visibility of zvol snapshot devices and may be set to
either 'visible' or 'hidden'. When set to 'hidden', which is the
default, zvol snapshot devices will not be created under /dev/.
To gain access to these devices the property must be set to 'visible'
This behavior is analogous to the existing 'snapdir' property.

Other significant changes include:
* Added Linux 3.9 compatibility
* Added snapdev property to control visibility of zvol snapshots.
* Disabled old on-disk format warning for `zpool status -x`.
* Enabled zfs_arc_memory_throttle_disable by default.
* Improved slab object reclaim behavior.
* Fixed disk cache flushing for 2.6.37 and newer kernels.
* Fixed hot spare functionality.
* Git - included in release for working builds.
* Updated dkms and kmod compliant packaging.
* Added man pages for splat, fsck.zfs, mount.zfs, zhack,
zinject, zpios, ztest, and zpool-features.

----------------------- SPL Change Log ---------------------------
Brian Behlendorf (16):
Fix atomic64_* autoconf checks
Disable automatic log dumping
Remove INSTALL
Fix spl_config.h install permissions
Add KMODDIR to install target
Remove custom install-data-local for headers
Remove ARCH packaging
Merge branch 'build-system'
Merge branch 'linux-3.9'
Change spl-kmod-devel install path
Refresh RPM packaging
Remove spl-dkms conflict with spl-kmod
Use requested kernel for dkms builds
Use 'git describe' for working builds
Provide ${kmodname}-devel-kmod for yum-builddep
Tag spl-0.6.1

Darik Horn (1):
Create splat man page

Ned Bass (1):
Refresh links to web site

Richard Yao (8):
Fix HAVE_MUTEX_OWNER_TASK_STRUCT autotools check on PPC64
Linux 3.9 compat: Include linux/sched/rt.h
Linux 3.9 compat: Do not depend on f_vfsmnt
Linux 3.9 compat: vfs_getattr takes two arguments
Linux 3.9 compat: set_fs_root takes const struct path *
Drop support for 3 argument version of set_fs_pwd
Linux 3.9 compat: Switch to hlist_for_each{,_rcu}
Do not call cond_resched() in spl_slab_reclaim()

----------------------- ZFS Change Log ---------------------------
Brian Behlendorf (35):
Add zpool-features(5) man page
Fix 1M references in zpool-features.5
Cast 'zfs bad bloc' to ULL for x86
Remove unused machelf.h header
Update the zfs.8 "ZFS Volumes as Swap" section
Add explicit MAXNAMELEN check
Fix broken RPATH in spec file
Enable zfs_arc_memory_throttle_disable by default
Leaf vdevs should not be reopened
Remove wholedisk check from vdev_disk_open()
Fix hot spares
Replace libexecdir with datadir
Fix zfs_config.h install permissions
Add KMODDIR to install target
Add --with-dracutdir configure option
Remove ARCH packaging
Retire ZFS.RELEASE file
Fix zdb.8 macro warning
Merge branch 'build-system'
Remove COPYING
Change zfs-kmod-devel install path
Configure --with-spl{-obj} auto-detect cleanup
Refresh RPM packaging
Add metaslab_debug option
Add zio_ddt_free()+ddt_phys_decref() error handling
Add spl-dkms dependency to zfs-dkms
Add missing dependencies
Refresh dracut module setup
Remove zfs-dkms conflict with zfs-kmod
Use BUILD_DEPENDS option for dkms builds
Use requested kernel for dkms builds
Use 'git describe' for working builds
Provide ${kmodname}-devel-kmod for yum-builddep
Include init scripts in packages
Tag zfs-0.6.1

Darik Horn (3):
Create mount.zfs, zinject, and zpios man pages.
Create fsck.zfs and zhack man pages.
Fix minor typos and update marketing copy.

Eric Dillmann (1):
Add snapdev=[hidden|visible] dataset property

Etienne Dechamps (2):
Use -Werror for all kernel configure tests.
Remove the bio_empty_barrier() check.

George Wilson (1):
Merge zvol.c changes from PSARC 2010/306 Read-only ZFS pools

Michael Gebetsroither (1):
Import ztest.1 man page.

Ned Bass (2):
Switch KM_SLEEP to KM_PUSHPAGE
Refresh links to web site

Richard Yao (5):
Fix function relocations in libzpool
Make spa.c assertions catch unsupported pre-feature flag pool versions
Eliminate runtime function pointer mods in autotools checks
Constify structures containing function pointers
Linux 3.9 compat: Undefine GCC_VERSION

Tim Connors (1):
-x shouldn't warn about old on-disk format or unavailable features

Hozzászólások

Phoronix benchmark itt a 0.6.0-rc9 verzióhoz. Érdekes hogy ahol Btrfs gyorsabb SSD-n, ott ugyanazzal a teszttel ZFS gyorsabb HDD-n. Gondolom, lehet hogy jobban optimalizálták a kódot sima HDD-re?

Csak feluletesen olvastam vmi levelet, es olyan remlik, h a zfs fejlesztok sem teljesen vagjak azt a tesztet (kompletten). Kozben pl. kiderult, hogy hibas volt a kod is es a zfs fals (gyorsabb) eredmenyeket produkalt, mert ott ahol azt mondta, h sync van, nem volt.

Remelem, a phoronix hamarosan ujra csinal egy tesztet es jobb lesz.

Masreszt amugy igen, a zfs-t nem optimalizaltak ssd-re. A TRIM implementalasa pl. folyamatban van, aki csinalta, az megvalt a munkaadojatol, akinek full time-ban ezen dolgozott es azota senki nem karolta fel a projektet, pedig az allitasa szerint mar nemsok hianyzik.
A btrfs-nek van ezen kivul ssd mount kapcsoloja is (a discard mellett), ami nem tudom, mit csinal, lehet hogy pont erre hajaz.

A zfs-nek van meg hova fejlodnie sebessegben. Na nem mintha a btrfs-nek nem.

tompos

Hat Ubi repo nincs?

Amugy eljutottunk mar odaig, hogy a kulonbozo ZFS portok "vegre" nem kompatibilisek egymassal? (Gondolok itt nyilvan az eredeti SUn/Oracle-fele solarisos, a freebsd-s, a FUSE-alapu es a nativ linuxos portra. Tudom, teszteljem magamnak.)

Kérdés hogy miért akarnánk hogy kompatibilis legyen pl. a Linux-on létrehozott az Oracle rendszeren lévővel? Nem találom gyakorlati problémának azonos FS felett a különböző oprendszerek cseréjét. Persze nem lenne baj ha úgy lenne, de ha már az új tulaj bezárta a kódot, azért jó hogy a meglévő már elérhető értéket tovább viszik. Főleg ha 8 éve él a projekt és az upstream régóta futtatja éles környezetben.

Valszeg jót tenne neki, ha Linux-on nagyobb figyelmet kapna. Mivel egy solaris porting layer az interface a kernel és a ZFS kód között, elképzelhetőnek tartanám hogy a FreeBSD-s verzió is nyerjen rajta meg fordítva.

BTW, szerintem van Ubi repo is: http://zfsonlinux.org oldalon Packages rész.

Azt írják, az összes ZFS fejlesztő kilépett az Oracle-től, és már az Illumosnak dolgoznak. Eszerint most már az Illumos tekinthető upstremnek, az peig továbra is nyitott.

A FreeBSD 9.1 release notes is ezt írja: "FreeBSD ZFS filesystem has been updated by merging improvements from illumos project.":

http://www.freebsd.org/releases/9.1R/relnotes.html

En szemely szerint ugy gondolom, hogy egyszer a UNIX vilag meglepte, hogy az egyseges UFS mindenkinel csak annyra volt mas, hogy egy Tru64-es UFS-t ne lehessen olvasni Solarison, meg egy BSD-set IRIX-en. Aztan gyakorlatilag ha jol tudom ugyanez tortent a Veritas-fele VxFS-sel, volt mindenkinek, de megsem lehetett olvasgatni keresztbe-kasul. Most mar igazan itt lene az ideje annak, hogy errol vegre elfelejtkezzenek, es igenis keresztbe-kasul kezelheo legyen. Ez ugyanis btang egyszeruve tenne egy migralast, egy backup-ot - de mindentol fuggetlenul leginkabb szerintem semmit nem nyernenek az inkompatibilitassal.