Page MenuHomeFreeBSD

Do not panic if inode bitmap is corrupted.
ClosedPublic

Authored by fsu on Feb 24 2019, 1:14 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 22 2024, 7:31 PM
Unknown Object (File)
Feb 15 2024, 2:19 AM
Unknown Object (File)
Dec 29 2023, 10:06 AM
Unknown Object (File)
Dec 22 2023, 12:34 AM
Unknown Object (File)
Dec 20 2023, 1:25 AM
Unknown Object (File)
Nov 25 2023, 11:42 PM
Unknown Object (File)
Nov 25 2023, 12:30 PM
Unknown Object (File)
Nov 23 2023, 8:39 AM
Subscribers

Details

Test Plan

Typical fsx/fstorture tests to avoid regression.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

We should probably keep this panic for consistency with UFS, which also panics on this case.

In D19325#414951, @pfg wrote:

We should probably keep this panic for consistency with UFS, which also panics on this case.

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.

Hi Kirk;
We have this as a panic in UFS, as well.

Fedor wants to relax it but it's probably weird enough to justify a panic ... I will let you both agree on what to do here :).

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.

This revision is now accepted and ready to land.Feb 27 2019, 8:20 PM

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).

I recently added the new error EINTEGRITY which is intended for use when a cylinder group or other filesystem structure has an integrity error.

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.

This revision was automatically updated to reflect the committed changes.