OpenZFS 2.0

Megjelent az OpenZFS fájlrendszer 2.0-s verziója. Újdonságok, tudnivalók, támogatott platfomok stb.:

Supported Platforms

  • Unified code base and documentation - The ZFS on Linux project has been renamed OpenZFS! Both Linux and FreeBSD are now supported from the same repository making all of the OpenZFS features available on both platforms. #8987

    • Linux: compatible with 3.10 - 5.9 kernels
    • FreeBSD: Release 12.2, stable/12, 13.0 (HEAD)

Major New Features

  • Sequential resilver - The sequential resilver feature can rebuild a failed mirror vdev in a fraction of the time it would take a traditional healing resilver. Full redundancy is restored as quickly as possible and then the pool is automatically scrubbed to verify all of the data checksums. #10349

  • Persistent L2ARC - This feature makes the L2ARC cache device persistent across reboots thereby eliminating the usual cache warmup time normally needed after importing your pool. #9582

  • ZStandard compression - ZStandard is a modern, high performance, general compression algorithm which provides similar or better compression levels to GZIP, but with much better performance. ZStandard provides a large selection of compression levels to allow a storage administrator to select the preferred performance/compression trade-off. #10278

  • Redacted zfs send/receive - Redacted streams allow users to send subsets of their data to a target system. This allows users to save space by not replicating unimportant data within a given dataset or to selectively exclude sensitive information. #7958

Changes to the zpool/zfs Commands

  • zpool replace|attach -s - Perform a sequential resilver when replacing or attaching a new vdev. #10349

  • zfs wait, zpool wait - Wait for long running background operations to complete (resilver, scrub, trim, etc). #9707 #9162

  • zfs redact, zfs send --redact - Generate a redacted send stream. #7958

  • zfs send --saved - Allows a user to send a partially received dataset. #9007

  • zfs jail, zfs unjail - Attaches and detaches ZFS filesystems from FreeBSD jails. #10658

  • zfs rename -u - Renames a filesystem without needing to remount. #10839

  • zfs umount -u - Unloads keys for an encrypted filesystem when it is unmounted. #8952

  • zfs bookmark fs#target fs#newbookmark - Copying an existing bookmark to a new name. #9571

Notable Changes

  • Added fallocate(mode-0/2) compatibility to preallocate space. #10408

  • Reorganized the zfs and zpool man pages by splitting out each subcommand in to its own page. #9559 #9564

  • Enabled the systemd zfs-mount-generator by default on Linux. #7329 #8848

  • More relevant and useful ZED syslog entries #10967 #10861

  • Provided pam module for automatically loading zfs encryption keys for home datasets. #9903

  • Support for inheriting and setting user properties in channel programs. #9738 #9950

  • Improved bootloader support. #10009 #8627 #10937

  • Optionally colorized zpool status output. #9340

Performance

Deprecated functionality

  • Deduplicated send streams have been deprecated. The zfs send -D command will now print a warning, ignore the -D flag, and generate a regular (non-deduplicated) send stream. A zfs receive of a deduplicated send stream will print an error message and fail. Legacy deduplicated send streams can be received by first converting them to a non-deduplicated stream with the zstream redup command. #10117 #10156

  • The dedupditto pool property has been deprecated. It may still be set with zpool set dedupditto but won't have any effect. OpenZFS is still compatible with existing pools that have the dedupditto property enabled and can understand dedupditto blocks and free them when appropriate. However, OpenZFS won't write any new dedupditto blocks. #8310

  • The zfs_vdev_scheduler module option can still be set but will have no effect. Linux users who require this functionality should update their systems to set the disk scheduler using a udev rule. #9609

Additional Information

  • Documentation - Updated OpenZFS documentation for Linux and FreeBSD.

  • Change log - Complete v0.8.0 - v2.0.0 change log

  • Module options - The default values for the module options were selected to yield good performance for the majority of workloads and configurations. They should not need to be tuned for most systems but are available for performance analysis and tuning. See the module parameters documentation for the complete list of the options and what they control.

Hozzászólások

Elvesztettem a fonalat, akkor most akkor járok jobban ha FreeBSD-re építve használom a zfs-t és ott lesz több lehetőségem és új featúráim :) , vagy ha egy solaris-t dobok fel?

Hááát. Nem estem le a székről. És ezért 2.0-ra emelni a verziót????

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Ez IS az akadálya. Meg az indokolatlanul nagy memóriahasználat. Ígéretekkel tele van a padlás itt is. De végülis igazuk van. Verziószámot növelni egyszerűbb. Pedig reménykedtem benne, hogy a kódegyesítés jót tesz majd neki.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Mert a mai tudásával annyival nem jobb választás egy házi szerveren/nason, mint amennyivel több ramot kér a szép futáshoz. (2-4GiB)

(Teszem hozzá, enterspájz környezetben sem mindig a legjobb választás. Szóval sem itt sem ott nem tökéletes.)

Csak akkor szólok hozzá egy témához, ha értelmét látom.

1 GB RAM-al, 2x500 GB-os vinyóval tükörben, egy leselejtezett ThinkCentre gépen csináltam FreeNAS fájlszervert ZFS-el. Nincs rajta nagy forgalom, kb. 5-6 ember használja. Tökéletesen teszi a dolgát kb. 4 éve. Szóval, nem "kell" neki sok RAM. Ha adsz neki, akkor meg használja. Nemrég adtam neki 2x4 GB-ot, nem vettem észre különbséget.

Ahha. Hát én desktopon próbáltam. Mondjuk a tükrözés nem nagy bűvészmutatvány. Azt tudja még az lvm is nagyon régóta. Talán még gyorsabban is.

Próbáld ki 3 disk raid5-ben fájlintenzív környezetben!

Mindegy. Ha sokáig tart a lezárás, akkor lehet kitesztelem különböző felállásokkal. Mostmár kíváncsivá tettél.

Csak akkor szólok hozzá egy témához, ha értelmét látom.

Nem értem, hogy a közössé tett kódbázis miért nem érne meg egy főverzió ugrást? Nem elég nagy változás két projekt életében, hogy eggyé válik? Ha ez nem, akkor mi? Akár új nevet is adhattok volna neki...

Meg azt sem értem, hogy miért gondoljátok, hogy a kódegyesítés közben (amikor az a cél, hogy az addigi képesség közös kódbázisra helyezés után is tökéletesen működjön az érintett rendszereken) majd jól belefejlesztenek alapokat érintő új funkciókat meg fícsöröket...

Most, hogy közös a kódbázis és kigyomlálták belőle a kódegyesítés gyerekbetegségeit, jöhet az érdemi _tovább_ fejlesztés. Szerintem.