From: d <omnios@puptv.com>
To: Jorge Schrauwen via illumos-discuss <discuss@lists.illumos.org>
Subject: Re: [discuss] Illumos future and compatibility with Open-ZFS
Date: Sun, 8 Sep 2024 02:55:54 -0700 [thread overview]
Message-ID: <640324ae-25bb-4ae2-8596-1603e37d1a22@puptv.com> (raw)
In-Reply-To: <18FDA110-5626-4C27-95F9-F2B142DBEE1E@blackdot.be>
This post enticed me to do a little research on zfs compression, which
lead me to some interesting info an a question:
https://indico.fnal.gov/event/16264/contributions/36466/attachments/22610/28037/Zstd__LZ4.pdf
TLDR: A couple really interesting bits:
On their test data set, zstd-2 (4.8) beat out other compression ratios
soundly for performance with minimal difference in the compression ratio.
lz4-1 (145 MB/s) beat out lz4-9 (45 MB/s) on speed with no difference in
the compression ratio with their data set.
Question:
zfs was written to optimize usage largely for spinning rust.
What would be different in a version of zfs optimized for NVMe or SSDs?
How much can you tune zfs to optimize it for ssds?
Thanks
On 9/8/24 01:50, Jorge Schrauwen via illumos-discuss wrote:
> Since I am on mobile I’ll top post…
>
> Although some of the new features are indeed enticing, I value lack of dataloss and stability more.
>
> Once data has been lost, all trust is gone.
>
> Work is a linux shop and most of my colleagues don’t care for ZFS because they tried it and had all sorts of issues/loss of data. They rather use XFS or ext4. (They don’t care much for btrfs either for the same reason, and prefer LVM to fill the snapshot/zvol gap.)
>
> There is probably a fair share of users that chose illumos for those values that align closer with theirs.
>
> I’m sure illumos loses some of the ‘new’ users that try out illumos because of some of these choices of stability, don’t break master,… those users values may closer align with they way openzfs does things, and that is fine. They have the option to use it and seem to do so.
>
> Ultimately picking an OS is always a mix of features and values the project has.
>
> I think illumos is uniquely positioned here.
>
> ~ sjorge
>
>> On 7 Sep 2024, at 23:39, Gea <gea@napp-it.org> wrote:
>>
>> Thank you for bringing the discussion forward..
>>
>> Have your cake...
>> This is a term used by the Brits on Brexit in Europe.
>> While BS it basically says look for a way to get something new from controversial demands.
>>
>> As you say a project must have a focus on certain points be it stability or compatibility and yes stability has priority but in the end stability is nothing without compatibility when there are not enough users to justify the whole effort beside a single company use case. This is not different to the end of Sun that lost focus on users. Dying virtuously is not a serious option for any OSS project.
>>
>> From a user view, I do not see how the current Illumos follows Open-ZFS development or see that important new Open-ZFS features find their way to Illumos in time, so it cannot be more of the same.
>>
>> As I am not a Illumos dev this is my personal outside view. There may be other solutions from inside view.
>>
>> Gea
>>
>> gea@napp-it.org
>> -------------------------
>>
> ------------------------------------------
> illumos: illumos-discuss
> Permalink: https://illumos.topicbox.com/groups/discuss/T627f77e1b29a7b53-M69804f13feba105e940a7d98
> Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
next prev parent reply other threads:[~2024-09-08 9:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 20:50 shutdown hang with zpools on ISCSI devices Carsten Grzemba
2024-08-05 21:46 ` [discuss] " Joshua M. Clulow
2024-08-06 5:17 ` Carsten Grzemba
2024-08-06 5:29 ` Carsten Grzemba
2024-08-06 5:46 ` Joshua M. Clulow
2024-08-06 6:36 ` Carsten Grzemba
2024-08-06 6:46 ` Joshua M. Clulow
2024-08-06 14:27 ` Carsten Grzemba
2024-08-06 15:16 ` Carsten Grzemba
2024-08-06 19:04 ` Joshua M. Clulow
2024-09-06 11:53 ` Illumos future and compatibility with Open-ZFS gea
2024-09-07 8:30 ` [discuss] " Joshua M. Clulow
2024-09-07 11:12 ` Gea
2024-09-07 16:38 ` Joshua M. Clulow
2024-09-07 21:37 ` Gea
2024-09-08 8:50 ` Jorge Schrauwen
2024-09-08 9:55 ` d [this message]
2024-09-09 10:41 ` Gea
2024-09-09 11:32 ` Toomas Soome
2024-09-09 9:29 ` Volker A. Brandt
2024-09-09 9:49 ` bronkoo
2024-09-09 11:13 ` Jorgen Lundman
2024-09-09 12:27 ` Gea
2024-09-09 14:47 ` gea
2024-09-09 19:29 ` Joshua M. Clulow
2024-12-11 8:47 ` zt958bjm via illumos-discuss
2024-12-11 8:56 ` zt958bjm via illumos-discuss
2024-12-11 9:01 ` zt958bjm via illumos-discuss
2024-12-11 10:09 ` Jorgen Lundman
2024-12-11 12:17 ` zt958bjm via illumos-discuss
2024-09-07 14:32 ` Miles Nordin
2024-08-05 22:45 ` [discuss] shutdown hang with zpools on ISCSI devices John D Groenveld
2024-08-05 22:55 ` Joshua M. Clulow
2024-08-06 15:56 ` Gordon Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=640324ae-25bb-4ae2-8596-1603e37d1a22@puptv.com \
--to=omnios@puptv.com \
--cc=discuss@lists.illumos.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).