On Tue, 2005-05-17 at 14:26, Bryan Henderson wrote:
> >Yes, we're sure to abort the operation, but we can't use
> >exit(EXIT_FAILURE) directly. For HA environment, we should
> >identify the cause of the error, take correspondent action,
> >right? So we need to get the right error.
>
> You mean a computer program will take the correspondent action? I think
> it would take a remarkably intelligent program to respond appropriately to
> particular failures -- especially if the program isn't tailored to a very
> specific environment. In practice, all I ever see a binary response --
> one for success, one for failure. The errno is used at most for giving a
> three word explanation to a human so the human can respond. That's why
> people don't take this issue seriously.
>
> "pass the errno up" is definitely a layering violation and cheap
> architecture. It's why the 3 word description you get is often
> meaningless -- it's telling you about a failure deep in computations you
> aren't even supposed to know about. I myself stay away from errnos where
> possible and produce error information in English text, with each layer
> adding information meaningful at that layer. But where we're sticking
> with classic errnos, it just doesn't make sense to work really hard on it.
>
> Nonetheless, I think there's broad agreement, and the current discussion
> is consistent with it, that if write() fails due to an I/O error, the
> errno should be EIO. Whether it's formally specified or not, the standard
> is there. That ext3 returns EROFS is either a bug or an implementation
what standard do you mean?
> convenience compromise or a case where the actual failure is more
> complicated than you imagine (maybe an operation fails and gets retried --
> the original failure caused an automatic switch to R/O and the retry
> failed because of the R/O status. Errnos are definitely not sufficient to
> give you the whole chain of causation for a failure -- if it gives you
> even the immediate cause, you should feel fortunate).
I suggest you visit our project, see the testing result,
http://developer.osdl.jp/projects/doubt/fs-consistency-and-coherency
For each test case, different FS returns different result.
>From user's perspective, it's really annoying, so, there should be a
standard which constraints the error type. Otherwise, different fs
can return whatever they want, regardless of the user's need.
> --
> Bryan Henderson IBM Almaden Research Center
> San Jose CA Filesystems
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
