You know, if you'd mentioned this two weeks ago, experimenting with it
might have made it into a slide of my talk...
- Rich
On Tue, Oct 18, 2022 at 11:57 AM Adam Moss wrote:
> In the spirit of the OP and getting expensive things onto the GPU...
> https://developer.nvidia.com/nvcomp
I believe the Intel QAT support we have will happily offload gzip for you,
though I don't know if it makes any promises about what level equivalent of
gzip it hands you back...
- Rich
On Mon, Oct 17, 2022 at 12:02 PM Garrett D'Amore wrote:
> That’s about what I would have expecte
results on
different OSes annoyed me.
- Rich
On Mon, Apr 11, 2022 at 6:21 PM René J.V. Bertin
wrote:
> On Sunday April 10 2022 18:52:07 Matthew Ahrens via openzfs-developer
> wrote:
> >gzip update
> >Kidding…
> >…but I really did experiment with it.
> >Tried
is outside of trying to
reproduce other people's issues, but additional people have been
trickling into the issue tracker in either that bug or new bugs about
this.
I've got a load of debugging information and rabbit holes gone down I
can share if anyone is interested.
Thanks!
- Rich
arts, and I'm not entirely sure where to look
for "space zdb doesn't seem to count, but gets freed correctly".
(This also works with similar overhead on sparse zvols, so it doesn't
seem to be specific to files?)
Thanks to whoever has any insight,
- Rich
--
K zpool doesn't currently have much of any sort of runtime
config parsing, just argument parsing).
The only open implementation question, for me, was how people intended
to persist the notion of last-used value of -o features=abcd, but if
it's an actual pool property that follows readily.
- Rich
tradeoff of value
(though I agree that if you need to have the config for an -o
features=custom123 in order to import the pool, Something Is Very
Wrong With The Design), but overriding the builtins makes this
valueless for people trying to produce consistent results on different
systems.
- Rich
On Wed
I think we're agreeing loudly - as I said, I have concerns about the
implications of allowing it to be configurable, but if we did, we
should probably blacklist overriding any hardcoded defines.
Not allowing that also resolves that problem.
- Rich
On Mon, Mar 25, 2019 at 10:08 PM Josh Pa
I'm not usually in favor of limiting configurability, but in this
case, I agree with Joshua - letting people add their own custom
defines for e.g. debian-buster or epel6 or ubuntu1604 might be fine
(though at that point I'd still like something like a constraint
solver to say "I want this to work o
First, let me say I'm so pleased someone actually drove this forward,
thank you. :)
I think my only lament about this would be the lack of zpool create
defaults, but that's a conversation for once everyone is confident
this doesn't cook your pool somehow.
- Rich
On Mon, Mar 25,
On Thu, Dec 6, 2018 at 11:20 AM Josh Paetzel wrote:
>
>
>
> On Thu, Dec 6, 2018, at 12:23 AM, Rich via openzfs-developer wrote:
> > On Thu, Dec 6, 2018 at 12:19 AM Josh Paetzel wrote:
> > >
> > > There was a proposal on this mailing list a week or so ago that
e with you as masochists conveys more about
the beliefs and intent than the entire rest of this message.
Please don't claim you want a discussion when you open it with a
proposal that solves neither of the two problems the original was
written to address, and include active mocking of those who
On Mon, Dec 3, 2018 at 12:24 PM Matthew Ahrens wrote:
>
> On Fri, Nov 30, 2018 at 3:41 PM Rich via openzfs-developer
> wrote:
>>
>> Hi all,
>> So, I spent a little bit pondering the idea from here [1] of a zpool
>> compat flag to allow people to minimize foot-
On Sat, Dec 1, 2018 at 12:00 AM Josh Paetzel wrote:
>
>
>
>
>
> > On Nov 30, 2018, at 5:40 PM, Rich via openzfs-developer
> > wrote:
> >
> > Hi all,
> > So, I spent a little bit pondering the idea from here [1] of a zpool
> > compat flag to
want that information can still get it, while not handing
unfamiliar users a sharp tool and suggesting they juggle it.
Anyway, as I said, comments/criticisms welcomed, but please warn me
before gratuitous flaming, I need to go invest in asbestos
undergarments before you do that. :)
(Meant to include https://zgrep.org/zfs.html as my citation there but
forgot I hadn't put it in yet. Whoops.)
On Wed, Nov 28, 2018 at 10:36 AM Rich wrote:
>
> The obvious pain points from my perspective would be the feature flag
> disparities between platforms, and how they bite
n uncommon event for most, but IMO the default
behavior should not be to end up with a pool no other platform can
import.)
But that's just me having had to explain to many people why their pool
wouldn't import elsewhere when a bug on one platform bit them and they
wanted to try another.
e need for L2ARC in a number of situations has gone
down, it's hardly limited to the "highly budget oriented plays."
- Rich
On Thu, Aug 23, 2018 at 8:42 PM, Jason Matthews wrote:
>
> Maybe I am doing it wrong but I am using NVMe for primary storage and ass
> tons of
@avg-I I would presume it's either
https://github.com/ahrens/dtrace/blob/master/txg.xd or some later iteration
thereof.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/616#issuecommen
t import as untrusted.
So changing between an unfixed and fixed system would result in you
treating all the txgs before the most recent fixed system import as
potentially buggy, rather than maintaining a range list.
- Rich
---
openzfs-developer
Archives: http
m not sure there's a nicer solution than
either that or defaulting to discarding hole_birth metadata without an
explicit flag to zfs send like -e or -L.
If anyone has any nicer suggestions, or thoughts on how to better handle
this recurring problem, I'd love to have a better answer to th
21 matches
Mail list logo
