enable compression by default on new pools

[mailinglists35]

System information

Type	Version/Name
Distribution Name	all
Distribution Version	all
Linux Kernel	all
Architecture	all
ZFS Version	all
SPL Version	all

Describe the problem you're observing

zpool creates new pool with zfs compression set to off.
can this be made default to on?

Describe how to reproduce the problem

[user@zfs ~]$ truncate -s 1G /tmp/delete
[user@zfs ~]$ sudo losetup -f /tmp/delete
[user@zfs ~]$ sudo zpool create test /dev/loop0
[user@zfs ~]$ zpool get feature@lz4_compress test
NAME  PROPERTY              VALUE                 SOURCE
test  feature@lz4_compress  active                local
[user@zfs ~]$ zfs get compression test
NAME  PROPERTY     VALUE     SOURCE
test  compression  off       default

Include any warning/errors/backtraces from the system logs

[mailinglists35]

also, from http://open-zfs.org/wiki/Performance_tuning#General_recommendations

"Set compression=lz4 on your pools' root datasets so that all datasets inherit it unless you have a reason not to enable it"

is there a strong reason to not enable it by default?

[DeHackEd]

Defaults should be sane and consistent from a user standpoint. compression=off is most consistent with other filesystems, produces expected results with regard to applications like du and df, and users' initial expectations of space usage will be met.

[Lady-Galadriel]

Perhaps we can handle this a different way. Create a user editable configuration file that would be used for defaults. ZFS on Linux seems to have one already, (at least on Gentoo Linux);

> cat /etc/default/zfs
ZFS_MOUNT='yes'

Then if someone is deploying servers with ZFS, they include the appropriately modified default file. For @mailinglists35 issue, perhaps something like this;

ZPOOL_COMPRESSION="lz4"

which would be applied on any pool creation. Then inherited down the dataset / zvol tree.

However, I do agree leaving the current default of compression off is best for now. And this idea can be discussed elsewhere, (like the mailing list).

[mailinglists35]

that idea would be awesome and would solve another issue, the default mountpoint on root filesystem tree instead of naturally going into /srv on linux

[mailinglists35]

@Lady-Galadriel I can't easily search for "defaults" as there are too many results, do you happen to know if is there already filed some issue to provide defaults in a /etc/default/zfs file (in the upstream package, not added by distro)? this and the other issue I mentioned should then be solved.

[Lady-Galadriel]

@mailinglists35, no I don't know if this defaults file concept has been filed as a feature request / issue.

It should probably be followed up in the mailing lists. And / or reported as a separate issue.

As for your default mountpoint for a pool, I thought it was based on the pool name. Thus, a pool named "srv" would mount by default on "/srv". I routinely disable my pool's automounting, as it's never correct. So;

zpool create -O mountpoint=legacy POOL DEVICE

[GregorKopka]

Other candidates for updated defaults could be xattr=sa and normalization=formD as these two seem to be a 'you definitively want this' in most of the howtos for pool creation that float around.

Thus a generic way to specify -o and -O options in a default file that are applied on zpool create would be helpful.

Ceterum censeo regarding the argument about consistency with other filesystems and users initial expectations we should do something about zpool FREE being a red herring.

[DeHackEd]

... normalization=formD as these two seem to be a 'you definitively want this' in most of the howtos for pool creation that float around.

Objection, that implies utf8only=on which not everybody wants.

[mailinglists35]

Can we repurpose this issue as a feature request for a global zfs/zpool preferences file?

Like the one ubuntu already provides, but with added abilites (1) to specify zpool create -o -O flags and (2) with ability to tell the root prefix mountpoint (instead of default /)

[richardelling]

there is some precedent for defaults already, where the "default config file" is /etc/modprobe.d/zfs.conf

see https://github.com/zfsonlinux/zfs/wiki/ZFS-on-Linux-Module-Parameters#spa_config_path

[Lady-Galadriel]

Thinking about this more, it maybe should be 2 / 3 configuration files. Or a way to specify the difference between options for zpool, zfs and Zvols. Meaning the current requests could be met with;

/etc/default/zpool
compression="lz4"
mountpoint=/srv/$POOL

And in some cases, I can see Zvols wanting this as the default;

/etc/default/zvol
volblocksize=8k

Basically anything related to the pool or top level dataset would be in the "zpool" defaults file, applied at pool creation. And the "/etc/default/zfs" file would apply to all other datasets on "zfs create". And perhaps allowing a separate "zvol" defaults would be useful.

I'd also suggest allowing some variables to be allowed in the default configuration files;

$POOL
$DATASET
$ZVOL
$HOSTNAME
$DATE
$TIME

The last 3 could be useful for Zpool comments, like "Pool made for HOSTNAME on DATE". (Zpool comments on exported pools are available using zpool import...)

[gmelikov]

It would be great if we can set any default value via some config file (if we're already speaking about this functionality for compression). What do you think about it?

[stephenmclan]

ZFS is slowly becoming "the systemd" of filesystems and it is because of feature requests like this (and #6836, #6041, #4134)

Is it too hard to type "-O compression=lz4" once in a blue moon? No, it is not.

Does your job require typing "zpool create" all day long? You can script it with something that fits your needs.

Once again we see a great product of engineering being pushed around by the some members of its community. I can't wait to see ZFS/systemd integration via D-Bus /s.

[mailinglists35]

Is it too hard to type "-O compression=lz4" once in a blue moon?

yes

[richardelling]

IMNSHO, pool creation should be automated, like everything else you do more than once. When developing such automation, understanding where and why someone else changes the defaults is toil.

[halfa]

For me compression is a feature, and as such should be leaved off by default even if the recommended setup is to have it on. As said before, compressing data by default is not so common among filesystems and certainly unexpected. Sane defaults often are not the same than recommended setup for a use-case, as generic as it could be. I'd also arg that ZoL would then diverge from the other zfs implementations, which -as far as I know- retain mostly the same settings.

As for the default setting file, only root can create/mount filesystems, so why not put a cmd alias somewhere in /root/.*rc?

[ahrens]

@kpande Sure, can you also bring it up on the [email protected] mailing list so that folks from all platforms have a chance to weigh in on this before the meeting?

[ahrens]

Let's have this issue be specific to the having compression on out-of-the-box, with no additional work. It sounds like some folks would also like to be able to have a settings file that (essentially) provides some default arguments whenever you run "zpool create". If that's still desired, please open a separate Issue (feature request) for that.

[alek-p]

seems like all of the negative aspects of having compression=on by default (CPU wasting cycles) could be avoided if we also port this Nexenta/illumos-nexenta@1e096bb604 along with switching the default to on

[ahrens]

This was discussed at today's OpenZFS Leadership Meeting. Here are the relevant notes:

The idea is to give a better out of the box experience. The downsides are: potential CPU cost (and write performance due to compressing) and new users misunderstanding how the space is used in certain cases.
Igor: There have been issues when root pools are expecting compression to be disabled (on SPARC?)
Allan: This has been the default in FreeBSD installer for ~2 years
Sef: Boot pools need to be different for each platform, but grub doesn’t seem like it needs to be different. Sef supports it being the default.
Compression=on has been the default in FreeNAS for several years; no complaints
*** Someone to take an action item to investigate benefits and issues, and write it up?

https://www.youtube.com/watch?v=dIVGGJaZ7zk&feature=youtu.be