Messages in this thread |  | | | Subject | Re: [RFD] What error should FS return when I/O failure occurs? | | From | Valdis.Kletnieks@vt ... | | Date | Mon, 16 May 2005 13:58:04 -0400 |
| |
On Mon, 16 May 2005 14:04:04 EDT, fs said:
> The point is(from the user's perspective, not FS developer's): > If you open a file with O_RDWR, and sys_open returns success, > next, call sys_write, but returns EROFS? The two return values are > paradox/self-contradictory.
You'd be better off pointing out that 'man 2 write' lists the errors that might be returned as: EBAF, EINVAL, EFAULT, EFBIG, EPIPE, EAGAIN, EINTR, ENOSPC, and EIO.
Does the POSIX spec allow write() to return -EROFS?
What happens if you're writing to an NFS-mounted file system, and the remote system remounts the disk R/O? What is reported in that case?
> The purpose of this RFD, is to get the community to understand, > all I/O related syscalls should return VFS error, not FS error.
All fine and good, until you hit a case like ext3 where reporting the FS error code will better explain the *real* problem than forcing it to fit into one of the provided VFS errors.
> User mode app should not care about the FS they are using. > So, the community should define the ONLY VFS error first.
I think that's been done, and the VFS behavior is "if the FS reports an error we pass it up to userspace". [unhandled content-type:application/pgp-signature] |  |