On 3/27/19 5:01 PM, Gregor Kopka wrote:
> I care, having it in the .c code makes is needlessly harder to modify as
> it would be incompatible with installing ZoL from the distributions
> repository.
While I agree that it is harder to modify something in the source than
in a configuration, file I d
>
> Thankfully, these can be solved in exactly the same way. When you create
the features=portable behavior, I will propose a features=grub
definition. I don't really care if this is in ZoL .c code, in a text
file, or in an Debian/Ubuntu patch.
I care, having it in the .c code makes is needlessl
On 3/27/19 2:13 PM, Rich wrote:
> Honestly, if nobody else writes it or convinces me otherwise, I'll
> probably take a stab at it in the next 7 days, as the actual
> implementation without configurability shouldn't require a lot of
> code. (...neither should permitting configurability, really, it's
On Wed, Mar 27, 2019 at 12:14 PM Rich wrote:
> Honestly, if nobody else writes it or convinces me otherwise, I'll
> probably take a stab at it in the next 7 days, as the actual
> implementation without configurability shouldn't require a lot of
> code. (...neither should permitting configurabilit
Honestly, if nobody else writes it or convinces me otherwise, I'll
probably take a stab at it in the next 7 days, as the actual
implementation without configurability shouldn't require a lot of
code. (...neither should permitting configurability, really, it's just
that AFAIK zpool doesn't currently
> On Mar 27, 2019, at 11:46 AM, Gregor Kopka
> wrote:
>
> I read the proposal as giving a ZFS admin the QoL to not having to dig
> through some feature compatibility matrix each time he wants to create a pool
> that should be importable on a set of other machines.
>
> I'm fine with that ge
I read the proposal as giving a ZFS admin the QoL to not having to dig through
some feature compatibility matrix each time he wants to create a pool that
should be importable on a set of other machines.
I'm fine with that general idea. I just see no point (and no benefit) in
hardcoding the val
> On Wed, Mar 27, 2019 at 1:17 PM Gregor Kopka
> wrote:
> >
> > @ahrens: Having an additional user-defined feature set list dosn't make
> > sense, it doubles the coding effort (having to check hardcoded and user
> > defined ones).
> > It would also open the question of who takes precedence: the
If the primary purpose is to enforce a consistent baseline of behavior
on all platforms, letting you override those baselines defeats the
point, because then you need to explicitly specify it all the time in
case someone decided they knew better.
Adding additional ones seems like a debatable trade
@ahrens: Having an *additional* user-defined feature set list dosn't make
sense, it doubles the coding effort (having to check hardcoded and user defined
ones).
It would also open the question of who takes precedence: the user ones (as I
would expect from OS software) or you enforcing your *hard
At yesterday's meeting we discussed:
- log spacemap review
- DRAID summit
- default pool features
- filesystem GUIDs.
Video recording available: https://www.youtube.com/watch?v=tVhf4ZxfB1Y
The next meeting will be April 23rd at 11AM Pacific time (2 hours earlier
than usual).
Detaile
11 matches
Mail list logo
