On Sat, May 20, 2017 at 12:57:09AM +0000, Hugo Mills wrote: > I think from the POV of removing these BUG_ONs, it doesn't matter > which FS causes them. "All" you need to know is where the error > happened. From there, you can (in theory) work out what was wrong and > handle it more elagantly than simply stopping. Sorry, "you" being the code author, or the user? If code author, I'd rather this be worked out without the extra steps of having to guess or spend more time to see which FS. My FS takes up to a day to scrub and btrfs check, clearly making me do this over 3 of them is not a good use of time and a loss of up to 3 days of wall clock time. Not counting that during that time, I have loss of service on all my filesystems because I don't want to mount them read-write.
> Obviously it would be nice, from the POV of the sysadmin, to know
> which FS was complaining, but as an FS developer it's secondary to
> identifying a BUG_ON which happens in real life, which offers an
> opportunity to make the error path more elegant.
If the FS is remounted R/O, further damage is averted and it's obvious to
the admin which FS has a problem.
Is there a reason why all errors that are serious enough, do not cause the
FS to remount R/O instead of having any BUG/BUG_ON at all?
WARN_ON is also fine obviously if the error is not serious enough, or doing
a WARN_ON + a remount R/O
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
signature.asc
Description: Digital signature
