On 1 July 2020 20:24:37 CEST, Matthew Miller wrote:
>On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
>> could be good option. I know technically it is already opt-in, but it's not
>>
On Wed, Jul 01, 2020 at 08:48:57AM -0400, Stephen John Smoogen wrote:
> > We have https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
> > maybe this could be used to collect some statistics about the fs type
> > too.
> I am going to try and nix this one in the bud right here. DNF counting
On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
> could be good option. I know technically it is already opt-in, but it's not
> very visible or popular. We could make the btrfs option more
On Wed, Jul 1, 2020 at 5:49 AM Steven Whitehouse wrote:
>
> If the / and /home split is the main issue, then dm-thin might be an
> alternative solution, and we should check to see if some of the issues
> listed on the change page have been addressed. I'm copying in Jon for
> additional comment on
On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel
wrote:
Actually this split is a godsend because you can convince anaconda to
leave your home alone when reinstalling, while someone always seems
too
invent a new Fedora change that justifies the reformatting of /.
Good luck dealing
Le mercredi 01 juillet 2020 à 10:27 -0400, Neal Gompa a écrit :
> On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel
> wrote:
> >
> > Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-
> > Szmek
> > a écrit :
> > >
> > > Actually that part has been answered pretty
On Wed, Jul 01, 2020 at 04:25:31PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
> a écrit :
> >
> > Actually that part has been answered pretty comprehensively. The
> > split between / and /home is hurting users
>
> Actually
On Wed, Jul 1, 2020 at 10:26 AM Nicolas Mailhot via devel
wrote:
>
> Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
> a écrit :
> >
> > Actually that part has been answered pretty comprehensively. The
> > split between / and /home is hurting users
>
> Actually this split
On 7/1/20 7:49 AM, Steven Whitehouse wrote:
Hi,
On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
Hi,
On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy
Le mercredi 01 juillet 2020 à 11:09 +, Zbigniew Jędrzejewski-Szmek
a écrit :
>
> Actually that part has been answered pretty comprehensively. The
> split between / and /home is hurting users
Actually this split is a godsend because you can convince anaconda to
leave your home alone when
On Wed, Jul 1, 2020 at 7:54 AM Stephen Gallagher wrote:
>
> On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro
> wrote:
> >
> >
> > On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen
> > wrote:
> > > The issue isn't that you haven't done your work. It is that it looks
> > > like you were set
On Sun, Jun 28, 2020 at 7:54 PM Gerald B. Cox wrote:
> And? I don't know about you, when dealing with file systems a chart with OK,
> Mostly OK and Unstable doesn't give me the warm and fuzzies. Especially when
> OK is defined as: "should be safe to use, no known major defficiencies" .
>
On Wed, Jul 1, 2020 at 8:55 AM Stephen Gallagher wrote:
>
> On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro
> wrote:
> >
> >
> > On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen
> > wrote:
> > > The issue isn't that you haven't done your work. It is that it looks
> > > like you were set
On Tue, Jun 30, 2020 at 9:03 PM Michael Catanzaro wrote:
>
>
> On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen
> wrote:
> > The issue isn't that you haven't done your work. It is that it looks
> > like you were set up to fail. The email from Michael comes across that
> > Workstation
On Wed, 1 Jul 2020 at 07:19, Zbigniew Jędrzejewski-Szmek
wrote:
>
> Yeah. I have no doubt that the decision was made carefully back then.
> That said, time has passed, and btrfs has evolved and our use cases
> have evolved too, so a fresh look is good.
>
> We have
Hi,
On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
Hi,
On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
So yes, I think an explicit "let's all
On Sat, 2020-06-27 at 18:41 -0600, Chris Murphy wrote:
> On Sat, Jun 27, 2020 at 4:30 PM Konstantin Kharlamov
>
> > Good for you. But you're trying take take decision for all other peoples, so
> > you
> > need to take into account not everyone has NVMe or SSD. HDDs that many
> > people
> > are
On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
> Hi,
>
> On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
> >>So yes, I think an explicit "let's all test btrfs (as anaconda
> >>configures it) before we
Hi,
On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
So yes, I think an explicit "let's all test btrfs (as anaconda
configures it) before we make it default" period is warranted.
Perhaps one can argue that Fedora has
While this isn't a problem for Fedora per se, it's worth noting.
OpenSUSE uses btrfs by default and as a result we're unable to open
SUSE guest images from distros that don't include btrfs in the kernel
(ie. RHEL, and maybe CentOS unless you use an alternate kernel). So
that would apply to
On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
> So yes, I think an explicit "let's all test btrfs (as anaconda
> configures it) before we make it default" period is warranted.
>
> Perhaps one can argue that Fedora has already been doing that for the
> past two years (since
Stratis allows users to manage XFS filesystems using a pool of block devices.
Features include: thin-provisioning, snapshots, and encryption
Stratis does come under the Springfield umbrella. We are an active team and
happy to respond to our public mailing list, if anyone has questions at
On Sun, Jun 28, 2020 at 6:21 AM Antti wrote:
>
> Hello,
>
> I'm in total opposition to this proposal as a long-time Fedora user. The
> btrfs is unstable and not ready for production. Most of what I'm about to
> write is admittedly anecdotal but it's the only file system in Linux which
> has
On Tue, Jun 30, 2020 at 7:16 pm, Stephen John Smoogen
wrote:
The issue isn't that you haven't done your work. It is that it looks
like you were set up to fail. The email from Michael comes across that
Workstation couldn't make a decision and told you to go see if FESCO
would approve it... but
On Tue, 30 Jun 2020 at 17:09, Neal Gompa wrote:
>
> On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote:
> >
> > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr
> > wrote:
> > >
> > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > > > On Tue, 30 Jun 2020 at 11:09,
On Mon, Jun 29, 2020, at 6:57 PM, Markus Larsson wrote:
> On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
> > On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
> > > Why not Stratis?
> >
> > Stratis cannot be used to build the root filesystem. (It's been
> > answered elsewhere in the
- Original Message -
> From: "James Cassell"
> To: "Fedora Development List"
> Sent: Tuesday, June 30, 2020 6:08:30 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
> file system for desktop variants
>
>
On Tue, Jun 30, 2020, at 10:18 AM, Steven Whitehouse wrote:
> I know it has been rather confined to Red Hat internally, however that
> was not the intention, and in fact I would like to strongly encourage
> community involvement. There is an upstream mailing list, which
> currently has almost
On Tue, Jun 30, 2020 at 4:29 PM Neal Gompa wrote:
>
> On Tue, Jun 30, 2020 at 5:19 PM Justin Forbes wrote:
> >
> > On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote:
> > >
> > > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes
> > > wrote:
> > > >
> > > > On Tue, Jun 30, 2020 at 1:39 PM John M.
On Tue, Jun 30, 2020 at 5:19 PM Justin Forbes wrote:
>
> On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote:
> >
> > On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote:
> > >
> > > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr
> > > wrote:
> > > >
> > > > On Tuesday, June 30, 2020 8:22:00
On Tue, Jun 30, 2020 at 4:02 PM Neal Gompa wrote:
>
> On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote:
> >
> > On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr
> > wrote:
> > >
> > > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > > > On Tue, 30 Jun 2020 at 11:09,
On Tue, Jun 30, 2020 at 4:30 PM Justin Forbes wrote:
>
> On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr
> wrote:
> >
> > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro
> > > wrote:
> > > >
> > > >
> > > > On Tue,
On Tuesday, June 30, 2020, Justin Forbes wrote:
> On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr
> wrote:
> >
> > On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro
> > > wrote:
> > > >
> > > >
> > > > On Tue, Jun 30,
On Tue, Jun 30, 2020 at 1:39 PM John M. Harris Jr wrote:
>
> On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro
> > wrote:
> > >
> > >
> > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
> > > wrote:
> > >
> > > > For
On Tue, Jun 30, 2020 at 2:39 PM John M. Harris Jr wrote:
>
> On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> > On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro
> > wrote:
> > >
> > >
> > > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
> > > wrote:
> > >
> > > > For
On Tue, Jun 30, 2020 at 10:30 AM Antti wrote:
>
> > Another way to consider this would be that we can stop arguing against these
> > changes, let the GNOME folks run the ship aground, and hope that the user
> > backlash will act as a wakeup call when it comes to these changes. I agree
> > that
On Tuesday, June 30, 2020 8:22:00 AM MST Stephen John Smoogen wrote:
> On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro
> wrote:
> >
> >
> > On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
> > wrote:
> >
> > > For the record, as this directly affects the Workstation deliverable,
> > > I will
> I can only offer descriptions of symptoms of trouble from the web back-end
> developer /
> desktop end-user PoW which starts to appear in personal computers where I
> have used or
> currently do use btrfs if not full-time. I made a long list of these
> yesterday and only
> some of them can be
On Tue, Jun 30, 2020 at 11:22 AM Stephen John Smoogen wrote:
>
> The problem is that the request as discussed reads as "FESCo says use
> it for workstation" vs "FESCo has no problem with Workstation saying
> they want btrfs" or "FESCo says use btrfs as default". Yes it says
> "desktop variants"
All,
As a long time user of Fedora I have run into nearly all the same issues as
mentioned below by Antti.
btrfs is not ready to be default:
https://news.ycombinator.com/item?id=14907771
On Sun, Jun 28, 2020 at 5:21 AM Antti wrote:
> Hello,
>
> I'm in total opposition to this proposal as a
On Tue, Jun 30, 2020 at 10:00 AM Michael Catanzaro wrote:
>
> On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
> wrote:
> > For the record, as this directly affects the Workstation deliverable,
> > I will be voting -1 until and unless the Workstation WG votes in
> > favor.
> >
> > Yes, it's a
On Tue, 30 Jun 2020 at 11:09, Michael Catanzaro wrote:
>
> On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
> wrote:
> > For the record, as this directly affects the Workstation deliverable,
> > I will be voting -1 until and unless the Workstation WG votes in
> > favor.
> >
> > Yes, it's a
On Tue, Jun 30, 2020 at 10:26 am, Stephen Gallagher
wrote:
For the record, as this directly affects the Workstation deliverable,
I will be voting -1 until and unless the Workstation WG votes in
favor.
Yes, it's a large set of Change owners, but since only two of them are
Workstation WG
Hi,
On 29/06/2020 19:54, Igor Raits wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-06-29 at 12:26 -0400, Matthew Miller wrote:
On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
We cannot include ZFS in Fedora for legal reasons. Additionally,
ZFS is not
> Another way to consider this would be that we can stop arguing against these
> changes, let the GNOME folks run the ship aground, and hope that the user
> backlash will act as a wakeup call when it comes to these changes. I agree
> that btrfs is far too unstable to be made a default, and I
On Fri, Jun 26, 2020 at 11:00 AM Matthew Miller
wrote:
>
>
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>
> Wow! Is it 2010 already? Time flies! :)
>
> In seriousness: thanks for all of the effort put into this change proposal,
> and the impressive list of change owners. I'm
Hi,
On 30/06/2020 13:58, Neal Gompa wrote:
On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse wrote:
Hi,
On 29/06/2020 23:57, Markus Larsson wrote:
On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
Why not Stratis?
Stratis cannot be
On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse wrote:
>
> Hi,
>
> On 29/06/2020 23:57, Markus Larsson wrote:
> > On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
> >> On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
> >>> Why not Stratis?
> >> Stratis cannot be used to build the root
On Tue, Jun 30, 2020 at 7:45 AM Nicolas Mailhot via devel
wrote:
>
> Le lundi 29 juin 2020 à 10:26 -0600, Chris Murphy a écrit :
> >
> > Come on. It's cleanly unmounted and doesn't mount?
> >
> > I guess you missed the other emails about dm-log-writes and xfstests,
> > but they directly relate
Le lundi 29 juin 2020 à 10:26 -0600, Chris Murphy a écrit :
>
> Come on. It's cleanly unmounted and doesn't mount?
>
> I guess you missed the other emails about dm-log-writes and xfstests,
> but they directly relate here. Josef relayed that all of his deep
> dives into Btrfs failures since the
* Steven Whitehouse:
> On 27/06/2020 11:00, Florian Weimer wrote:
>> * Josef Bacik:
>>
>>> As for your ENOSPC issue, I've made improvements on that area. I
>>> see this in production as well, I have monitoring in place to deal
>>> with the machine before it gets to this point. That being said
Hi,
On 29/06/2020 23:57, Markus Larsson wrote:
On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
Why not Stratis?
Stratis cannot be used to build the root filesystem. (It's been
answered elsewhere in the thread.)
Are we sure?
Hi,
On 27/06/2020 11:00, Florian Weimer wrote:
* Josef Bacik:
As for your ENOSPC issue, I've made improvements on that area. I
see this in production as well, I have monitoring in place to deal
with the machine before it gets to this point. That being said if
you run the box out of metadata
Thanks for the reply.
It feels a bit dismissive after the time I spent there, so I'll assume I
wasn't clear and my point didn't get across (I did send that mail at 1AM
and haven't slept much lately...):
I'm not complaining about any particular bug here, just that the overall
use & feel is way too
On Mon, Jun 29, 2020 at 5:17 PM Dominique Martinet
wrote:
>
> Recap of the problems I ran into:
> - bug in btrfs-convert where it just aborts in the middle with an
...
> - second bug in btrfs-convert, running scrub immediately after
...
My view is that btrfs-convert is something of a proof of
On Monday, June 29, 2020 3:40:57 PM MST Markus S. wrote:
> It's not a GPL violation. OpenZFS works under Linux through a compatibility
> layer called SPL, the Solaris Porting Layer. SPL is licensed under GPL.
> Torvalds himself said that a non-GPL file system that was written for
> another OS
So, given this already has way too many answers I didn't want to reply,
but after spending ~4 hours to get my laptop back to bootable state
after a btrfs-convert I guess some people might be interested.
Overall thoughts for whoever doesn't want to read the rest is: I think
btrfs the FS is
On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
> On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
> > Why not Stratis?
>
> Stratis cannot be used to build the root filesystem. (It's been
> answered elsewhere in the thread.)
Are we sure?
On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
> Why not Stratis?
Stratis cannot be used to build the root filesystem. (It's been answered
elsewhere in the thread.)
V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To
Why not Stratis?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
It's not a GPL violation. OpenZFS works under Linux through a compatibility
layer called SPL, the Solaris Porting Layer. SPL is licensed under GPL.
Torvalds himself said that a non-GPL file system that was written for another
OS cannot be considered a derivative of the Linux kernel:
The legality FUD is unrelated to rolling or non-rolling kernels.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Mon, Jun 29, 2020 at 01:33:37PM -0400, Josef Bacik wrote:
> On 6/29/20 12:23 PM, J. Bruce Fields wrote:
> > Maybe not a desktop question, but do you know btrfs's change
> > attribute/i_version status? Does it default to bumping i_version on
> > each change, or does that still need to be opted
On 6/29/20 1:47 PM, Josef Bacik wrote:
Just to be clear here, the choice of XFS here is purely based on
performance, not on the reliability of the file systems, right?
(So it's not “all the really important data is stored in XFS”.)
>>>
>>> Yes that's correct. At our scale
On Mon, Jun 29, 2020 at 10:26:37AM -0600, Chris Murphy wrote:
> You've got an example where 'btrfs restore' saw no files at all? And
> you think it's the file system rather than the hardware, why?
Because the system failed to boot up, and even after offline repair
attempts was still missing a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-06-29 at 12:26 -0400, Matthew Miller wrote:
> On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
> > > We cannot include ZFS in Fedora for legal reasons. Additionally,
> > > ZFS is not
> > > really intended for the
On 6/29/20 2:23 PM, Eric Sandeen wrote:
On 6/29/20 8:39 AM, Josef Bacik wrote:
On 6/29/20 5:33 AM, Florian Weimer wrote:
* Josef Bacik:
That being said I can make btrfs look really stupid on some workloads.
There's going to be cases where Btrfs isn't awesome. We still use xfs
for all our
On 6/29/20 12:44 PM, Mark Otaris wrote:
> That’s one fewer reason not to use XFS then. It seems
> Documentation/admin-guide/cgroup-v2.rst was not updated and still says
> only ext2, ext4, and btrfs have writeback implemented.
Interesting, thanks for the heads up - I'll get that fixed.
Looks like
On 6/29/20 8:39 AM, Josef Bacik wrote:
> On 6/29/20 5:33 AM, Florian Weimer wrote:
>> * Josef Bacik:
>>
>>> That being said I can make btrfs look really stupid on some workloads.
>>> There's going to be cases where Btrfs isn't awesome. We still use xfs
>>> for all our storage related tiers (think
On Mon, Jun 29, 2020 at 10:38 AM Przemek Klosowski via devel
wrote:
>
> On 6/27/20 11:40 PM, Tom Seewald wrote:
> >> On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams
> >> >>
> >>
> >> Just a PSA: btrfs raid1 does not have a concept of automatic degraded
> >> mount in the face of a device
Once upon a time, John M. Harris Jr said:
> For the best filesystem ever created, ZFS
My experiences with ZFS are less than impressive, definitely not "the
best ever". Too many fiddly things, and questions where the answer is
"back up and restore".
--
Chris Adams
That’s one fewer reason not to use XFS then. It seems
Documentation/admin-guide/cgroup-v2.rst was not updated and still says
only ext2, ext4, and btrfs have writeback implemented.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On 6/29/20 12:23 PM, J. Bruce Fields wrote:
Maybe not a desktop question, but do you know btrfs's change
attribute/i_version status? Does it default to bumping i_version on
each change, or does that still need to be opted in? And has anyone
measured the performance delta (i_version vs.
On Mon, Jun 29, 2020 at 10:20:17AM -0700, John M. Harris Jr wrote:
> I've both read that page, and linked to it further down in this thread.
> Yes, I believe that Canonical's implementation is a GPL violation, but it
> doesn't need to be. So long as the source is in a separate package, and
> it's
On Monday, June 29, 2020, John M. Harris Jr wrote:
> On Monday, June 29, 2020 9:26:09 AM MST Matthew Miller wrote:
> > On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
> >
> > > > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS
> is
> > > > not really
On Monday, June 29, 2020 9:26:09 AM MST Matthew Miller wrote:
> On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
>
> > > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is
> > > not really intended for the laptop use case.
> >
> > Has that actually been
On 6/29/20 12:38 PM, Przemek Klosowski via devel wrote:
On 6/27/20 11:40 PM, Tom Seewald wrote:
On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams
Just a PSA: btrfs raid1 does not have a concept of automatic degraded
mount in the face of a device failure. By default systemd will not
even
On 6/27/20 11:40 PM, Tom Seewald wrote:
On Sat, Jun 27, 2020 at 7:32 PM Garry T. Williams
Is this hopefully seen by upstream as a bug that will be fixed? This removes
the system availability benefits of raid, and I've never heard of another
system that would behave like this, whether that's
On Mon, Jun 29, 2020 at 7:55 AM Solomon Peachy wrote:
>
> On Mon, Jun 29, 2020 at 11:33:40AM +0200, Florian Weimer wrote:
> > Just to be clear here, the choice of XFS here is purely based on
> > performance, not on the reliability of the file systems, right?
> > (So it's not “all the really
On 6/26/20 5:23 PM, Tomasz Torcz wrote:
Disadvantages: using encryption is harder. GRUB2 supports only LUKS1
encryption (AFAIK). Obviously, there is not plymouth integration, so the
password would have to be entered at least twice.
When not using encryption above is not a problem.
There's
On Sun, Jun 28, 2020 at 09:59:52AM -0700, John M. Harris Jr wrote:
> > We cannot include ZFS in Fedora for legal reasons. Additionally, ZFS is not
> > really intended for the laptop use case.
> Has that actually been explored? How does Canonical get around the legal
> issues with OpenZFS'
Maybe not a desktop question, but do you know btrfs's change
attribute/i_version status? Does it default to bumping i_version on
each change, or does that still need to be opted in? And has anyone
measured the performance delta (i_version vs. noi_version) recently?
--b.
On 29 June 2020 17:36:15 CEST, Armin Wehrfritz wrote:
>> It is not acceptable that there is a range of time that people would
>> literally not be able to mount their file systems because the kernel
>> module would not build.
>I would say that is a rather unlikely scenario to happen given how
> It is not acceptable that there is a range of time that people would
> literally not be able to mount their file systems because the kernel
> module would not build.
I would say that is a rather unlikely scenario to happen given how engaged the
OpenZFS developers are in maintaining Linux kernel
* Solomon Peachy:
> On Mon, Jun 29, 2020 at 11:33:40AM +0200, Florian Weimer wrote:
>> Just to be clear here, the choice of XFS here is purely based on
>> performance, not on the reliability of the file systems, right?
>> (So it's not “all the really important data is stored in XFS”.)
>
> Be
On Mon, Jun 29, 2020 at 11:33:40AM +0200, Florian Weimer wrote:
> Just to be clear here, the choice of XFS here is purely based on
> performance, not on the reliability of the file systems, right?
> (So it's not “all the really important data is stored in XFS”.)
Be careful about overloading quite
On 6/29/20 1:31 AM, Mark Otaris wrote:
> The master branch for cp now defaults to copy-on-write on filesystems
> that support reflinks, which should make copies more efficient if
> Fedora starts using btrfs:
>
On 6/29/20 5:33 AM, Florian Weimer wrote:
* Josef Bacik:
That being said I can make btrfs look really stupid on some workloads.
There's going to be cases where Btrfs isn't awesome. We still use xfs
for all our storage related tiers (think databases). Performance is
always going to be
On Mon, Jun 29, 2020 at 4:16 AM John M. Harris Jr wrote:
>
> On Monday, June 29, 2020 12:54:02 AM MST Igor Raits wrote:
> > On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote:
> >
> > > On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote:
> > >
> > > > On 6/29/20 12:27 AM, John M.
> OpenZFS is frequently lagging behind in support for newer kernels which would
> work against
> Fedora's "rolling" approach to kernel releases.
Yes, there is quite often a time delay between kernel releases and OpenZFS
releases that contain compatibility patches. However, in my experience, the
> I'm strongly against this proposal. BTRFS is the most unstable file
> system I ever seen. It can break up even under an ideal conditions and
> lead to a complete data loss. There are lots of complaints and bug
> reports in Linux kernel bugzilla and Reddit.
Without providing evidence, this is
* Josef Bacik:
> That being said I can make btrfs look really stupid on some workloads.
> There's going to be cases where Btrfs isn't awesome. We still use xfs
> for all our storage related tiers (think databases). Performance is
> always going to be workload dependent, and Btrfs has built in
On Monday, June 29, 2020 12:54:02 AM MST Igor Raits wrote:
> On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote:
>
> > On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote:
> >
> > > On 6/29/20 12:27 AM, John M. Harris Jr wrote:
> > >
> > >
> > >
> > > > On Monday, June 29, 2020
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Mon, 2020-06-29 at 00:37 -0700, John M. Harris Jr wrote:
> On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote:
> > On 6/29/20 12:27 AM, John M. Harris Jr wrote:
> >
> > > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote:
> > >
On Monday, June 29, 2020 12:32:56 AM MST Samuel Sieb wrote:
> On 6/29/20 12:27 AM, John M. Harris Jr wrote:
>
> > On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote:
> >
> >> On 6/28/20 11:35 PM, John M. Harris Jr wrote:
> >>
> >>
> >>
> >>> For the best filesystem ever created, ZFS, I
On 6/29/20 12:27 AM, John M. Harris Jr wrote:
On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote:
On 6/28/20 11:35 PM, John M. Harris Jr wrote:
For the best filesystem ever created, ZFS, I can't say that I agree with
your assessment of that value. Having ZFS in Fedora would throw
On Monday, June 29, 2020 12:18:28 AM MST Samuel Sieb wrote:
> On 6/28/20 11:35 PM, John M. Harris Jr wrote:
>
> > For the best filesystem ever created, ZFS, I can't say that I agree with
> > your assessment of that value. Having ZFS in Fedora would throw Fedora
> > over the top as being the best
On 6/28/20 11:35 PM, John M. Harris Jr wrote:
For the best filesystem ever created, ZFS, I can't say that I agree with your
assessment of that value. Having ZFS in Fedora would throw Fedora over the top
as being the best Linux distro, hands down. I can count the number of times
that having root
On Sunday, June 28, 2020 5:14:14 PM MST Gerald Henriksen wrote:
> On Sun, 28 Jun 2020 09:59:52 -0700, you wrote:
>
>
> >Has that actually been explored? How does Canonical get around the legal
> >issues with OpenZFS' licensing?
>
>
> For a start they aren't a US company, and unlike Red Hat
On Sunday, June 28, 2020 11:31:15 PM MST Mark Otaris wrote:
> The master branch for cp now defaults to copy-on-write on filesystems
> that support reflinks, which should make copies more efficient if
> Fedora starts using btrfs:
>
101 - 200 of 352 matches
Mail list logo
