Chris Murphy posted on Mon, 12 Sep 2016 08:48:49 -0600 as excerpted:
> On Sun, Sep 11, 2016 at 10:54 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
>> On the bright side, the double-whammy of being under such tight
>> filesystem size constraints, coupled with finding out you have less
>> than half th
Kai Krakow posted on Tue, 13 Sep 2016 00:21:10 +0200 as excerpted:
> Am Sun, 21 Aug 2016 02:19:33 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:
>
>> Chris Murphy posted on Sat, 20 Aug 2016 18:36:21 -0600 as excerpted:
>>
>> > FAT leaves a lot to be desired but it's pretty universally supp
hello,
On 08/13/2016 01:36 AM, Ronan Arraes Jardim Chagas wrote:
Hi guys,
I'm facing a daily problem with BTRFS. Almost everyday, I get the
message "No space left on device". Sometimes I can recover by balancing
the system but sometimes even balancing does not work due to the lack
of space. In
Normally, bad key order can be fixed automatically (btrfs check --repair).
Since btrfs has no idea what key order is correct.
Normally for such case, btrfs uses DUP/RAID1/5/6/10 to recover bad
metadata block, but since it's caused by bad RAM, backup is all corrupted.
So for common case, it's
IIRC it's now part of Anand Jain's hot device replace patchset.
And noone knows when hot device replace will be merged, the per chunk
degrade check won't be merged.
Thanks,
Qu
At 09/13/2016 05:49 AM, Hugo Mills wrote:
What happened to these patches? (Particularly the per-chunk
degraded ch
On Mon, Sep 12, 2016 at 10:56:04AM -0400, Josef Bacik wrote:
> I think that looping through all the sb's in the system would be
> kinda shitty for this tho, we want the "get number of dirty pages"
> part to be relatively fast. What if I do something like the
> shrinker_control only for dirty objec
On Mon, Sep 12, 2016 at 10:24:12AM -0400, Josef Bacik wrote:
> Dave your reply got eaten somewhere along the way for me, so all i
> have is this email. I'm going to respond to your stuff here.
No worries, I'll do a 2-in-1 reply :P
> On 09/12/2016 03:34 AM, Jan Kara wrote:
> >On Mon 12-09-16 10:4
Am Sun, 21 Aug 2016 02:19:33 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:
> Chris Murphy posted on Sat, 20 Aug 2016 18:36:21 -0600 as excerpted:
>
> > FAT leaves a lot to be desired but it's pretty universally
> > supported and almost trivial to repair *if* the volume is
> > repairable in t
What happened to these patches? (Particularly the per-chunk
degraded checks). We've just had someone on IRC who could have used
the capability...
Hugo.
On Tue, May 10, 2016 at 10:09:21PM +0800, Anand Jain wrote:
> From: Qu Wenruo
>
> Now use the btrfs_check_degraded() to do mount time deg
On 12 September 2016 at 19:55, Austin S. Hemmelgarn
wrote:
> I'm not sure about gparted, but the default behavior for mkfs is as follows:
> 1. Is the device rotational? (check /sys/block//rotational). If
> not, do some extra stuff to try and ID it as an SSD. If it is an SSD, use
> SINGLE mode fo
Am Montag, 12. September 2016, 23:27:28 CEST schrieb Heinz Werner Kramski-
Grote:
> Due to bad RAM (now fixed), my (single disk) root partition got corrupted
> and no longer mounts with "corrupt leaf, bad key order":
>
> root@archiso ~ # mount /dev/sdh2 /mnt
> mount: wrong fs type, bad opt
On 09/12/2016 02:46 PM, Hans van Kranenburg wrote:
> On 09/12/2016 02:39 PM, David Sterba wrote:
>> On Fri, Sep 09, 2016 at 11:37:21PM +0200, Hans van Kranenburg wrote:
>>> Hi,
>>>
>>> While trying to enable skinny metadata on a filesystem, I got this error
>>> (after minutes of reading from disk b
Due to bad RAM (now fixed), my (single disk) root partition got corrupted and
no longer mounts with "corrupt leaf, bad key order":
root@archiso ~ # mount /dev/sdh2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdh2,
missing codepage or helper program, or other erro
Pasi Kärkkäinen wrote:
On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
Great.
I made to minor adaption. I added a link to the Status page to my warning in
before the kernel log by feature page. And I also mentioned that at the time
the page was last updated the latest kerne
On Mon, Sep 12, 2016 at 2:35 PM, Martin Steigerwald wrote:
> Am Montag, 12. September 2016, 23:21:09 CEST schrieb Pasi Kärkkäinen:
>> On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
>> > Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba:
>> > > On Mon, Sep 12, 2
Am Montag, 12. September 2016, 23:21:09 CEST schrieb Pasi Kärkkäinen:
> On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
> > Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba:
> > > On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
> > > > > I therefor
On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
> Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba:
> > On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
> > > > I therefore would like to propose that some sort of feature / stability
> > > > matrix f
On Mon, Sep 12, 2016 at 5:24 AM, Austin S. Hemmelgarn
wrote:
>
> After device discovery, specify UUID= instead of a device node.
Oh yeah good point, -U --uuid is also doable. I'm not sure what the
benefit is of using sysfs to delete a device's node after umounting.
If the umount isn't successful
On Mon, Sep 12, 2016 at 10:56 AM, Austin S. Hemmelgarn
wrote:
>
> Things listed as TBD status:
> 1. Seeding: Seems to work fine the couple of times I've tested it, however
> I've only done very light testing, and the whole feature is pretty much
> undocumented.
Mostly OK.
Odd behaviors:
- mount
Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba:
> On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
> > > I therefore would like to propose that some sort of feature / stability
> > > matrix for the latest kernel is added to the wiki preferably somewhere
> > > where i
Remove unneeded variables and assignments.
Signed-off-by: Masahiro Yamada
---
fs/btrfs/check-integrity.c | 7 ++-
fs/btrfs/ctree.c | 4 +---
fs/btrfs/delayed-inode.c | 5 +
fs/btrfs/extent-tree.c | 12 ++--
fs/btrfs/send.c| 8 ++--
5 files cha
On 2016-09-12 14:46, Imran Geriskovan wrote:
Wait wait wait a second:
This is 256 MB SINGLE created
by GPARTED, which is the replacement of MANUALLY
CREATED 127MB DUP which is now non-existant..
Which I was not aware it was a DUP at the time..
Peeww... Small btrfs is full of surprises.. ;)
What
> Wait wait wait a second:
> This is 256 MB SINGLE created
> by GPARTED, which is the replacement of MANUALLY
> CREATED 127MB DUP which is now non-existant..
> Which I was not aware it was a DUP at the time..
> Peeww... Small btrfs is full of surprises.. ;)
What's more, I also have another 128MB S
Zoiled wrote:
Chris Mason wrote:
On 09/11/2016 04:55 AM, Waxhead wrote:
I have been following BTRFS for years and have recently been
starting to
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim
the o
> btrfs filesystem df /mnt/back/boot
> Data, single: total=8.00MiB, used=0.00B
> System, DUP: total=8.00MiB, used=16.00KiB
> Metadata, DUP: total=32.00MiB, used=112.00KiB
> GlobalReserve, single: total=16.00MiB, used=0.00B
> IT IS DUP!!
Wait wait wait a second:
This is 256 MB SINGLE created
by GPA
On 2016-09-12 13:29, Filipe Manana wrote:
On Mon, Sep 12, 2016 at 5:56 PM, Austin S. Hemmelgarn
wrote:
On 2016-09-12 12:27, David Sterba wrote:
On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
I therefore would like to propose that some sort of feature / stability
matrix for th
Chris Mason wrote:
On 09/11/2016 04:55 AM, Waxhead wrote:
I have been following BTRFS for years and have recently been starting to
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim
the opposite.
Taking
On 2016-09-12 12:51, David Sterba wrote:
On Mon, Sep 12, 2016 at 10:54:40AM -0400, Austin S. Hemmelgarn wrote:
Somebody has put that table on the wiki, so it's a good starting point.
I'm not sure we can fit everything into one table, some combinations do
not bring new information and we'd need n
On Mon, Sep 12, 2016 at 5:56 PM, Austin S. Hemmelgarn
wrote:
> On 2016-09-12 12:27, David Sterba wrote:
>>
>> On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
I therefore would like to propose that some sort of feature / stability
matrix for the latest kernel is added t
On 2016-09-12 12:27, David Sterba wrote:
On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
I therefore would like to propose that some sort of feature / stability
matrix for the latest kernel is added to the wiki preferably somewhere
where it is easy to find. It would be nice to arch
On Mon, Sep 12, 2016 at 10:54:40AM -0400, Austin S. Hemmelgarn wrote:
> > Somebody has put that table on the wiki, so it's a good starting point.
> > I'm not sure we can fit everything into one table, some combinations do
> > not bring new information and we'd need n-dimensional matrix to get the
>
On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
> > I therefore would like to propose that some sort of feature / stability
> > matrix for the latest kernel is added to the wiki preferably somewhere
> > where it is easy to find. It would be nice to archive old matrix'es as
> > well
On 09/09/2016 04:17 AM, Jan Kara wrote:
On Mon 22-08-16 13:35:01, Josef Bacik wrote:
Provide a mechanism for file systems to indicate how much dirty metadata they
are holding. This introduces a few things
1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY.
2) WB stat for
On 2016-09-12 10:51, Chris Murphy wrote:
On Mon, Sep 12, 2016 at 8:09 AM, Henk Slager wrote:
FWIW, I use BTRFS for /boot, but it's not for snapshotting or even the COW,
it's for DUP mode and the error recovery it provides. Most people don't
think about this if it hasn't happened to them, but i
On 2016-09-12 10:27, David Sterba wrote:
Hi,
first, thanks for choosing a catchy subject, this always helps. While it
will serve as another beating stick to those who enjoy bashing btrfs,
I'm glad to see people answer in a constructive way.
On Sun, Sep 11, 2016 at 10:55:21AM +0200, Waxhead wrot
On Mon, Sep 12, 2016 at 8:09 AM, Henk Slager wrote:
>> FWIW, I use BTRFS for /boot, but it's not for snapshotting or even the COW,
>> it's for DUP mode and the error recovery it provides. Most people don't
>> think about this if it hasn't happened to them, but if you get a bad read
>> from /boot
On Sun, Sep 11, 2016 at 10:54 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> On the bright side, the double-whammy of being under such tight
> filesystem size constraints, coupled with finding out you have less than
> half the space of the filesystem actually available due to default-mixed-
> mode AND
Hi, I ran tests on the devel branch (
2b7c507d1de764002763190afe219746bb710098 ) of the github repo.
Compiling btrfs with "-g3 -fsanitize=address -fno-common" using gcc
6.1.1-3 (fedora 24) reveals a heap use after free in
repair_inode_backrefs().
These fsck tests failed (crashed due to ASAN
Hi,
first, thanks for choosing a catchy subject, this always helps. While it
will serve as another beating stick to those who enjoy bashing btrfs,
I'm glad to see people answer in a constructive way.
On Sun, Sep 11, 2016 at 10:55:21AM +0200, Waxhead wrote:
> I have been following BTRFS for years
Dave your reply got eaten somewhere along the way for me, so all i have is this
email. I'm going to respond to your stuff here.
On 09/12/2016 03:34 AM, Jan Kara wrote:
On Mon 12-09-16 10:46:56, Dave Chinner wrote:
On Fri, Sep 09, 2016 at 10:17:43AM +0200, Jan Kara wrote:
On Mon 22-08-16 13:3
On 2016-09-12 10:09, Henk Slager wrote:
FWIW, I use BTRFS for /boot, but it's not for snapshotting or even the COW,
it's for DUP mode and the error recovery it provides. Most people don't
think about this if it hasn't happened to them, but if you get a bad read
from /boot when loading the kernel
> FWIW, I use BTRFS for /boot, but it's not for snapshotting or even the COW,
> it's for DUP mode and the error recovery it provides. Most people don't
> think about this if it hasn't happened to them, but if you get a bad read
> from /boot when loading the kernel or initrd, it can essentially nuk
>> Just to note again:
>> Ordinary 127MB btrfs gives "Out of space" around 64MB payload. 128MB is
>> usable to the end.
> Thanks, and just to clarify for others possibly following along or
> googling it up later, that's single mode (as opposed to dup mode) for at
> least data, if in normal separat
Hi,
On 12/09/2016 14:59, Michel Bouissou wrote:
> [...]
> I never had problems with lzo compression, although I suspect that it (in
> conjuction with snapshots) adds much fragmentation that may relate to the
> extremely bad performance I get over time with mechanical HDs.
I had about 30 btrfs
On 2016-09-12 09:27, Jeff Mahoney wrote:
On 9/12/16 2:54 PM, Austin S. Hemmelgarn wrote:
On 2016-09-12 08:33, Jeff Mahoney wrote:
On 9/9/16 8:47 PM, Austin S. Hemmelgarn wrote:
A couple of other things to comment about on this:
1. 'can_overcommit' (the function that the Arch kernel choked on)
On 09/11/2016 04:55 AM, Waxhead wrote:
I have been following BTRFS for years and have recently been starting to
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim
the opposite.
Taking a quick glance at t
On 09/12/2016 07:37 AM, Austin S. Hemmelgarn wrote:
>> On 2016-09-09 15:23, moparisthebest wrote:
>> Didn't ubuntu on kernel 4.4 die in the same can_overcommit function?
>> (https://www.moparisthebest.com/btrfsoops.jpg) what kind of hardware
>> issues would cause a repeatable kernel crash like that
On 9/12/16 2:54 PM, Austin S. Hemmelgarn wrote:
> On 2016-09-12 08:33, Jeff Mahoney wrote:
>> On 9/9/16 8:47 PM, Austin S. Hemmelgarn wrote:
>>> A couple of other things to comment about on this:
>>> 1. 'can_overcommit' (the function that the Arch kernel choked on) is
>>> from the memory management
On 2016-09-12 08:59, Michel Bouissou wrote:
Le lundi 12 septembre 2016, 08:20:20 Austin S. Hemmelgarn a écrit :
FWIW, here's a list of what I personally consider stable (as in, I'm
willing to bet against reduced uptime to use this stuff on production
systems at work and personal systems at home)
Le lundi 12 septembre 2016, 08:20:20 Austin S. Hemmelgarn a écrit :
> FWIW, here's a list of what I personally consider stable (as in, I'm
> willing to bet against reduced uptime to use this stuff on production
> systems at work and personal systems at home):
> 1. Single device mode, including DU
On 2016-09-12 08:54, Imran Geriskovan wrote:
On 9/11/16, Chris Murphy wrote:
Something else that's screwy in that bug that I just realized, why is
it not defaulting to mixed-block groups on a 100MiB fallocated file? I
thought mixed-bg was the default below a certain size like 2GiB or
whatever?
On 9/11/16, Chris Murphy wrote:
> Something else that's screwy in that bug that I just realized, why is
> it not defaulting to mixed-block groups on a 100MiB fallocated file? I
> thought mixed-bg was the default below a certain size like 2GiB or
> whatever?
>> With an ordinary partition on a sing
On 2016-09-12 08:33, Jeff Mahoney wrote:
On 9/9/16 8:47 PM, Austin S. Hemmelgarn wrote:
A couple of other things to comment about on this:
1. 'can_overcommit' (the function that the Arch kernel choked on) is
from the memory management subsystem. The fact that that's throwing a
null pointer says
Le dimanche 11 septembre 2016 12:23:23, vous avez écrit :
> First off: On my systems BTRFS definately runs too stable for a research
> project. Actually: I have zero issues with stability of BTRFS on *any* of
> my systems at the moment and in the last half year.
I have been using BTRFS for 3+ ye
On 2016-09-11 15:51, Martin Steigerwald wrote:
Am Sonntag, 11. September 2016, 19:46:32 CEST schrieb Hugo Mills:
On Sun, Sep 11, 2016 at 09:13:28PM +0200, Martin Steigerwald wrote:
Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan:
* Metadata, and thus mixed-bg, defaults to DUP mode
On 09/12/2016 02:39 PM, David Sterba wrote:
> On Fri, Sep 09, 2016 at 11:37:21PM +0200, Hans van Kranenburg wrote:
>> Hi,
>>
>> While trying to enable skinny metadata on a filesystem, I got this error
>> (after minutes of reading from disk by the program):
>>
>> -# btrfstune -x /dev/xvdb
>> extent-
On Fri, Sep 09, 2016 at 11:37:21PM +0200, Hans van Kranenburg wrote:
> Hi,
>
> While trying to enable skinny metadata on a filesystem, I got this error
> (after minutes of reading from disk by the program):
>
> -# btrfstune -x /dev/xvdb
> extent-tree.c:2688: btrfs_reserve_extent: Assertion `ret`
On 2016-09-11 15:21, Martin Steigerwald wrote:
Am Sonntag, 11. September 2016, 21:56:07 CEST schrieb Imran Geriskovan:
On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote:
Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted:
What is the smallest recommended fs size for btrfs?
On 9/9/16 8:47 PM, Austin S. Hemmelgarn wrote:
> A couple of other things to comment about on this:
> 1. 'can_overcommit' (the function that the Arch kernel choked on) is
> from the memory management subsystem. The fact that that's throwing a
> null pointer says to me either your hardware has issu
On 2016-09-11 13:11, Duncan wrote:
Martin Steigerwald posted on Sun, 11 Sep 2016 14:05:03 +0200 as excerpted:
Just add another column called "Production ready". Then research / ask
about production stability of each feature. The only challenge is: Who
is authoritative on that? I´d certainly ask
On 2016-09-11 09:02, Hugo Mills wrote:
On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote:
Martin Steigerwald wrote:
Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
Thing is: This just seems to be when has a feature been implemented
matrix.
Not when it is conside
On 2016-09-09 15:23, moparisthebest wrote:
On 09/09/2016 02:47 PM, Austin S. Hemmelgarn wrote:
On 2016-09-09 12:12, moparisthebest wrote:
Hi,
I'm hoping to get some help with mounting my btrfs array which quit
working yesterday. My array was in the middle of a balance, about 50%
remaining, wh
On 2016-09-09 14:58, Chris Murphy wrote:
On Thu, Sep 8, 2016 at 5:48 AM, Austin S. Hemmelgarn
wrote:
On 2016-09-07 15:34, Chris Murphy wrote:
I like the idea of matching WWN as part of the check, with a couple of
caveats:
1. We need to keep in mind that in some environments, this can be spoo
Hi,
On 09/12/2016 05:18 PM, Eryu Guan wrote:
On Mon, Sep 12, 2016 at 02:36:59PM +0800, Wang Xiaoguang wrote:
Signed-off-by: Wang Xiaoguang
It's better to describe the test a bit in the commit log, e.g. why this
test is needed etc., which at least could give us some historical
information when
On Mon, Sep 12, 2016 at 02:36:59PM +0800, Wang Xiaoguang wrote:
> Signed-off-by: Wang Xiaoguang
It's better to describe the test a bit in the commit log, e.g. why this
test is needed etc., which at least could give us some historical
information when we look at this case again some time later. I
On 09/09/2016 11:37 PM, Hans van Kranenburg wrote:
>
> While trying to enable skinny metadata on a filesystem, I got this error
> (after minutes of reading from disk by the program):
>
> -# btrfstune -x /dev/xvdb
> extent-tree.c:2688: btrfs_reserve_extent: Assertion `ret` failed.
> btrfstune[0x41
On 09/12/16 09:38, Wang Xiaoguang wrote:
>> Actually even that is not true; both patches seem to be wrong in subtle
>> ways. Naohiro's patch seems to prevent the deletion during balance, whereas
>> yours prevents the cleaner from kicking in.
> Indeed in my patch, I just change "struct mutex delete
hello,
On 09/09/2016 06:56 PM, Holger Hoffstätte wrote:
On 09/09/16 12:18, Holger Hoffstätte wrote:
On Fri, 09 Sep 2016 16:17:48 +0800, Wang Xiaoguang wrote:
cleaner_kthread() may run at any time, in which it'll call
btrfs_delete_unused_bgs()
to delete unused block groups. Because this work
On Mon 12-09-16 10:46:56, Dave Chinner wrote:
> On Fri, Sep 09, 2016 at 10:17:43AM +0200, Jan Kara wrote:
> > On Mon 22-08-16 13:35:01, Josef Bacik wrote:
> > > Provide a mechanism for file systems to indicate how much dirty metadata
> > > they
> > > are holding. This introduces a few things
> >
Hi,
On 08/30/2016 12:22 AM, David Sterba wrote:
On Thu, Aug 25, 2016 at 01:20:59PM +0800, Wang Xiaoguang wrote:
Signed-off-by: Wang Xiaoguang
---
cmds-check.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index 0ddfd24..1cd0421 100644
--- a/cmds-check.c
70 matches
Mail list logo
