Post B6Kg0mIVZ6EkEYrUUC by ska@social.treehouse.systems
 (DIR) More posts by ska@social.treehouse.systems
 (DIR) Post #B6JKjnEGYX3Q0Lyef2 by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       ok here's a new one I haven't seen beforepwrite64(156, "\0004\0$-Uxcp8pyZwWc9s6obCh2_0yQJHEd"..., 3584, 0) = -1 EREMOTEIO (Remote I/O error)this is on a completely local filesystem ... ?
       
 (DIR) Post #B6JLzMzhxpQXE69wlU by meph@social.treehouse.systems
       0 likes, 0 repeats
       
       @astraleureka 🤨
       
 (DIR) Post #B6JuvEu3bM6rMyHYFU by ska@social.treehouse.systems
       0 likes, 0 repeats
       
       @astraleureka what even is EREMOTEIO? I have read my share of errno.h files and have never seen that
       
 (DIR) Post #B6KeN1fOu4qqMa3BlA by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @ska I dunno, it's there on all my machines:phendrana:~ eureka% cpp -dM /usr/include/errno.h | grep EREMOTEIO#define EREMOTEIO 121@khm's explanation of a short read makes sense, but I don't see how that's possible in this environment. it's a qemu-kvm instance, the drive is virtio-blk-scsi backed by LVM with no IO errors on the host reported (or in qemu logs). nothing in the guest kernel logs either. I might understand it if the guest filesystem were damaged and it was a *read* but on a *write* ?
       
 (DIR) Post #B6Kg0mIVZ6EkEYrUUC by ska@social.treehouse.systems
       0 likes, 0 repeats
       
       @astraleureka @khm You're right, it's there... I guess I never read that far into the high errno numbers 😖Why a non-NFS-related system call would ever return that, however, I have no idea.
       
 (DIR) Post #B6KyHobC3nJdT9sKTg by khm@hj.9fs.net
       0 likes, 0 repeats
       
       looks like qemu passes scsi errors from host:  https://github.com/qemu/qemu/blob/dc293f60b02ff9a4d51ccae153b1685cc8a34d79/scsi/utils.c#L601but it does it with like three layers of indirection via errno?!I tried to trace this back into the scsi blk driver but lost the thread.  the best I can tell is this happens when the host has to abort a scsi transactionCC: @ska@treehouse.systems
       
 (DIR) Post #B6KyHoqn7nnCFXAmn2 by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @khm @ska I've had experience with legitimate SCSI layer errors passed from host to guest, and they generally always result in EIO (+ usually something in dmesg). In this case the host reports no IO errors. The VM is assigned an LV, the LV is backed by bcache consisting of an 8x SAS mdraid10 + 2x NVMe mdraid1 cache. The counters at each layer show nothing out of the ordinary. I even tried an online fsck in the VM as well as offline from the host, neither with any faults. I also can't reproduce the issue anymore either, it was reliable last night but now it completes without fault. Truly, truly mystified
       
 (DIR) Post #B6KylKMx1BHEOvHnLU by brouhaha@mastodon.social
       0 likes, 0 repeats
       
       @ska @astraleureka You know how the create() system call is misspelled? This is another misspelling. It's supposed to be the emotion error, which tells you that the kernel is very sad.
       
 (DIR) Post #B6KylKYeJgdOzCl8a0 by astraleureka@social.treehouse.systems
       0 likes, 0 repeats
       
       @brouhaha @ska I always thought creat() was the amino acid syscall