Re: [Ext2-devel] Re: [RFD] FS behavior (I/O failure) in kernel summit

[Hans Reiser <reiser@namesys.com>]

Helge, the kernel needs to send a proper message to some proper demon
that does the right thing.  Neither proper message nor proper demon
currently exists.  If you think that what we have works, try unplugging
a USB drive while an unsophisticated user is using it.

The conversion to and then from these -EIO style codes with their
limited number of allowed values (what is it, 128 values? ) loses
information, such as what the user should do, and whether to tell the
user about it or just tell the app. 

The current system was not exactly designed by a usability expert.....

Some error messages need to be fs specific (e.g. hash collisions), and
some are not at all fs specific and should be standardized across all
filesystems (e.g. USB drive unplugged).

The essential point is that what we have now is incoherent and broken in
its usability.  Fixing it requires deep work, not surface work.  Deeper
work than I think Kennichi-san realized.  Lets not get mired in details
though of what API should be created until someone volunteers to do the
substantial labor required to unbreak the usability.  If someone were to
appear and offer to fix the usability, I would be happy to have
reiserfs/reiser4 cooperate with that.  Ted, what about ext2/3, would you
guys support such an effort?  Maybe if we are encouraging as a group,
someone will volunteer....

Hans

Helge Hafting wrote:

> Hans Reiser wrote:
>
>> What users need is for a window to pop up saying "the usb drive is
>> turned off" or "we are getting checksum errors from XXX, this may
>> indicate hardware problems that require your attention".
>>  
>>
> Nice.  And the way to do this right is to have the kernel merely
> log the error as usual.  The user can have some daemon listening
> to the log, this program may then pop up error messages with
> nifty detailed explanations, start up diagnostic software
> for various subsystems and so on.
> The kernel can't do GUI stuff - a GUI may or may not be present,
> and the kernel cannot know.  The server may not run X at all
> but I still run graphical SW on it using a workstation or X-terminal.
> Or the pc may have three video cards, each running a different xserver
> with different users for each.  Who to report to?
>
> An error-reporting daemon have an easier job, it can look up the
> correct (possibly remote) display in its config file for all those
> cases when there isn't just _one_ display.
>
> Helge Hafting
>
>
>
>
>
>