On Tuesday, 23 June 2020 9:13:04 PM AEST Nikolay Borisov wrote: > > # btrfs fi usa . > > Overall: > > Device size: 62.50GiB > > Device allocated: 19.02GiB > > Device unallocated: 43.48GiB > > Device missing: 0.00B > > Used: 16.26GiB > > Free (estimated): 44.25GiB (min: 22.51GiB) > > Data ratio: 1.00 > > Metadata ratio: 2.00 > > Global reserve: 17.06MiB (used: 0.00B) > > > > Data,single: Size:17.01GiB, Used:16.23GiB (95.43%) > > /dev/sdc1 17.01GiB > > > > Metadata,DUP: Size:1.00GiB, Used:17.19MiB (1.68%) > > /dev/sdc1 2.00GiB > > > > System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%) > > /dev/sdc1 16.00MiB > > > > Unallocated: > > /dev/sdc1 43.48GiB > > Do you use compression on this filesystem i.e have you mounted with > -ocompression= option ? No, used the default mount with the Debian build of kernel 5.6.14. Everything was pretty much default with it. Made a filesystem, copied a bunch of large files to it, tried to read it, got problems. It was a storage device I suspected of having errors, copying files to/from it with BTRFS is a good way of exposing errors. > Based on this data alone it's evident that you don't really have mirrors > of the data, in this case having experienced the checksum errors should > have indeed resulted in error counters being incremented. I'll look into > this. Thanks. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
