On Sun, Jul 12, 2020 at 07:31:30PM -, Tom Seewald wrote:
> For example with virtualization I'd think that the changes would need
> to happen around the level of libvirt, and not to specific a front-end
> like GNOME boxes or virt-manager. It's also probably not sufficient to
> just set
On Sun, Jul 12, 2020 at 5:33 PM Tom Seewald wrote:
>
> > What changes?
>
> I don't see a reason for this level of snark, in your next paragraph you
> described the changes I'm talking about.
>
> > Discussion is happening upstream to determine the best location for
> > such optimization to
> What changes?
I don't see a reason for this level of snark, in your next paragraph you
described the changes I'm talking about.
> Discussion is happening upstream to determine the best location for
> such optimization to happen.
I'm glad work is happening upstream and I hope it goes
On Sun, Jul 12, 2020 at 1:31 PM Tom Seewald wrote:
>
> > (Yes, that means applications need to start being concious of what fs
> > they are being run on, or at least the fedora configuration needs to do
> > that check for them)
>
> Right, and it's concerning to me that Fedora is committing to
> (Yes, that means applications need to start being concious of what fs
> they are being run on, or at least the fedora configuration needs to do
> that check for them)
Right, and it's concerning to me that Fedora is committing to btrfs by default
before important applications have become more
On Sun, Jul 12, 2020 at 7:51 AM Dominique Martinet
wrote:
> (Yes, that means applications need to start being concious of what fs
> they are being run on, or at least the fedora configuration needs to do
> that check for them)
Good luck with that. It's a direct violation of the "object
Vitaly Zaitsev via devel wrote on Sun, Jul 12, 2020:
> On 11.07.2020 14:20, Dominique Martinet wrote:
> > BTW, given the size gains ws. time difference for compression I would
> > advocate for default zstd compression instead of :1 -- I'd think another
> > 12% compression improvement[1] for almost
On 11.07.2020 17:28, Chris Murphy wrote:
> The paper is with respect to metadata write amplification. This has no
> effect on data writes. Compression applies to data writes, not
> metadata. As the data amount is significantly larger than metadata
> (the file system itself), any reduction in data
On 11.07.2020 14:20, Dominique Martinet wrote:
> BTW, given the size gains ws. time difference for compression I would
> advocate for default zstd compression instead of :1 -- I'd think another
> 12% compression improvement[1] for almost no time difference isn't to be
> sneezed at?
Now please
On Fri, Jul 10, 2020 at 1:45 PM Tomasz Torcz wrote:
>
> On Fri, Jul 10, 2020 at 07:14:09PM +0200, Vitaly Zaitsev via devel wrote:
> > On 26.06.2020 16:42, Ben Cotton wrote:
> > > ** transparent compression: significantly reduces write amplification,
> > > improves lifespan of storage hardware
> >
On Sat, Jul 11, 2020 at 6:11 AM Artem Tim wrote:
>
> BTRFS WA is ~8 times higher than ext4. Average profit from compression about
> 50% max. Not that hard arithmetic.
The paper is with respect to metadata write amplification. This has no
effect on data writes. Compression applies to data
On Fri, Jul 10, 2020 at 11:14 AM Vitaly Zaitsev via devel
wrote:
>
> On 26.06.2020 16:42, Ben Cotton wrote:
> > ** transparent compression: significantly reduces write amplification,
> > improves lifespan of storage hardware
>
> What can you say about this? https://arxiv.org/pdf/1707.08514.pdf
On Sat, Jul 11, 2020 at 5:55 AM Antti wrote:
> For example btrfs has for a long-time had this issue where after several
> months and being maybe more than 75% of disk space being in use, that when
> run on SSDs, system can randomly stops reading from the file system, starts
> thinking and
Artem Tim wrote on Sat, Jul 11, 2020:
> BTRFS WA is ~8 times higher than ext4. Average profit from compression
> about 50% max. Not that hard arithmetic.
It's not that simple.
The pattern used in that paper is far from a standard workload (random
writes within a file with cow is just about as bad
BTRFS WA is ~8 times higher than ext4. Average profit from compression about
50% max. Not that hard arithmetic.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
> That said, as one of the change owners, I *want* to know about your
> issues.
Yes, I understand. It's just that I believe that the burden of proof is on my
shoulders to prove that I have this and that issue before making bug reports.
The problem I often face with btrfs is that it is highly
On Fri, Jul 10, 2020 at 07:14:09PM +0200, Vitaly Zaitsev via devel wrote:
> On 26.06.2020 16:42, Ben Cotton wrote:
> > ** transparent compression: significantly reduces write amplification,
> > improves lifespan of storage hardware
>
> What can you say about this?
> It doesn't use compression so not relevant to the cited statement?
Well the paper compares ext2, ext4, xfs, f2fs, and btrfs in terms of IO
amplification and states:
"In fact, in all our experiments, btrfs was an outlier, producing the highest
read, write, and space amplification."
The
On 7/10/20 10:14 AM, Vitaly Zaitsev via devel wrote:
On 26.06.2020 16:42, Ben Cotton wrote:
** transparent compression: significantly reduces write amplification,
improves lifespan of storage hardware
What can you say about this? https://arxiv.org/pdf/1707.08514.pdf
I would say that it
On Friday, July 10, 2020, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 26.06.2020 16:42, Ben Cotton wrote:
> > ** transparent compression: significantly reduces write amplification,
> > improves lifespan of storage hardware
>
> What can you say about this?
On 26.06.2020 16:42, Ben Cotton wrote:
> ** transparent compression: significantly reduces write amplification,
> improves lifespan of storage hardware
What can you say about this? https://arxiv.org/pdf/1707.08514.pdf
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 7/9/20 2:24 PM, Eric Sandeen wrote:
<50 runs later on btrfs>
16 readonly mounts failed (32% failure rate)
Within the successful mounts, 1 or more files were unreachable in 30 attempts.
Across all 50 attempts, 7720 files were lost.
Is that better than ext4, and will ext4 need fsck just to be
On Fri, Jun 26, 2020 at 6:30 PM Josef Bacik wrote:
>
> On 6/26/20 11:15 AM, Matthew Miller wrote:
> > On Fri, Jun 26, 2020 at 11:13:39AM -0400, Josef Bacik wrote:
> >> Not Fedora land, but Facebook installs it on all of our root
> >> devices, so millions of machines. We've done this for 5 years.
On 7/9/20 9:15 PM, Josef Bacik wrote:
> On 7/9/20 9:30 PM, Eric Sandeen wrote:
...
>>> This test is run constantly by us, specifically because it's the error
>>> cases that get you. But not for crash consistency reasons, because we're
>>> solid there. I run them to make sure I don't have
On 7/9/20 9:30 PM, Eric Sandeen wrote:
On 7/9/20 8:22 PM, Josef Bacik wrote:
On 7/9/20 7:23 PM, Eric Sandeen wrote:
On 7/9/20 4:27 PM, Eric Sandeen wrote:
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
As someone on one of the teams at FB that has to deal with that, I can
assure
On 7/9/20 8:22 PM, Josef Bacik wrote:
> On 7/9/20 7:23 PM, Eric Sandeen wrote:
>> On 7/9/20 4:27 PM, Eric Sandeen wrote:
>>> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
>>
>> ...
>>
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios
On 7/9/20 7:23 PM, Eric Sandeen wrote:
On 7/9/20 4:27 PM, Eric Sandeen wrote:
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios you listed can and do happen, and they
happen a lot. While
On 7/9/20 4:27 PM, Eric Sandeen wrote:
> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
>> As someone on one of the teams at FB that has to deal with that, I can
>> assure you all the scenarios you listed can and do happen, and they
>> happen a lot. While we don't have the "laptop's out
On Thu, Jul 9, 2020 at 3:06 PM Stephen John Smoogen wrote:
>
> That is because anyone who questions the perfection of ZFS is quickly
> burned at a stake.
I think Neal also has a good take on why, which is that it was mostly
a closed door development early on, wasn't used on heterogeneous
- Original Message -
> From: "Josef Bacik"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 9, 2020 9:11:07 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
> file system for desktop variants
>
> On 7/9/20 1:51 P
On 7/9/20 3:38 PM, Chris Murphy wrote:
> On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
>> On 7/9/20 2:11 PM, Josef Bacik wrote:
From what I've gathered from these responses, btrfs is unique in that it
is
/expected/ that if anything goes wrong, the administrator should be
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
> On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
>> However I have had bad kernels, power outages, loss of battery power
>> (laptops on too long suspend) and other random reasons to force
>> reboot
>> a system. That has been the primary case
On Thu, Jul 9, 2020 at 4:16 PM Simo Sorce wrote:
>
> On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote:
> > On 7/9/20 2:11 PM, Josef Bacik wrote:
> > > > From what I've gathered from these responses, btrfs is unique in that
> > > > it is
> > > > /expected/ that if anything goes wrong, the
On Thu, 2020-07-09 at 13:32 -0700, Davide Cavalca via devel wrote:
> On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
> > However I have had bad kernels, power outages, loss of battery power
> > (laptops on too long suspend) and other random reasons to force
> > reboot
> > a system. That has
On Thu, 9 Jul 2020 at 16:49, Chris Murphy wrote:
>
> On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
> >
> > On 7/9/20 2:11 PM, Josef Bacik wrote:
> > >>
> > >> From what I've gathered from these responses, btrfs is unique in that
> > >> it is
> > >> /expected/ that if anything goes wrong,
On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
>
> On 7/9/20 2:11 PM, Josef Bacik wrote:
> >>
> >> From what I've gathered from these responses, btrfs is unique in that it
> >> is
> >> /expected/ that if anything goes wrong, the administrator should be
> >> prepared
> >> to scrape out
On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
> However I have had bad kernels, power outages, loss of battery power
> (laptops on too long suspend) and other random reasons to force
> reboot
> a system. That has been the primary case of file system checks
> through
> my Fedora usage. And
On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote:
> On 7/9/20 2:11 PM, Josef Bacik wrote:
> > > From what I've gathered from these responses, btrfs is unique in that it
> > > is
> > > /expected/ that if anything goes wrong, the administrator should be
> > > prepared
> > > to scrape out
On 7/9/20 2:11 PM, Josef Bacik wrote:
>>
>> From what I've gathered from these responses, btrfs is unique in that it is
>> /expected/ that if anything goes wrong, the administrator should be prepared
>> to scrape out remaining data, re-mkfs, and start over. If that's acceptable
>> for the Fedora
On 7/9/20 1:51 PM, Eric Sandeen wrote:
On 7/6/20 12:07 AM, Chris Murphy wrote:
On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
wrote:
On 7/3/20 1:41 PM, Chris Murphy wrote:
SSDs can fail in weird ways. Some spew garbage as they're
failing, some go read-only. I've seen both. I don't have stats
On 7/6/20 8:21 PM, Chris Murphy wrote:
...
> Yes. Also in fuzzing there is the concept of "when to stop fuzzing"
> because it's a rabbit hole, you have to come up for air at some point,
> and work on other things. But you raise a good and subtle point which
> is also that ext4 has a very good
On 7/6/20 12:07 AM, Chris Murphy wrote:
> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
> wrote:
>>
>> On 7/3/20 1:41 PM, Chris Murphy wrote:
>>> SSDs can fail in weird ways. Some spew garbage as they're
>>> failing, some go read-only. I've seen both. I don't have stats on
>>> how common it is for
On 08.07.20 23:47, Adam Williamson wrote:
> I think it's `efibootmgr -b -L DefinitelyNotFedora`, where is
> the number of the entry called 'Fedora', which you could find by just
> running `efibootmgr` to get a list of entries. -b selects the entry to
> operate on and -L changes the
On Wed, 2020-07-08 at 17:23 -0400, James Cassell wrote:
> On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote:
> > On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> > > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen
> > > wrote:
> > > >
> > > > On Wed, 1 Jul 2020 14:24:37 -0400, you
On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote:
> On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> > >
> > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> > >
> > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew
On 7 July 2020 18:31:32 CEST, Adam Williamson
wrote:
>On Tue, 2020-07-07 at 06:02 +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote:
>> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
>> > > So if one has a spare partition to
On Tue, 2020-07-07 at 06:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote:
> > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> > > So if one has a spare partition to play with btrfs, is there an easy
> > > way to install a second
On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote:
> On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> >
> > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> >
> > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek
> > > wrote:
> > > > Making btrfs opt-in for F33
On Tue, Jul 7, 2020 at 9:25 AM Lennart Poettering wrote:
> Thou shallt not have multiple ESPs per disk. See:
>
> https://news.ycombinator.com/item?id=16261695
>
> The EFI spec is kinda vague about it, but it breaks everywhere, in
> particular with Windows.
The Windows *installer* doesn't like
On Mo, 06.07.20 20:06, Chris Murphy (li...@colorremedies.com) wrote:
> On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> >
> > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> >
> > >On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek
> > >wrote:
> > >> Making btrfs
On Wed, Jul 01, 2020 at 03:50:37PM -0400, Josef Bacik wrote:
> I've stated this many times before, btrfs is more vulnerable to
> things going wrong. It's also more likely to notice things going
> wrong. There's things we can do to make it easier in the face of
> these issues, they're patches
David Sterba 于2020年7月7日周二 下午6:09写道：
>
> > Yes, BtrFs was very unstable, but before. Every software has this process.
> > I
> > have talked to one of the maintainer of BtrFs, she thinks that BtrFs is
> > ready
> > to production usage. (few years before, she is strongly against using BtrFs
> >
> Yes, BtrFs was very unstable, but before. Every software has this process. I
> have talked to one of the maintainer of BtrFs, she thinks that BtrFs is ready
> to production usage. (few years before, she is strongly against using BtrFs
> for production purpose).
May I ask who was the person you
On Mon, Jul 06, 2020 at 08:06:05PM -0600, Chris Murphy wrote:
> On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
> > So if one has a spare partition to play with btrfs, is there an easy
> > way to install a second copy of Fedora without having the /boot/efi/
> > entries overwrite the
On Mon, Jul 6, 2020 at 5:30 PM Samuel Sieb wrote:
>
> On 7/6/20 4:24 PM, Adam Williamson wrote:
> > If you mean the EFI boot manager entry, just renaming the existing one
> > something other than "Fedora" ought to do the trick, I think. So far as
> > /boot/efi goes...well, you have two choices.
On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote:
>
> On Wed, 1 Jul 2020 14:24:37 -0400, you 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
On Mon, Jul 6, 2020 at 9:52 AM Stephen John Smoogen wrote:
>
> On Mon, 6 Jul 2020 at 01:19, Chris Murphy wrote:
> >
> > On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen wrote:
> > >
> > > On 7/3/20 1:41 PM, Chris Murphy wrote:
> > > > SSDs can fail in weird ways. Some spew garbage as they're
On 7/6/20 4:24 PM, Adam Williamson wrote:
If you mean the EFI boot manager entry, just renaming the existing one
something other than "Fedora" ought to do the trick, I think. So far as
/boot/efi goes...well, you have two choices. You can have the two
installs share one, or have two separate
On Mon, 2020-07-06 at 16:24 -0700, Adam Williamson wrote:
> On Mon, 2020-07-06 at 18:48 -0400, Gerald Henriksen wrote:
> > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote:
> >
> > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek
> > > wrote:
> > > > Making btrfs opt-in for
On Mon, 2020-07-06 at 18:48 -0400, Gerald Henriksen wrote:
> On Wed, 1 Jul 2020 14:24:37 -0400, you 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
On Wed, 1 Jul 2020 14:24:37 -0400, you 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
>> very
On 7/2/20 4:38 PM, Eric Sandeen wrote:
Running 10 loops on each of btrfs, ext4, and xfs I got results that look
like this (ext4 always creates empty lost+found so it will always find at
least 1 file there)
btrfs
...
== 4 fsck failures, 2 mount failures
ext4
...
== 0 fsck failures, 0 mount
On Mon, 6 Jul 2020 at 01:19, Chris Murphy wrote:
>
> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen wrote:
> >
> > On 7/3/20 1:41 PM, Chris Murphy wrote:
> > > SSDs can fail in weird ways. Some spew garbage as they're failing,
> > > some go read-only. I've seen both. I don't have stats on how
On 7/3/20 10:39 PM, Eric Sandeen wrote:
On 7/3/20 1:41 PM, Chris Murphy wrote:
SSDs can fail in weird ways. Some spew garbage as they're failing,
some go read-only. I've seen both. I don't have stats on how common it
is for an SSD to go read-only as it fails, but once it happens you
cannot fsck
On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen wrote:
>
> On 7/3/20 1:41 PM, Chris Murphy wrote:
> > SSDs can fail in weird ways. Some spew garbage as they're failing,
> > some go read-only. I've seen both. I don't have stats on how common it
> > is for an SSD to go read-only as it fails, but once
On Fri, Jul 3, 2020 at 9:14 AM Josef Bacik wrote:
>
> On 7/3/20 9:37 AM, Eric Sandeen wrote:
> > Does btrfsck really never attempt to salvage a metadata block with a bad
> > CRC by
> > validating its fields?
>
> No, I suppose we could, I'll add it to the list. Generally speaking if
> there's
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 7/3/20 1:41 PM, Chris Murphy wrote:
> SSDs can fail in weird ways. Some spew garbage as they're failing,
> some go read-only. I've seen both. I don't have stats on how common it
> is for an SSD to go read-only as it fails, but once it happens you
> cannot fsck it. It won't accept writes. If it
SSDs can fail in weird ways. Some spew garbage as they're failing,
some go read-only. I've seen both. I don't have stats on how common it
is for an SSD to go read-only as it fails, but once it happens you
cannot fsck it. It won't accept writes. If it won't mount, your only
chance to recover data
On 7/3/20 9:37 AM, Eric Sandeen wrote:
On 7/1/20 2:50 PM, Josef Bacik wrote:
On 7/1/20 2:24 PM, 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
On 7/1/20 2:50 PM, Josef Bacik wrote:
> On 7/1/20 2:24 PM, 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
Le jeudi 02 juillet 2020 à 17:44 -0400, Josef Bacik a écrit :
> However just because we know something
> went wrong doesn't mean we can do anything about it, it just means
> that the user knows now that they need to restore from backups
That’s a perfect answer for an Enterprise server setup
Yeah I mean the general discussion, not you specifically. Thanks,
Josef
On Thu, Jul 2, 2020 at 8:38 PM Eric Sandeen wrote:
> On 7/2/20 4:44 PM, Josef Bacik wrote:
> > We're talking about this issue like it's reasonable that xfs and ext4
> are going to allow the user to get back a bunch of
On 7/2/20 4:44 PM, Josef Bacik wrote:
> We're talking about this issue like it's reasonable that xfs and ext4 are
> going to allow the user to get back a bunch of data they don't know is ok or
> not. We're also talking about it like the user should be able to carry on his
> happy merry way. In
On Thu, 2020-07-02 at 21:37 +0300, Konstantin Kharlamov wrote:
> On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote:
> > * Konstantin Kharlamov:
> >
> > > FWIW, I was just thinking about it, and I came up with example you
> > > may like which shows exactly why BTRFS is bad for HDD. Consider
On 7/2/20 4:38 PM, Eric Sandeen wrote:
On 7/1/20 12:50 PM, Chris Murphy wrote:
...
Integrity checking is highly valued by some and less by others.
Considering that we know hardware isn't 100% reliable, and doesn't
always report its own failures as expected, and hence why most file
systems now
On 7/2/20 3:58 PM, José Abílio Matos wrote:
> On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote:
>> 3 files in lost+found, -1 files gone/unreachable
>
> This last line from the xfs test seems suspicious (the -1 file gone). :-)
It is weird, but it shows I didn't fudge the numbers ;)
On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote:
> 3 files in lost+found, -1 files gone/unreachable
This last line from the xfs test seems suspicious (the -1 file gone). :-)
--
José Abílio
___
devel mailing list --
On 2020-07-01 23:04, Michael Catanzaro wrote:
On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa wrote:
The real solution would be to make wise usage of LVM, for example by not
allocating 100% of the extents at the beginning (or even dm-thin) and/or
using filesystems where a shrink is supported
On 7/1/20 12:50 PM, Chris Murphy wrote:
...
> Integrity checking is highly valued by some and less by others.
> Considering that we know hardware isn't 100% reliable, and doesn't
> always report its own failures as expected, and hence why most file
> systems now at least checksum metadata, it's
On 7/1/20 9:49 PM, Chris Adams wrote:
Once upon a time, Josef Bacik said:
This sounds like a "wtf, why are you doing this btrfs?" sort of
thing, but this is just the reality of using checksums. It's a
checksum, not ECC. We don't know _which_ bits are fucked, we just
know somethings fucked,
On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote:
> * Konstantin Kharlamov:
>
> > FWIW, I was just thinking about it, and I came up with example you
> > may like which shows exactly why BTRFS is bad for HDD. Consider
> > development process. It includes rewriting source files over and
> >
On 7/1/20 9:24 AM, Josef Bacik wrote:
> 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 Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa
wrote:
The real solution would be to make wise usage of LVM, for example by
not
allocating 100% of the extents at the beginning (or even dm-thin)
and/or
using filesystems where a shrink is supported (I'm here blaming xfs
for not having this,
* Konstantin Kharlamov:
> FWIW, I was just thinking about it, and I came up with example you
> may like which shows exactly why BTRFS is bad for HDD. Consider
> development process. It includes rewriting source files over and
> over: you do `git checkout foo` and files are overwritten, you
>
On Wed, Jul 1, 2020 at 11:25 PM Chris Murphy wrote:
>
> This is called 'dup' profile in Btrfs. Two copies of a block group.
Two copies of a block group ^on the same drive.
--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Wed, Jul 1, 2020 at 8:24 PM James Cassell
wrote:
>
>
> On Wed, Jul 1, 2020, at 9:43 PM, Neal Gompa wrote:
> > On Wed, Jul 1, 2020 at 9:27 PM James Cassell
> > > Or maybe make all metadata raid 1, even on single disk set up?
> > >
> >
> > Not that isn't interesting, but what would be the
On Wed, Jul 1, 2020, at 9:43 PM, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 9:27 PM James Cassell
> wrote:
> >
> >
> > On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote:
> > > On 7/1/20 3:50 PM, Josef Bacik wrote:
> > > > This sounds like a "wtf, why are you doing this btrfs?"
Once upon a time, Josef Bacik said:
> This sounds like a "wtf, why are you doing this btrfs?" sort of
> thing, but this is just the reality of using checksums. It's a
> checksum, not ECC. We don't know _which_ bits are fucked, we just
> know somethings fucked, so we throw it all away. If you
On Wed, Jul 1, 2020 at 9:27 PM James Cassell
wrote:
>
>
> On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote:
> > On 7/1/20 3:50 PM, Josef Bacik wrote:
> > > This sounds like a "wtf, why are you doing this btrfs?" sort of thing,
> > > but this is just the reality of using
On Wed, Jul 1, 2020, at 9:03 PM, Przemek Klosowski via devel wrote:
> On 7/1/20 3:50 PM, Josef Bacik wrote:
> > This sounds like a "wtf, why are you doing this btrfs?" sort of thing,
> > but this is just the reality of using checksums. It's a checksum, not
> > ECC.
>
> Yes, exactly---why
On 7/1/20 3:50 PM, Josef Bacik wrote:
This sounds like a "wtf, why are you doing this btrfs?" sort of thing,
but this is just the reality of using checksums. It's a checksum, not
ECC.
Yes, exactly---why isn't it ECC? Wouldn't it work better, especially in
the context of faulty hardware?
> On Sun, Jun 28, 2020 at 7:54 PM Gerald B. Cox
> I'm wondering, how do you actually want to define a "production
> release" of a kernel module?
> Does being part of an upstream kernel release (not in staging modules)
> not qualify?
> Because that's already the case, and has been for years. The
On 7/1/20 4:08 PM, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen wrote:
>>
>> On 7/1/20 11:53 AM, Michael Catanzaro wrote:
>>> 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
On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen wrote:
>
> On 7/1/20 11:53 AM, Michael Catanzaro wrote:
> > 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,
On 7/1/20 11:53 AM, Michael Catanzaro wrote:
> 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
On 2020-07-01 18:53, Michael Catanzaro wrote:
The options we are seriously considering for our default going forward are (a)
btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c)
less-likely, maybe xfs all one big partition without LVM. This is being
discussed in
On 2020-07-01 04:07, Nico Kadel-Garcia wrote:
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
On 7/1/20 2:24 PM, 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
very visible or
I like this approach, a lot. I'm all in favour of switching to btrfs
(I've been using it for a while, on server & desktop), and I think this
would be a safe approach to do so.
Christopher
On 01.07.20 20:24, Matthew Miller wrote:
> On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew
1 - 100 of 354 matches
Mail list logo
