FYI, unmounted the filesystem and it checked clean: # btrfs check /dev/sdd Checking filesystem on /dev/sdd UUID: 550c0f77-8f75-40f3-a64e-42c87a0c8e8d checking extents checking free space cache checking fs roots checking csums checking root refs found 116808409085477 bytes used err is 0 total csum bytes: 113927723420 total tree bytes: 146420203520 total fs tree bytes: 19490373632 total extent tree bytes: 6762332160 btree space waste bytes: 9826655374 file data blocks allocated: 117763247816704 referenced 121374972489728 btrfs-progs v4.1.2 mounted again no problems, deleted a couple of snapshots to make it free something and now rsync is running again fine. On Thu, Aug 20, 2015 at 10:07 AM, E V <eliventer@xxxxxxxxx> wrote: > Thanks for looking, let me know if you need any other info. I haven't > touched the system yet, but it appears I'll need to unmount to btrfs > check or mount rw,recovery to try and get it working again. Who knows > what will happen then? I can leave it as if for a few days if it will > help any diagnosis. Thanks again. > > On Wed, Aug 19, 2015 at 11:17 PM, Anand Jain <anand.jain@xxxxxxxxxx> wrote: >> >> two to dig more.. >> >>> Aug 16 04:41:31 [1082957.226817] BTRFS: error (device sdb) in >>> __btrfs_free_extent:6235: errno=-28 No space left >>> Aug 16 04:41:31 [1082957.226819] BTRFS info (device sdb): forced readonly >> >> >> :: >> >>> Aug 16 04:41:31 [1082957.289289] BTRFS: error (device sdb) in >>> cleanup_transaction:1692: errno=-5 IO failure >> >> >> 1. >> We probably need to understand what kicked in readonly. is it >> -28 (No space left) OR -5 (EIO). >> >> 2. >> There are no media errors from the block layer, hope we are not >> fabricating the EIO in the FS layer... thats wrong. >> >> digging more. >> >> Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
