On Monday 22 January 2007 17:17, Phillip Susi wrote: > > You do not need to know which read() exactly failed due to bad disk. > > Filename and offset from the start is enough. Right? > > > > So, SIGIO/SIGBUS can provide that, and if your handler is of > > void (*sa_sigaction)(int, siginfo_t *, void *); > > style, you can get fd, memory address of the fault, etc. > > Probably kernel can even pass file offset somewhere in siginfo_t... > > Sure... now what does your signal handler have to do in order to handle > this error in such a way as to allow the one request to be failed and > the task to continue handling other requests? I don't think this is > even possible, yet alone clean.
Actually, you have convinced me on this. While it's is possible to report error to userspace, it will be highly nontrivial (read: bug-prone) for userspace to catch and act on the errors. > > You think "Oracle". But this application may very well be > > not Oracle, but diff, or dd, or KMail. I don't want to care. > > I want all big writes to be efficient, not just those done by Oracle. > > *Including* single threaded ones. > > Then redesign those applications to use aio and O_DIRECT. Incidentally > I have hacked up dd to do just that and have some very nice performance > numbers as a result. I will still disagree on this point (on point "use O_DIRECT, it's faster"). There is no reason why O_DIRECT should be faster than "normal" read/write to large, aligned buffer. If O_DIRECT is faster on today's kernel, then Linux' read()/write() can be optimized more. (I hoped that they can be made even *faster* than O_DIRECT, but as I said, you convinced me with your "error reporting" argument that reads must still block until entire buffer is read. Writes can avoid that - apps can do fdatasync/whatever to make sync writes & error checks if they want). -- vda - 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/
