FYI, for NexentaStor we made sharesmb a "no-inherit" property.
(because most customers want "traverse mounts" in SMB,
meaning the SMB server exposes descendent file systems)
Note also that the most common situation (by far) for customer
configurations is that a shared ZFS dataset should show up i
Am 26.02.2019 um 06:42 schrieb George Wilson:
>
> A couple of months ago we discussed the issues surrounding zfs
> properties which have platform specific implementations. The example
> given was “sharenfs” which has platform-specific syntax and
> platform-specific implementations. Having platfor
On Tue, 26 Feb 2019 at 13:56, Garrett D'Amore wrote:
> I know that we (RackTop) are moving towards managing file system (dataset)
> mounts more manually.
That absolutely makes sense for an appliance where you have extremely
specific needs, and total control over the management of ZFS. In the
re
invent their own properties as needed.
This feels like a solution in search of a problem.
Garrett
From: Matthew Ahrens
Sent: Tuesday, February 26, 2019 1:27 PM
To: openzfs-developer
Subject: Re: [developer] Proposal: Platform-specific ZFS properties
To respond to a few of the points on this thread
To respond to a few of the points on this thread:
1. If we need finer granularity than Linux/illumos/FreeBSD/OSX/Windows
(e.g. distribution vs operating system), it seems like that would fit into
this proposal. E.g. Substitute distro for OS in the suffix. Are there
specific examples of ways that
> On Feb 26, 2019, at 11:14 AM, Garrett D'Amore wrote:
>
> The unmount prior to sharing is actually interesting… while it isn’t
> particularly cross-platform, its very analogous to the problems we had with
> dynamic reconfiguration, where we wanted to vacate I/O from an adapter prior
> to remo
us that are NAS vendors already
know how to manage this cleanly anyway.
Garrett
From: Richard Elling
Sent: Tuesday, February 26, 2019 10:34 AM
To: openzfs-developer
Subject: Re: [developer] Proposal: Platform-specific ZFS properties
On Feb 25, 2019, at 9:53 PM, Garrett D'Amore wrot
> On Feb 25, 2019, at 9:53 PM, Garrett D'Amore wrote:
>
> I suspect having the platform “resolve” which property to use is going to be
> problematic at the very best. The semantics are platform specific, and to
> make matters worse, I suspect that even on some platforms, you will find
> dis
On Tue, 26 Feb 2019 at 06:59, George Wilson wrote:
> On Mon, Feb 25, 2019 at 10:54 PM Garrett D'Amore wrote:
>> I suspect having the platform “resolve” which property to use is going to be
>> problematic at the very best. The semantics are platform specific, and to
>> make matters worse, I sus
ve attempts to convert, is
> probably the next best option.
>
>
>
> Garrett
>
>
>
> *From: *George Wilson
> *Sent: *Monday, February 25, 2019 9:43 PM
> *To: *openzfs-developer
> *Subject: *[developer] Proposal: Platform-specific ZFS properties
>
>
>
&
broad agreement about the property contents. Absent that,
namespace separation, *without* naïve attempts to convert, is probably the next
best option.
Garrett
From: George Wilson
Sent: Monday, February 25, 2019 9:43 PM
To: openzfs-developer
Subject: [developer] Proposal: Platform-specific ZFS
A couple of months ago we discussed the issues surrounding zfs properties
which have platform specific implementations. The example given was
“sharenfs” which has platform-specific syntax and platform-specific
implementations. Having platform-specific syntax for these types of
properties means that
12 matches
Mail list logo
