Re: Btrfs send to send out metadata and data separately

At 07/29/2016 09:14 PM, Libor Klepáč wrote: Hello, just a little question on receiver point 0), see bellow Dne pátek 29. července 2016 20:40:38 CEST, Qu Wenruo napsal(a): Hi Filipe, and maintainers, Receive will do the following thing first before recovering the subvolume/snapshot: 0)

[PATCH v4] btrfs: fix fsfreeze hang caused by delayed iputs deal

When running fstests generic/068, sometimes we got below deadlock: xfs_io D 8800331dbb20 0 6697 6693 0x0080 8800331dbb20 88007acfc140 880034d895c0 8800331dc000 880032d243e8 fffe 880032d24400 0001 8800331dbb38

btrfs fi usage bug during shrink

Hi, all. I was resizing (shrinking) a btrfs partition, and figured I'd check in on how it was going with "btrfs fi usage." It was quite startling: $ sudo btrfs fi usage /mnt/ Overall: Device size: 370.00GiB Device allocated:372.03GiB Device unallocated:

Re: Btrfs send to send out metadata and data separately

At 07/31/2016 02:49 AM, g.bt...@cobb.uk.net wrote: 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

Re: systemd KillUserProcesses=yes and btrfs scrub

Chris Murphy posted on Sat, 30 Jul 2016 14:02:17 -0600 as excerpted: > 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

Re: systemd KillUserProcesses=yes and btrfs scrub

On 30.07.2016 22:02, 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 > then logs out of the shell, the user space operation is killed, and > btrfs scrub status reports that the

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

[CC Mel and linux-mm] On Sun 31-07-16 07:11:21, Markus Trippelsdorf wrote: > 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 This a kernel stack allocation. >

[GIT PULL] Btrfs

Hi Linus, This is part one of my btrfs pull, and you can find it in my for-linus-4.8 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.8 This pull is dedicated to Josef's enospc rework, which we've been testing for a few releases now. It fixes some early

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

On Fri, Jul 15, 2016 at 2:31 AM, Omar Sandoval wrote: > From: Omar Sandoval > > So it turns out that the free space tree bitmap handling has always been > broken on big-endian systems. Totally my bad. > > Patch 1 fixes this. Technically, it's a disk format

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

On 2016.07.31 at 17:10 +0200, Michal Hocko wrote: > [CC Mel and linux-mm] > > On Sun 31-07-16 07:11:21, Markus Trippelsdorf wrote: > > Tonight the OOM killer got invoked during backup of /: > > > > [Jul31 01:56] kthreadd invoked oom-killer: > >

Re: systemd KillUserProcesses=yes and btrfs scrub

On Sun, Jul 31, 2016 at 4:56 AM, Gabriel C wrote: > > > On 30.07.2016 22:02, 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 >> then logs out of the shell,