On 14.10.22 16:51, Thijs Cramer wrote:
I've been searching the GitHub Repository and the Mailing list, but
couldn't find any discussion about this.
I know it's probably silly, but I would like to understand the workings.
Let's say one could offload the Checksumming process to a dedicated
GP
On Wednesday, 24 April 2019, at 3:18 PM, Ayan George wrote:
> I think you intentionally misinterpret the intention of the code of conduct.
Slight exaggeration used to illustrate the point to be made.
>>> intentionally
>> only one person in the world, at maximum, can know that information
> Not tr
> “Avoid
humor that is personal in nature,
all humor is a matter of personal preference
> mean-spirited
in the eye of the beholder
> and
discourteous to others,
a matter of taste
> demonstrating bullying intent.
depending on how snowflake one feels this can be 'Hel
> I really don’t see why you think the file would be regularly edited by
> someone who isn’t a distro or ZFS developer.
I see a use case to do this, thus at least I would want to edit the file. As of
> Grub: We discussed this before, and we decided it was too hard and we were
> going to defer the
With it being a configuration file you're done with
zfs; (not even having to do the second step for
modifications made to prior to the update as
usually offers to merge existing changes into the new version
being installed).
Having it in the .c code leads to having to fetch/patch/compile/
>
> 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
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
@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
> It seems fine, perhaps, to allow __additional__ feature sets this way, but I
> think the "portable" family really needs to be something compiled in. The
> core value proposition is that "zpool create -o features=portable-2016" is
> the same __everywhere__, and allowing it to be easily overrid
Looks good.
Only thing: *please* make this feature lookup the features for a set *from a
plain text file* (like in /etc/zfs/), just containing
features_name = comma, separated, list, of, feature, names
and *not* something compiled in.
It should be easy to define custom feature sets, this would
A little late to the party, but:
Given the goals are to give an easy way to create a pool that is compatible
with a desired range of other systems (and tools like GRUB) in a way that is
both interoperable between the different distributions / platforms, easy to
automate and simple to remember..
Am 08.09.2016 um 19:21 schrieb Joshua M. Clulow:
> On 8 September 2016 at 00:25, Gregor Kopka
> wrote:
>> Tying that option name change to a system tuneable
>> (zfs.rollback-recursive-syntax) which can be used to walk through the
>> steps of the proposal
>> (as-is|de
Am 08.09.2016 um 00:26 schrieb Matthew Ahrens:
> On Wed, Sep 7, 2016 at 12:05 PM, Joshua M. Clulow wrote:
>> On 7 September 2016 at 11:45, Gregor Kopka
>> wrote:
>>> 1. Introduce two new option aliases that are functional identical to -r
>>> and -R on the ro
Hello,
The zfs rollback command breaks the expectation of the user about -r
since it does not work recursively on the children as this option does
everywhere else. Also rolback is the only command dealing with snapshots
where there is no way to recursively apply it to the children of the
specified
I think the group in 4 is quite huge since the bug has the potential to
already having hit everyone using filesystems with compression!=off (in
case I got it correctly) - and I wouldn't count on everyone of them
having knowledge of the problem.
Since the effect will only manifest when sending, ign
15 matches
Mail list logo
