On Fri, Sep 7, 2018 at 6:47 AM, Stefan Loewen <stefan.loe...@gmail.com> wrote: > Well... It seems it's not the hardware. > I ran a long SMART check which ran through without errors and > reallocation count is still 0.
That only checks the drive, it's an internal test. It doesn't check anything else, including connections. Also you do have a log with a read error and a sector LBA reported. So there is a hardware issue, it could just be transient. > So I used clonezilla (partclone.btrfs) to mirror the drive to another > drive (same model). > Everything copied over just fine. No I/O error im dmesg. > > The new disk shows the same behavior. So now I'm suspicious of USB behavior. Like I said earlier, when I've got USB enclosed drives connect to my NUC, regardless of file system, I routinely get hangs and USB resets. I have to connect all of my USB enclosed drives to a good USB hub, or I have problems. > So I created another subvolume, reflinked stuff over and found that it > is enough to reflink one file, create a read-only snapshot and try to > btrfs-send that. It's not happening with every file, but there are > definitely multiple different files. The one I tested with is a 3.8GB > ISO file. > Even better: > 'btrfs send --no-data snap-one > /dev/null' > (snap-one containing just one iso file) hangs as well. Do you have a list of steps to make this clear? It sounds like first you copy a 3.8G ISO file to one subvolume, then reflink copy it into another subvolume, then snapshot that 2nd subvolume, and try to send the snapshot? But I want to be clear. I've got piles of reflinked files in snapshots and they send OK, although like I said I do get sometimes a 15-30 second hang during sends. > Still dmesg shows no IO errors, only "INFO: task btrfs-transacti:541 > blocked for more than 120 seconds." with associated call trace. > btrfs-send reads some MB in the beginning, writes a few bytes and then > hangs without further IO. > > copying the same file without --reflink, snapshotting and sending > works without problems. > > I guess that pretty much eleminates bad sectors and points towards > some problem with reflinks / btrfs metadata. That's pretty weird. I'll keep trying and see if I hit this. What happens if you downgrade to an older kernel? Either 4.14 or 4.17 or both. The send code is mainly in the kernel, where the receive code is mainly in user space tools, for this testing you don't need to downgrade user space tools. If there's a bug here, I expect it's kernel. -- Chris Murphy
