On Fri, Mar 14, 2014 at 10:44:04PM +0000, Hugo Mills wrote: > On Fri, Mar 14, 2014 at 02:51:22PM -0400, Josef Bacik wrote: > > On 03/13/2014 06:16 PM, Hugo Mills wrote: > > >On Thu, Mar 13, 2014 at 03:42:13PM -0400, Josef Bacik wrote: > > >>Lets try this again. We can deadlock the box if we send on a box and try > > >>to > > >>write onto the same fs with the app that is trying to listen to the send > > >>pipe. > > >>This is because the writer could get stuck waiting for a transaction > > >>commit > > >>which is being blocked by the send. So fix this by making sure looking > > >>at the > > >>commit roots is always going to be consistent. We do this by keeping > > >>track of > > >>which roots need to have their commit roots swapped during commit, and > > >>then > > >>taking the commit_root_sem and swapping them all at once. Then make sure > > >>we > > >>take a read lock on the commit_root_sem in cases where we search the > > >>commit root > > >>to make sure we're always looking at a consistent view of the commit > > >>roots. > > >>Previously we had problems with this because we would swap a fs tree > > >>commit root > > >>and then swap the extent tree commit root independently which would cause > > >>the > > >>backref walking code to screw up sometimes. With this patch we no longer > > >>deadlock and pass all the weird send/receive corner cases. Thanks, > > > > > > There's something still going on here. I managed to get about twice > > >as far through my test as I had before, but I again got an "unexpected > > >EOF in stream", with btrfs send returning 1. As before, I have this in > > >syslog: > > > > > >Mar 13 22:09:12 s_src@amelia kernel: BTRFS error (device sda2): did not > > >find backref in send_root. inode=1786631, offset=825257984, > > >disk_byte=36504023040 found extent=36504023040\x0a > > > > > > > I just noticed that the offset you have there is freaking gigantic, > > like 700mb, which is way larger than what an extent should be. Here > > is a newer debug patch, just chuck the old on and put this instead > > and re-run > > > > http://paste.fedoraproject.org/85486/39482301 > > That last run, with the above patch, failed again, at approximately > the same place again. The only output in dmesg is: > > [ 6488.168469] BTRFS error (device sda2): did not find backref in send_root. > inode=1786631, offset=825257984, disk_byte=36504023040 found > extent=36504023040, len=1294336
root@amelia:~# btrfs insp ino 1786631 / //srv/vm/armand.img root@amelia:~# ls -l /srv/vm/armand.img -rw-rw-r-- 1 root kvm 4000000000 Jan 30 08:11 /srv/vm/armand.img root@amelia:~# filefrag /srv/vm/armand.img /srv/vm/armand.img: 17436 extents found This is a VM image, not currently operational. It probably has sparse extents in it somewhere. The full filefrag -ev output is at [1], but the offset it's complaining about is 825257984 = 201479 4k blocks: ext: logical_offset: physical_offset: length: expected: flags: 17200: 201478.. 201478: 7220724.. 7220724: 1: 8923002: 17201: 201479.. 201481: 8912386.. 8912388: 3: 7220725: 17202: 201482.. 201482: 8923002.. 8923002: 1: 8912389: This seems unexceptional. Hugo. [1] http://carfax.org.uk/files/temp/filefrag.txt -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- "Can I offer you anything? Tea? Seedcake? --- Glass of Amontillado?"
signature.asc
Description: Digital signature
