Messages in this thread | | | Date | Thu, 16 Jun 2005 12:52:32 -0700 | From | Hans Reiser <> | Subject | Re: [Ext2-devel] Re: [RFD] FS behavior (I/O failure) in kernel summit |
| |
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 > > > > > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |