On Feb 14, 2013, at 1:59 AM, Hugo Mills <h...@carfax.org.uk> wrote: >> >> Data, RAID1: total=2.66TB, used=2.66TB > > This is the amount of actual useful data (i.e. what you see with du > or ls -l). Double this (because it's RAID-1) to get the number of > bytes or raw storage used.
Right, the decoder ring. Effectively no outsiders will understand this. It contradicts the behavior of conventional df with btrfs volumes. And it becomes untenable with per subvolume profiles. >> Total devices 2 FS bytes used 1.64TB >> devid 1 size 2.73TB used 1.64TB path /dev/sdi1 >> devid 2 size 2.73TB used 2.67TB path /dev/sde1 > > This is the amount of raw disk space allocated. The total of used > here should add up to twice the "total" values above (for > Data+Metadata+System). I'm mostly complaining about the first line. If 2.67TB of writes to sde1 are successful enough to be stated as "used" on that device, then FS bytes used should be at least 2.67TB. > >> So I can't tell if it's ~1.64TB copied or 2.6TB. > > Looks like /dev/sdi1 isn't actually being written to -- it should > be the same allocation as /dev/sde1. Yeah he's getting a lot of these, and I don't know what it is: > Feb 14 08:32:30 nerv kernel: [180511.760850] lost page write due to I/O error > on /dev/sdd1 It's not tied to btrfs or libata so I don't think it's the drive itself reporting the write error. I think maybe the kernel has become confused as a result of the original ICRC ABRT, and the subsequent change from sdd to sdi. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
