And this one as well.
-- Forwarded message -
From: Chris Murphy
Date: Fr., 7. Sep. 2018 um 23:53 Uhr
Subject: Re: btrfs send hung in pipe_wait
To: Stefan Loewen
Cc: Chris Murphy
On Fri, Sep 7, 2018 at 3:19 PM, Stefan Loewen wrote:
> Now I also tested with Fedora 28 (li
Oops. Forgot CCing the mailinglist
-- Forwarded message -
From: Stefan Loewen
Date: Fr., 7. Sep. 2018 um 23:19 Uhr
Subject: Re: btrfs send hung in pipe_wait
To: Chris Murphy
No it does not only happen in VirtualBox. I already tested the following:
- Manjaro baremetal (btrfs
PREEMPT Fri Aug 24 16:33:26 UTC 2018 x86_64 GNU/Linux"
Same results. btrfs-send freezes.
Am Fr., 7. Sep. 2018 um 17:44 Uhr schrieb Chris Murphy
:
>
> On Fri, Sep 7, 2018 at 6:47 AM, Stefan Loewen wrote:
> > Well... It seems it's not the hardware.
> > I ran a long SMA
hat much time for helping me find the problem
here, Chris. Very much appreciated!
Am Fr., 7. Sep. 2018 um 05:29 Uhr schrieb Chris Murphy
:
>
> On Thu, Sep 6, 2018 at 2:16 PM, Stefan Loewen wrote:
>
> > Data,single: Size:695.01GiB, Used:653.69GiB
> > /dev/sdb1 695.01GiB
&g
, Stefan Loewen wrote:
Output of the commands is attached.
fdisk
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
smart
Sector Sizes: 512 bytes logical, 4096 bytes physical
So clearly the case is lying about the actual physical sector
Output of the commands is attached.
The broken-sector-theory sounds plausible and is compatible with my new
findings:
I suspected the problem to be in one specific directory, let's call it
"broken_dir".
I created a new subvolume and copied broken_dir over.
- If I copied it with cp --reflink,
Update:
It seems like btrfs-send is not completely hung. It somewhat regularly
wakes up every hour to transfer a few bytes. I noticed this via a
periodic 'ls -l' on the snapshot file. These are the last outputs
(uniq'ed):
-rw--- 1 root root 1492797759 Sep 6 08:44 intenso_white.snapshot
