Typical fsx/fstorture tests to avoid regression.
I prefer to remove the panic in this case, because we can return error clearly.
It just mean that the inode cannot be allocated in the requested cg.
Also, there is for example, the ext2_dirbad (), here the panic is more preferable, because it is difficult to figureout, what will happen if dirver will not call panic().
So, just decrease ext2fs panic () probability.
Upon further thought: the situation is very different for ext2fs than to a filesystem in which the all the system depends as in UFS.
In ext2fs we can tell the user to oops. ... run fsck and try again, on UFS one simple looses the system so panic'ing is preferable to remaining in some blocked state.
I recently added the new error EINTEGRITY which is intended for use when a cylinder group or other filesystem structure has an integrity error. My initial plan is to use it for check-hash failures, but this is another good place to use it. It means that the callers of the functions that return this error need to be prepared to handle it. Specifically when allocating blocks or files trying to allocate from a different cylinder group. When deleting blocks or files, not immediately giving up, but trying to release all the remaining blocks of the file. A similar analysis would need to be used for this error (notably trying to allocate from a different cylinder group).
Ah yes, ext2fs also has hash checks so it will be good to keep the consistency among both implementations.
Small reminder: when we start using the new error we will have to decode it into something sensible for the linuxulator as well.