On Sun, Jan 5, 2020 at 7:17 AM Christian Wimmer <telefonchris@xxxxxxxxxx> wrote: > > Seems that I am using fstrim (I did not know this, what is it?): Frees unused blocks from underlying storage: in the case of sparse files it punches holds, for thin provisioning it frees logical extents back to the pool, and for real physical SSDs it informs the firmware those blocks are no longer used and can be garbage collected. Most bugs in this area have either been fixed by firmware updates by manufacturers for the SSD, or they've been blacklisted in the kernel so that FITRIM is a no op. > > BTW, sda2 is here my root partition which is practically the same configuration (just smaller) than the 12TB hard disc > > 2020-01-03T11:30:47.479028-03:00 linux-ze6w kernel: [1297857.324177] sda2: rw=2051, want=532656128, limit=419430400 > 2020-01-03T11:30:47.479538-03:00 linux-ze6w kernel: [1297857.324658] BTRFS warning (device sda2): failed to trim 1 device(s), last error -5 > 2020-01-03T11:30:48.376543-03:00 linux-ze6w fstrim[27910]: fstrim: /opt: FITRIM ioctl failed: Input/output error > 2020-01-03T11:30:48.378998-03:00 linux-ze6w kernel: [1297858.223675] attempt to access beyond end of device > 2020-01-03T11:30:48.379012-03:00 linux-ze6w kernel: [1297858.223677] sda2: rw=3, want=421570540, limit=419430400 Yeah that's a problem. That may not be *the* problem, but there is confusion here. What is /dev/sda? This is a virtual drive inside the guest VM? And is backed by a file on the Promise storage? What about /dev/sdb? Same thing? You're only having a problem with /dev/sdb, which contains a Btrfs file system. But if its storage stack is the same as /dev/sda, then the FITRIM problem might be related, we just don't have logs proving it. What do you get for 'sudo systemctl status fstrim.timer' ? While it might be simple to just disable the fstrim.timer if it's enabled; I don't know that this tells you whether there might be other problems with the storage stack somewhere. The fact that this particular FITRIM command is trying to access beyond the end of the device, means there is confusion about /dev/sda size. Is that transient and related to the resize maybe not yet having completed? Or is it a persistent problem that could affect the mapping in otherwise valid regions inside this virtual block device? What should be true is FITRIM inside a guest VM either completely fails (unmap or trim are not advertised and therefore FITRIM fails safely) or it completely succeeds. You shouldn't get corruptions and you shouldn't get the message you're seeing. So my advice is trying to figure out why that's happening. And also if logs show whether it has ever happened for /dev/sdb -- Chris Murphy
