On Mon, Jan 11, 2016 at 5:33 PM, cheater00 . <cheater00@xxxxxxxxx> wrote: > After unmounting: > [251818.992992] BTRFS error (device sdc1): cleaner transaction attach > returned -30 > > and remounting: > [251837.393750] BTRFS info (device sdc1): disk space caching is enabled > > the disk again resizes Data. > > On Mon, Jan 11, 2016 at 5:02 PM, cheater00 . <cheater00@xxxxxxxxx> wrote: >> I triggered the bug again, attaching log. There were some usb resets, >> but they happened 23 minutes before the fs crashed. >> >> At mount, the output of btrfs fi df -g was like this: >> Data, single: total=2080.01GiB, used=2078.80GiB >> System, DUP: total=0.01GiB, used=0.00GiB >> System, single: total=0.00GiB, used=0.00GiB >> Metadata, DUP: total=5.50GiB, used=3.73GiB >> Metadata, single: total=0.01GiB, used=0.00GiB >> GlobalReserve, single: total=0.50GiB, used=0.00GiB >> >> Now it is: >> Data, single: total=2094.01GiB, used=2092.26GiB >> System, DUP: total=0.01GiB, used=0.00GiB >> System, single: total=0.00GiB, used=0.00GiB >> Metadata, DUP: total=5.50GiB, used=3.79GiB >> Metadata, single: total=0.01GiB, used=0.00GiB >> GlobalReserve, single: total=0.50GiB, used=0.00GiB The Data increments with 1G (or 10G?) chunks if there is no well-fitting space in existing chunks. >> The file being copied at the time was 954 MB. The space cache faults get repaired automatically, that is not an issue. Also your fs gives no errors when doing a check. The sort of files you write is nothing difficult for btrfs, even not over a stable usb2 connection. I am writing/incrementing files of ~50G, also C-sources etc over an old usb2 link since 2 years Also balancing many hours over this link. I have not seen resets however (grepped /var/log/messages). The usb2 link is an 2T usb3 disk plugged into an usb2 port. In usb3 port it isn't even recognised. I also have a usb3 3.5 inch dock that produces resets with a 4T harddisk since kernel 4.x (was 4.1.x or so, it was a dd full disk copy). Also if you have too many ATA resets caused by whatever or short disconnects, btrfs might get in trouble; it can't handle bad disks/IO very well currently. -- 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
