illumos gate

The following document further specifies exactly what Jakob is pointing out (and I vote should be supported for continuity, functionality, and general up-keep):

[[http://docs.oracle.com/cd/E19963-01/html/821-1448/gbchx.html]]

zfs receive x foo -o bar=on snafu/snap.1 < good

zfs receive x foo -x bar -o foo=on snafu/snap.1 < bad

Jakob Borg wrote:

It's very useful to prevent certain properties from being received when doing a `zfs receive`. In Oracle Solaris, this is implemented with the `-x` switch to `zfs receive`:

-x property

Ensures that the effective value of the specified
property after the receive is unaffected by the
value of that property in the send stream (if any),
as if the property had been excluded from the send
stream. If the specified property is not present in
the send stream, this option does nothing. If a
received property needs to be overridden, the effec-
tive value can be set or inherited, depending on the
property. In the case of an incremental update, x
leaves any existing local setting or explicit inher
itance unchanged (since the received property is
already overridden). All -o restrictions apply
equally to -x.

The "-o restrictions" mentioned are:

Set-once properties bound to the
received data, such as normalization and casesensi-
tivity, cannot be set at receive time even when the
datasets are newly created by zfs receive. Multiple
-o options can be specified. An error results if the
same property is specified in multiple -o or -x
options.

We came across the requirement for this feature when trying to restore a backup of a disk which had had the recordsize changed on the root FS and who's child FS's had refquota's. The result being the receive would fail with a quota error due to the change in compression factore.

I've implemented this feature against the FreeBSD src to fix our issue, so the code may well be of interest.

It takes the the -x and -o options a little further allowing global -x <property>, -o <property>=<value> as well as dataset specific -x <property><volume|filesystem>, -o <property><volume|filesystem>=<value> to be passed.

In addition it also adds a -l option which allows the datasets that are actually received from the stream to be limited facilitating the ability to restore one or more volumes / filesystems from a multi dataset stream.

The latest version of the patch can be found here:-
http://blog.multiplay.co.uk/dropzone/freebsd/zfs-recv-properties.patch

Feedback on the patch would be most appreciated.

We came across the requirement for this feature when trying to restore a backup of a disk which had had the recordsize changed on the root FS and who's child FS's had refquota's. The result being the receive would fail with a quota error due to the change in compression factore.

I've implemented this feature against the FreeBSD 8.3-RELEASE source to fix our issue, so the code may well be of interest.

It takes the the -x and -o options a little further allowing global -x <property>, -o <property>=<value> as well as dataset specific -x <property><volume|filesystem>, -o <property><volume|filesystem>=<value> to be passed.

In addition it also adds a -l option which allows the datasets that are actually received from the stream to be limited facilitating the ability to restore one or more volumes / filesystems from a multi dataset stream.

The latest version of the patch can be found here:-
http://blog.multiplay.co.uk/dropzone/freebsd/zfs-recv-properties.patch

Feedback on the patch would be most appreciated.

Oops sorry about the dual post seems, there's no edit or delete for notes :(

Patch updated

Hi Steven,
sorry i'm not an official illumos guy. but I'm interested in seeing your stuff integrated.

Here's something of interest from the "zfs" illumos mailing list:

****
The way it works is:

	

	
Mail patch/webrev/whatever to developer@lists.illumos.org.
	


	

	
Get 1-N reviews, depending on how complex the change is.  This is where most of the work is done.
	


	

	
After 1-N satisfied reviewers, mail advocates@lists.illumos.org (Cc:ing the reviewers if they aren't advocates themselves) requesting push/pull/whatever.
	


	

	
It goes back. [ into the main src tree? -- phil]
	

Is this patch being kept up to date?

Was there any RTI or did it hit the developer mailing list for review?

It would be great to see this integrated!

Tobias Oetiker wrote:

It would be great to see this integrated!

i'll take a look it

As reported by Zender Fufikoff on Illumos ZFS mailing list. This has been done on ZoL and FreeBSD and ported to Nexenta.

From more than 3 years ago:
https://github.com/zfsonlinux/zfs/commit/80617ec9b86061b5be1736913e888f6cf313af0a

From more than 2 years ago:

https://github.com/Nexenta/illumos-nexenta/commit/21eaf38dbf37deaf21b7d044b8ea5fb699fcff38#diff-6be825898f47810e1d625eb31bc41a32

We could really use this in mainstream Illumos. Working around it is a pain and problematic.

Hi,

Is the src code of what has been ported to nexenta available so that it just needs to be compiled to work under let's say omnios? I really think i need this feature to be able to do zfs send/recv between a nexenta and a non nexenta illumos system as by doing so our nexenta system crashes and only a reboot helps. This is really a pain and since nexenta doesn't officially support zfs replication to a non nexenta system I'm kind of stuck. I'm really happy to test this feature but I'm no programmer so I can't implement this feature myself.

Best regards,

Oliver

Would anyone be interested in being sponsored/paid to integrate this patch into Illumos? It's pretty nuts that it is in FreeBSD, ZoL, Nexenta, but not illumos-proper.

We require it for our backups, due to for example, conflicting mountpoints, or quotas being exceeded.