Pieter de Goeje wrote: > GEOM_VIRSTOR[1]: All physical space allocated for test > GEOM_VIRSTOR[5]: Failed to allocate physical chunk for virstor/test > g_vfs_done():virstor/test[WRITE(offset=103153664, length=131072)]error = 28 > It spitted out these messages in a tight loop (100% sys load). I was unable to Yes, it turns out the file system gets confused if the device reports a certain size and then returns ENOSPC (error 28) when it shouldn't. Unfortunately, yanking the device from under the file system would panic the kernel. Returning EIO could either panic it or "just" end up with a corrupted file system. Any ideas from the more VFS-savvy? The "tight loop" seems to be VFS retrying, inserting the requests to GEOM layer over and over... > Also, no warning was issued when it aproached 0% free physical space. > I would expect the system to simply abort the write operation (possibly > needing a background fsck after adding another component to make more space). It should - are you sure the message didn't get lost/overflown in the log?
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:05 UTC