Re: 12 TB btrfs file system on virtual machine broke again

[Chris Murphy <lists@colorremedies.com>]

On Sun, Jan 5, 2020 at 7:17 AM Christian Wimmer <telefonchris@icloud.com> 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