Dear Linus, Andrew Morton, and all FS maintainers,
I'm taking part in the project DOUBT[1], and my sub-project
focuses on the consistency and coherency of FS[2].
Several days ago, I posted a thread, titled "[RFD] What error should
FS return when I/O failure occurs?"[3] The purpose of this RFD, is to
see whether the community has agreed on this subject. Unfortunately, NO!
From my test results in [2], we can see different FS returns
different error, or even no error. The community has several points,
A) some results are caused by bugs, some are correct, some are
implementation compromise. errno is passed to VFS from lower layer,
no need to supply unified error type. User applications should handle
every error type or glibc can convert the types to specified error
type.
B) the kernel should give unified error(i.e. errno should be the same
for each FS, and give the correct meaning). User applicatons should
handle specified error type/types.
C) the errno that user gets can't provide enough info, so, there's no
need to tell. User application gets -1 from I/O syscalls, that's
enough, don't use errno. If user really have special needs, the
kernel should use special mechanism to achieve the goal, e.g. add
new functions to device drivers.
D) ...
From the user's perspective, B) seems to be the best, especially for
HA purpose. But till now, we can't find any standards or constraints, so
each FS implementaion uses 'de facto' way to return errno. This makes
users confused.
So, would you please have a discussion about this issue in Kernel
Summit (June 11-18)? If yes, we users are really thankful for this
discussion, so we can know how linux is designed for I/O error handling
about FS; if not, that means errno is FS implementation dependent, we
have to test our app for each FS. :(
P.S.: During the presentation of Kenichi Okuyama in Paris, Windows seems
to detect every I/O failure immediately, even for async writes. This
shows how proprietary software handles I/O failure.
[1] http://developer.osdl.jp/projects/doubt/
[2]
http://developer.osdl.jp/projects/doubt/fs-consistency-and-coherency/index.html
[3] http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/0006.html
yours,
----
Qu Fuping
|