RE: linux 4.7.2 & btrfs & rsync & OOM gone crazy

[Paul Jones]

> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of E V
> Sent: Saturday, 27 August 2016 5:01 AM
> To: linux-btrfs 
> Subject: linux 4.7.2 & btrfs & rsync & OOM gone crazy
> 
> Just upgraded from 4.6.5 to 4.7.2 for my btrfs backup server with 32GB of
> ram. Only thing that run's on it is an rsync of an NFS filesystem to the local
> btrfs. Cached mem tends to hang out around 26-30GB, but with 4.7.2 the
> OOM is now going crazy and trying to kill whatever it can including my ssh and
> rsync process. Anyone seen anything similar?
> Trying it again with /proc/sys/vm/swappiness at 0 will see if that makes a
> difference.


Yes, I had the same issue on a backup VM that only has 1G ram - rsync 
constantly is killed by OOM. Doesn't happen on the main machine with 24G ram.

Paul.
N�r��yb�X��ǧv�^�)޺{.n�+{�n�߲)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

[Omar Sandoval]

On Fri, Aug 26, 2016 at 02:06:29PM +0300, Anatoly Pugachev wrote:
> On Thu, Aug 18, 2016 at 11:33 PM, Omar Sandoval  wrote:
> > On Tue, Jul 19, 2016 at 03:25:16PM -0400, Chris Mason wrote:
> >> On 07/19/2016 12:06 PM, Chandan Rajendra wrote:
> >>
> >> Omar, looks like we need to make the patched kernel refuse to mount free
> >> space trees without a new incompat bit set.  That way there won't be any
> >> surprises for the people that have managed to get a free space tree saved.
> >> Can it please printk a message about clearing the tree and mounting again?
> >>
> > Sorry it took me a month to get around to this, I tried to implement
> > this a couple of ways but I really don't like it. Basically, when we see
> > that we're missing the compat bit, we have to assume that the free space
> > tree was created with the same endianness that we're running on now.
> > That could lead to a false positive if, say, we created the filesystem
> > on a little-endian machine with an old kernel but are using it on a
> > big-endian system, or a false negative if it was created on a big-endian
> > machine with an old kernel but we're using it on a little-endian
> > machine.
> >
> > There's also the question of making it a compat bit vs an incompat bit.
> > An incompat bit makes sure that we don't break the filesystem by
> > mounting it on an old big-endian kernel, but needlessly breaks
> > backwards-compatibility for little-endian.
> >
> > I'd be much happier if we could just pretend this never happened. Here's
> > the patch, anyways, for the sake of completeness. Chris, what do you
> > think?
> 
> Omar,
> 
> I can't load btrfs module with this patch applied to 4.8.0-rc3+ (git
> v4.8-rc3-39-g61c0457)
> on "modprobe btrfs" i'm getting the following in the logs and module
> does not load:
> 
> Btrfs loaded, crc32c=crc32c-generic, debug=on, assert=on
> BTRFS: selftest: sectorsize: 8192  nodesize: 8192
> BTRFS: selftest: Running btrfs free space cache tests
> BTRFS: selftest: Running extent only tests
> BTRFS: selftest: Running bitmap only tests
> BTRFS: selftest: Running bitmap and extent tests
> BTRFS: selftest: Running space stealing from bitmap to extent
> BTRFS: selftest: Free space cache tests finished
> BTRFS: selftest: Running extent buffer operation tests
> BTRFS: selftest: Running btrfs_split_item tests
> BTRFS: selftest: Running extent I/O tests
> BTRFS: selftest: Running find delalloc tests
> BTRFS: selftest: Running extent buffer bitmap tests
> BTRFS: selftest: Setting straddling pages failed
> BTRFS: selftest: Extent I/O tests finished

Is this with the whole patchset + this patch? You still need the patch
set for this to actually work, the extra patch is just some extra
checks.

-- 
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs progs release 4.7.1

[Luis Henriques]

David Sterba  writes:

> On Fri, Aug 26, 2016 at 12:24:10AM +0100, Luis Henriques wrote:
>> On Thu, Aug 25, 2016 at 07:47:27PM +0200, David Sterba wrote:
>> > Hi,
>> > 
>> > btrfs-progs 4.7 have been released. Though it's a minor version release, 
>> > there
>> > are changes that could be considered big but I don't see a reason to hold 
>> > them
>> > until 4.8 is released.
>> ...
>> > Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
>> > Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
>> 
>> Looks like the master branch has not been pushed, although I can see the 
>> v4.7.1
>> (and thus I can actually git reset to this release).
>
> Now pushed.

Cool, thanks!

Cheers,
-- 
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

[Anatoly Pugachev]

On Thu, Aug 18, 2016 at 11:33 PM, Omar Sandoval  wrote:
> On Tue, Jul 19, 2016 at 03:25:16PM -0400, Chris Mason wrote:
>> On 07/19/2016 12:06 PM, Chandan Rajendra wrote:
>>
>> Omar, looks like we need to make the patched kernel refuse to mount free
>> space trees without a new incompat bit set.  That way there won't be any
>> surprises for the people that have managed to get a free space tree saved.
>> Can it please printk a message about clearing the tree and mounting again?
>>
> Sorry it took me a month to get around to this, I tried to implement
> this a couple of ways but I really don't like it. Basically, when we see
> that we're missing the compat bit, we have to assume that the free space
> tree was created with the same endianness that we're running on now.
> That could lead to a false positive if, say, we created the filesystem
> on a little-endian machine with an old kernel but are using it on a
> big-endian system, or a false negative if it was created on a big-endian
> machine with an old kernel but we're using it on a little-endian
> machine.
>
> There's also the question of making it a compat bit vs an incompat bit.
> An incompat bit makes sure that we don't break the filesystem by
> mounting it on an old big-endian kernel, but needlessly breaks
> backwards-compatibility for little-endian.
>
> I'd be much happier if we could just pretend this never happened. Here's
> the patch, anyways, for the sake of completeness. Chris, what do you
> think?

Omar,

I can't load btrfs module with this patch applied to 4.8.0-rc3+ (git
v4.8-rc3-39-g61c0457)
on "modprobe btrfs" i'm getting the following in the logs and module
does not load:

Btrfs loaded, crc32c=crc32c-generic, debug=on, assert=on
BTRFS: selftest: sectorsize: 8192  nodesize: 8192
BTRFS: selftest: Running btrfs free space cache tests
BTRFS: selftest: Running extent only tests
BTRFS: selftest: Running bitmap only tests
BTRFS: selftest: Running bitmap and extent tests
BTRFS: selftest: Running space stealing from bitmap to extent
BTRFS: selftest: Free space cache tests finished
BTRFS: selftest: Running extent buffer operation tests
BTRFS: selftest: Running btrfs_split_item tests
BTRFS: selftest: Running extent I/O tests
BTRFS: selftest: Running find delalloc tests
BTRFS: selftest: Running extent buffer bitmap tests
BTRFS: selftest: Setting straddling pages failed
BTRFS: selftest: Extent I/O tests finished
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Btrfs progs release 4.7.1

[David Sterba]

On Fri, Aug 26, 2016 at 12:24:10AM +0100, Luis Henriques wrote:
> On Thu, Aug 25, 2016 at 07:47:27PM +0200, David Sterba wrote:
> > Hi,
> > 
> > btrfs-progs 4.7 have been released. Though it's a minor version release, 
> > there
> > are changes that could be considered big but I don't see a reason to hold 
> > them
> > until 4.8 is released.
> ...
> > Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
> > Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
> 
> Looks like the master branch has not been pushed, although I can see the 
> v4.7.1
> (and thus I can actually git reset to this release).

Now pushed.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switch raid mode without rebalance?

[Austin S. Hemmelgarn]

On 2016-08-25 18:32, Gert Menke wrote:

Hi,

On 2016-08-25 20:26, Justin Kilpatrick wrote:


I'm not sure why you want to avoid a balance,

I didn't check, but I imagined it would slow down my rsync significantly.
It will slow it down, but I can't tell you exactly how much (there are 
too many variables to give a good answer in this case).



Once you start this command all the new data should follow the new rules.

Ah, now that's interesting.
When the balance is running, df shows 4TB free space; when I cancel the
balance, the free space goes back to a few 100GB.
Regular 'df' isn't to be trusted when dealing with BTRFS, the only 
reason we report anything there is because many things break horribly if 
we don't.


But if the balancing only happens when the disk would otherwise be idle,
and the mere fact that there is a balance process running will cause the
new data to be written in single mode, I'm all set. I would not even
have to wait for the balance to finish after the rsync is done; I could
just cancel it and unmount the disks. A bit hacky, but in this case
totally acceptable.
The balancing operation runs in the foreground (unless you daemonize it 
in a new enough btrfs-progs), it isn't restricted to just using idle 
time, and as explained by Chris Murphy in the other branch of this 
thread, it's not flipping some binary switch telling the FS to write all 
new data in the new profile.


Additionally, while running with multiple profiles while not balancing 
should work, it's pretty much untested, and any number of things may 
break.  Assuming your two disks have similar latency and transfer speed, 
you're almost certainly better off just converting completely to single 
mode (which works like raid0, just at the chunk level instead of the 
block level).  Doing so will likely have near zero impact on 
performance, will also be easier to recover data from if one disk dies, 
and will avoid the mostly untested situation of running with multiple 
chunk profiles.


On a slightly separate note, if your doing backups more frequently than 
once a week, your probably better off just leaving the disks connected 
and running.  Regular load/unload cycles are generally harder on the 
mechanical components in modern disks than just leaving them running 24/7.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux 4.7.2 & btrfs & rsync & OOM gone crazy

[E V]

Just upgraded from 4.6.5 to 4.7.2 for my btrfs backup server with 32GB
of ram. Only thing that run's on it is an rsync of an NFS filesystem
to the local btrfs. Cached mem tends to hang out around 26-30GB, but
with 4.7.2 the OOM is now going crazy and trying to kill whatever it
can including my ssh and rsync process. Anyone seen anything similar?
Trying it again with /proc/sys/vm/swappiness at 0 will see if that
makes a difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux 4.7.2 & btrfs & rsync & OOM gone crazy

[Tomasz Torcz]

On Fri, Aug 26, 2016 at 03:00:48PM -0400, E V wrote:
> Just upgraded from 4.6.5 to 4.7.2 for my btrfs backup server with 32GB
> of ram. Only thing that run's on it is an rsync of an NFS filesystem
> to the local btrfs. Cached mem tends to hang out around 26-30GB, but
> with 4.7.2 the OOM is now going crazy and trying to kill whatever it
> can including my ssh and rsync process. Anyone seen anything similar?

  That's probably OOM regression in 4.7. Could you please test this patch:
https://lkml.org/lkml/2016/8/23/145

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switch raid mode without rebalance?

[Gert Menke]

Hi,

On 2016-08-26 13:52, Austin S. Hemmelgarn wrote:


Regular 'df' isn't to be trusted when dealing with BTRFS, the only
reason we report anything there is because many things break horribly
if we don't.

Yeah, I noticed. Seems to produce a reasonable guess, though.


Additionally, while running with multiple profiles while not balancing
should work, it's pretty much untested, and any number of things may
break.

Oh. Good to know.


Assuming your two disks have similar latency and transfer
speed, you're almost certainly better off just converting completely
to single mode (which works like raid0, just at the chunk level
instead of the block level).

Okay, I see.


On a slightly separate note, if your doing backups more frequently
than once a week, your probably better off just leaving the disks
connected and running.  Regular load/unload cycles are generally
harder on the mechanical components in modern disks than just leaving
them running 24/7.
True. A bit of context: I first want to make a full backup locally, then 
use the disks off-site for nightly incremental backups via internet.


Cheers
Gert
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

heap-use-after-free in btrfsck v4.7-42-g56e9586

[Lukas Lueg]

Hi,

let me draw your attention to
https://bugzilla.kernel.org/show_bug.cgi?id=153641 which is a
heap-use-after-free bug in btrfs-progs v4.7-42-g56e9586 I found while
fuzzing btrfs.

There are more bugs like this. How do you people want them to be reported?

Best regards
Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switch raid mode without rebalance?

[Gert Menke]

Hi Chris,

first off, thank you for the detailled explanations!

On 2016-08-26 01:04, Chris Murphy wrote:

No, it's not a file, directory or subvolume specific command. It
applies to a whole volume.
You are right, but all I was after in the first place was a way to 
change the mode for new data on the whole volume.
But I understand now that there is no simple switch for that. (And to be 
honest it's not overly important, I was just being curious.)



If I add another file, I'll get another data chunk allocated, and
it'll be added to the chunk tree as item 5, and it'll have its own
physical  offset on each device.
And this chunk just uses the same profile as the last one (or the parent 
in the tree), I suppose.



So the point now is, in order to change the profile of a chunk, it has
to be completely rewritten.

That makes sense.


To do what you want is planned, with no work picked up yet as far as I
know. It'd probably involve some work to associate something like an
xattr to let the allocator know which profile the user wants for the
data, and then to allocate it to the proper existing chunk or create a
new chunk with that profile as needed.

I see.

I think it would be very nice to have something like that for the 
different compression modes. For example, use LZ4 for daily use but LZMA 
for the subvolume that stores backups, and no compression at all for 
/boot, so the bootloader doesn't have to know about all the different 
compression algorithms.


Speaking of which, I read here: 
https://btrfs.wiki.kernel.org/index.php/Compression#Why_does_not_du_report_the_compressed_size.3F
that du will not tell me the compressed size of a file. This is very 
counter-intuitive, isn't it?
The reason stated is that some tools apparently determine the 
sparse-ness of a file by comparing the size with the stat.st_blocks 
value.
I do not know if there is a better way to do that, so maybe my argument 
falls apart right here, BUT: this looks to me like working around one 
bug by introducing another. Wouldn't it be better to have a mount option 
"make_du_lie_for_buggy_tools" for those that really need it? BTW, which 
tools would an honest du break, and how? (What harm is there in thinking 
that a compressed file is sparse?)


Thanks!
Gert
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switch raid mode without rebalance?

[Chris Murphy]

On Fri, Aug 26, 2016 at 1:18 PM, Gert Menke  wrote:
> Hi Chris,
>
> first off, thank you for the detailled explanations!
>
> On 2016-08-26 01:04, Chris Murphy wrote:
>>
>> No, it's not a file, directory or subvolume specific command. It
>> applies to a whole volume.
>
> You are right, but all I was after in the first place was a way to change
> the mode for new data on the whole volume.

New chunks, yes in a rudimentary sense (btrfs balance start then
cancel with a dconvert/mconvert), but there's no user control to
provide a hint to the allocator which chunks to put new data into. It
can go into new chunks or old chunks.

Also, I *think* if you cancel the balance, a new balance is not going
to complete the conversion - it will do the balance maintaining the
mixed profile state of existing chunks. So you'd want to do something
like -dconvert=profile,soft -mconvert=profile,soft



>> If I add another file, I'll get another data chunk allocated, and
>> it'll be added to the chunk tree as item 5, and it'll have its own
>> physical  offset on each device.
>
> And this chunk just uses the same profile as the last one (or the parent in
> the tree), I suppose.

I honestly don't know how it determines what the profile will be; it
might be the profile of the chunk with the most recent generation.



https://btrfs.wiki.kernel.org/index.php/Compression#Why_does_not_du_report_the_compressed_size.3F
> that du will not tell me the compressed size of a file. This is very
> counter-intuitive, isn't it?
> The reason stated is that some tools apparently determine the sparse-ness of
> a file by comparing the size with the stat.st_blocks value.
> I do not know if there is a better way to do that, so maybe my argument
> falls apart right here, BUT: this looks to me like working around one bug by
> introducing another. Wouldn't it be better to have a mount option
> "make_du_lie_for_buggy_tools" for those that really need it? BTW, which
> tools would an honest du break, and how? (What harm is there in thinking
> that a compressed file is sparse?)

I don't know anything about this so someone else will have to chime in.

-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux 4.7.2 & btrfs & rsync & OOM gone crazy

[E V]

Interesting, thanks. Patch doesn't apply clean to 4.7.2, but I get the
gist, delete one version of should_compact_retry() and move ifdef so
it only has __alloc_pages_direct_compact(). I'll try it out if my
rsync gets OOM'd again.

On Fri, Aug 26, 2016 at 3:02 PM, Tomasz Torcz  wrote:
> On Fri, Aug 26, 2016 at 03:00:48PM -0400, E V wrote:
>> Just upgraded from 4.6.5 to 4.7.2 for my btrfs backup server with 32GB
>> of ram. Only thing that run's on it is an rsync of an NFS filesystem
>> to the local btrfs. Cached mem tends to hang out around 26-30GB, but
>> with 4.7.2 the OOM is now going crazy and trying to kill whatever it
>> can including my ssh and rsync process. Anyone seen anything similar?
>
>   That's probably OOM regression in 4.7. Could you please test this patch:
> https://lkml.org/lkml/2016/8/23/145
>
> --
> Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
> seeking
> xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
> (LKML)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

fuzzed segv in btrfsck

[Lukas Lueg]

Hi,

let me draw your attention to
https://bugzilla.kernel.org/show_bug.cgi?id=154021 which is a
reproducible segv in btrfs-progs v4.7-42-g56e9586 I found while
fuzzing btrfs.

Best regards
Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Btrfs

[Chris Mason]

Hi Linus,

Please pull my for-linus-4.8 branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
for-linus-4.8

We've queued up a few different fixes in here.  These range from enospc
corners to fsync and quota fixes, and a few targeted at
error handling for corrupt metadata/fuzzing.

Liu Bo (5) commits (+60/-2):
Btrfs: detect corruption when non-root leaf has zero item (+22/-1)
Btrfs: add ASSERT for block group's memory leak (+5/-0)
Btrfs: clarify do_chunk_alloc()'s return value (+9/-0)
Btrfs: fix memory leak of reloc_root (+8/-1)
Btrfs: check btree node's nritems (+16/-0)

Qu Wenruo (4) commits (+191/-53):
btrfs: relocation: Fix leaking qgroups numbers on data extents (+103/-6)
btrfs: qgroup: Fix qgroup incorrectness caused by log replay (+16/-0)
btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent() (+71/-47)
btrfs: backref: Fix soft lockup in __merge_refs function (+1/-0)

Wang Xiaoguang (4) commits (+161/-108):
btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster() 
(+6/-4)
btrfs: divide btrfs_update_reserved_bytes() into two functions (+57/-40)
btrfs: update btrfs_space_info's bytes_may_use timely (+73/-63)
btrfs: fix fsfreeze hang caused by delayed iputs deal (+25/-1)

Jeff Mahoney (3) commits (+45/-18):
btrfs: don't create or leak aliased root while cleaning up orphans (+22/-11)
btrfs: waiting on qgroup rescan should not always be interruptible (+13/-6)
btrfs: properly track when rescan worker is running (+10/-1)

Filipe Manana (1) commits (+8/-4):
Btrfs: fix lockdep warning on deadlock against an inode's log mutex

Anand Jain (1) commits (+19/-8):
btrfs: do not background blkdev_put()

Alex Lyakas (1) commits (+1/-1):
btrfs: flush_space: treat return value of do_chunk_alloc properly

Josef Bacik (1) commits (+1/-0):
Btrfs: fix em leak in find_first_block_group

Total: (20) commits

 fs/btrfs/backref.c |   1 +
 fs/btrfs/ctree.h   |   5 +-
 fs/btrfs/delayed-ref.c |   7 +-
 fs/btrfs/disk-io.c |  56 +--
 fs/btrfs/disk-io.h |   2 +
 fs/btrfs/extent-tree.c | 185 +++--
 fs/btrfs/extent_io.h   |   1 +
 fs/btrfs/file.c|  28 
 fs/btrfs/inode-map.c   |   3 +-
 fs/btrfs/inode.c   |  37 +++---
 fs/btrfs/ioctl.c   |   2 +-
 fs/btrfs/qgroup.c  |  62 ++---
 fs/btrfs/qgroup.h  |  36 --
 fs/btrfs/relocation.c  | 126 ++---
 fs/btrfs/root-tree.c   |  27 +---
 fs/btrfs/super.c   |  16 +
 fs/btrfs/transaction.c |   7 +-
 fs/btrfs/tree-log.c|  21 +-
 fs/btrfs/tree-log.h|   5 +-
 fs/btrfs/volumes.c |  27 +---
 20 files changed, 473 insertions(+), 181 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

[Marc Haber]

hi,

On Thu, Aug 25, 2016 at 05:56:18PM -0600, Chris Murphy wrote:
> Anyway it's a known problem, I don't think it's fixed still. There's a
> lot of enospc work in 4.8 so eventually it'll make sense to give it a
> shot with that kernel.

assuming that I'm willing to try that, will a successful rebalance
with 4.8 fix a filesystem, or is the recommended way still "backup,
format, restore, lose all snapshots"?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html