Re: btrfs: relocation: Fix leaking qgroups numbers on data extents

On 07/29/2016 08:06 PM, Qu Wenruo wrote: > Hi, Goldwyn, > > This patch is replaced by the following patchset: > https://patchwork.kernel.org/patch/9213915/ > https://patchwork.kernel.org/patch/9213913/ > > Would you mind testing the new patch? > Sorry, it fails. Actually, the previous patch

Re: Btrfs send to send out metadata and data separately

On 29/07/16 13:40, Qu Wenruo wrote: > Cons: > 1) Not full fs clone detection >Such clone detection is only inside the send snapshot. > >For case that one extent is referred only once in the send snapshot, >but also referred by source subvolume, then in the received >subvolume, it

systemd KillUserProcesses=yes and btrfs scrub

Short version: When systemd-logind login.conf KillUserProcesses=yes, and the user does "sudo btrfs scrub start" in e.g. GNOME Terminal, and then logs out of the shell, the user space operation is killed, and btrfs scrub status reports that the scrub was aborted. [1] I think what's going on is the

Re: [PATCH] btrfs: Change RAID stripesize to a user-configurable option

Any comments? On Thu, 28 Jul 2016 13:32:27 +0200 David Sterba wrote: > I'll comment on the overall approach and skip code-specific comments. > > The changelog does not explain why there's a need for a new blockgroup > type and what's the relation to the existing types. It

bad tree blcok start & faild to read chunk root

Hello, from this https://www.spinics.net/lists/linux-btrfs/msg57405.html I still have damaged btrf file system (the partition was recovered. Thanks Chris). When mounting, I get: [15681.255356] BTRFS info (device sda1): disk space caching is enabled [15681.255690] BTRFS error (device sda1):

Fixup direct bi_rw modifiers

bi_rw should be using bio_set_op_attrs to set bi_rw. Signed-off-by: Shaun Tancheff Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: Mike Christie --- Patch is against linux-next tag next-20160729

Re: Balance and subvolume delete causes deadlock and metadata corruption

On 07/31/2016 01:18 AM, Hans van Kranenburg wrote: > blahblahblahblahblalahba > > Doing a btrfs check now on the block device, will fup with the output. > Output so far: -# btrfs check /dev/xvdc 2>&1 | tee btrfs-check-xvdc checking extents ref mismatch on [3649516437504 16384] extent item 0,

Balance and subvolume delete causes deadlock and metadata corruption

Hi, tl;dr: concurrent metadata balance and subvol delete caused deadlock and metadata corruption. could mount ro, copied data off of the filesystem. filesystem still available for science, can possibly mount rw, but crashes when space_tree v2 bails out when it sees the metadata corruption.

Re: btrfs: relocation: Fix leaking qgroups numbers on data extents

On 07/30/2016 11:57 PM, Goldwyn Rodrigues wrote: On 07/29/2016 08:06 PM, Qu Wenruo wrote: Hi, Goldwyn, This patch is replaced by the following patchset: https://patchwork.kernel.org/patch/9213915/ https://patchwork.kernel.org/patch/9213913/ Would you mind testing the new patch? Sorry,

Re: systemd KillUserProcesses=yes and btrfs scrub

On Sat, Jul 30, 2016 at 2:02 PM, Chris Murphy wrote: > Short version: When systemd-logind login.conf KillUserProcesses=yes, > and the user does "sudo btrfs scrub start" in e.g. GNOME Terminal, and Same thing with Xfce, so it's not DE specific. (Unsuprising.) I inflated

Re: Balance and subvolume delete causes deadlock and metadata corruption

On 07/31/2016 02:13 AM, Hans van Kranenburg wrote: > On 07/31/2016 01:18 AM, Hans van Kranenburg wrote: >> blahblahblahblahblalahba >> >> Doing a btrfs check now on the block device, will fup with the output. >> > > Output so far: > > -# btrfs check /dev/xvdc 2>&1 | tee btrfs-check-xvdc >

OOM killer invoked during btrfs send/recieve on otherwise idle machine

Tonight the OOM killer got invoked during backup of /: [Jul31 01:56] kthreadd invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, oom_score_adj=0 [ +0.04] CPU: 3 PID: 2 Comm: kthreadd Not tainted 4.7.0-06816-g797cee982eef-dirty #37 [ +0.00] Hardware

Re: btrfs on sparc64 results in kernel stack trace in 1 minute test

On Sat, Jul 30, 2016 at 12:52 AM, Jeff Mahoney wrote: >> On Jul 29, 2016, at 5:11 PM, Anatoly Pugachev wrote: >> and in logs: >> >> Jul 30 00:05:48 nvg5120 kernel: BTRFS info (device loop0): inode >> 227514 still on the orphan list >> Jul 30 00:06:01 nvg5120