Re: discard on SSDs quickly causes backup trees to vanish

On Fri, Nov 10, 2017 at 8:48 PM, Qu Wenruo wrote: > > Check the original post. > It only gives the magic number, it's not saying if it's from backup root. > > If it's dumped from running fs (it's completely possible) then it's the > problem I described. There are two

Re: discard on SSDs quickly causes backup trees to vanish

On 2017年11月11日 11:13, Hans van Kranenburg wrote: > On 11/11/2017 03:30 AM, Qu Wenruo wrote: >> >> On 2017年11月11日 09:54, Hans van Kranenburg wrote: >>> On 11/11/2017 12:52 AM, Chris Murphy wrote: Hardware: HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1, which is an NVMe

btrfs test bed

Hi, I'm trying to setup a public test bed for btrfs. Idea is to quickly test user scripts and check its valid or not for specific kernel/btrfs-progs versions. Also keep running them daily and record/save the logs. Its ran for few days and results can be view on below link[2]. If you have

Re: discard on SSDs quickly causes backup trees to vanish

On 11/11/2017 03:30 AM, Qu Wenruo wrote: > > On 2017年11月11日 09:54, Hans van Kranenburg wrote: >> On 11/11/2017 12:52 AM, Chris Murphy wrote: >>> Hardware: >>> HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1, which is an NVMe >>> drive. >>> >>> Kernels: >>> various but definitely 4.12.0

Re: discard on SSDs quickly causes backup trees to vanish

On 2017年11月11日 09:54, Hans van Kranenburg wrote: > On 11/11/2017 12:52 AM, Chris Murphy wrote: >> Hardware: >> HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1, which is an NVMe >> drive. >> >> Kernels: >> various but definitely 4.12.0 through 4.13.10 >> >> Problem: >> Within seconds of

Re: discard on SSDs quickly causes backup trees to vanish

On 11/11/2017 12:52 AM, Chris Murphy wrote: > Hardware: > HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1, which is an NVMe > drive. > > Kernels: > various but definitely 4.12.0 through 4.13.10 > > Problem: > Within seconds of the super being updated to point to a new root tree, > the

discard on SSDs quickly causes backup trees to vanish

Hardware: HP Spectre which contains a SAMSUNG MZVLV256HCHP-000H1, which is an NVMe drive. Kernels: various but definitely 4.12.0 through 4.13.10 Problem: Within seconds of the super being updated to point to a new root tree, the old root tree cannot be read with btrfs-debug-tree. Example: $

Re: btrfs check lowmem vs original

Resurrecting this old thread because I'm still seeing these errors. On Thu, Mar 16, 2017 at 6:54 PM, Qu Wenruo wrote: > > > At 03/17/2017 07:22 AM, Chris Murphy wrote: >> >> With kernel 4.10.3, and btrfs-progs 4.10, I'm still seeing the >> following errors only with

Re: how to run balance successfully (No space left on device)?

On 10.11.2017 22:51 Chris Murphy wrote: >> Combined with evidence that "No space left on device" during balance can >> lead to various file corruption (we've witnessed it with MySQL), I'd day >> btrfs balance is a dangerous operation and decision to use it should be >> considered very thoroughly.

Re: how to run balance successfully (No space left on device)?

On Fri, Nov 10, 2017 at 12:42 AM, Tomasz Chmielewski wrote: > On 2017-11-07 23:49, E V wrote: > >> Hmm, I used to see these phantom no space issues quite a bit on older >> 4.x kernels, and haven't seen them since switching to space_cache=v2. >> So it could be space cache

Re: [PATCH 2/6] writeback: allow for dirty metadata accounting

On Fri, Nov 10, 2017 at 03:25:33PM +1100, Dave Chinner wrote: > On Thu, Nov 09, 2017 at 02:30:57PM -0500, Josef Bacik wrote: > > From: Josef Bacik > > > > Provide a mechanism for file systems to indicate how much dirty metadata > > they > > are holding. This introduces a few

Re: [PATCH v4] Btrfs: add support for fallocate's zero range operation

On 4.11.2017 06:07, fdman...@kernel.org wrote: > From: Filipe Manana > > This implements support the zero range operation of fallocate. For now > at least it's as simple as possible while reusing most of the existing > fallocate and hole punching infrastructure. > >

[PATCH][v2] btrfs: don't bug_on with enomem in __clear_state_bit

From: Josef Bacik Since we're allocating under atomic we could every easily enomem, so if that's the case and we can block then loop around and try to allocate the prealloc not under a lock. We also saw this happen during try_to_release_page in production, in which case it's

Re: [PATCH 2/2] btrfs-progs: Replace some BUG_ON by return

Hi Gu, I applied these two patches: https://patchwork.kernel.org/patch/9939879/ https://patchwork.kernel.org/patch/9939881/ Still the test "sudo make TEST=003\* test-fuzz" is failing like: btrfs-progs/btrfs check --check-data-csum btrfs-progs/tests/fuzz-tests/images/bko-156731.raw.restored

Re: [PATCH 2/4] Btrfs: fix data corruption in raid6

On 2017年11月10日 08:54, Qu Wenruo wrote: > > > On 2017年11月10日 08:12, Liu Bo wrote: >> On Thu, Nov 09, 2017 at 05:29:25PM +0800, Anand Jain wrote: >>> >>> >>> On 11/09/2017 03:53 AM, Liu Bo wrote: On Tue, Nov 07, 2017 at 04:32:55PM +0800, Anand Jain wrote: > > > On 11/02/2017

Re: [PATCH 3/3] btrfs-progs: qgroup: cleanup __qgroup_search, no functional change

On Thu, Nov 09, 2017 at 05:51:48PM +0100, David Sterba wrote: >On Tue, Oct 31, 2017 at 05:13:45PM +0800, Lu Fengqi wrote: >> 1. Use goto instead of while (1) to reduce the level of indentation > >I'd rather avoid this goto pattern in new code, using while is ok. If >the indentation depth becomes

[PATCH] btrfs-progs: lowmem check: Reword an unclear error message about file extent gap

This error occurs when no_holes is not set, but there is a gap before the file extent. Signed-off-by: Lu Fengqi --- Really ashamed, I made the mistake about the meaning of this word. cmds-check.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git