On Wed, 2007-08-01 at 17:00 +0200, Raphael Manfredi wrote:The answer appears to be that some filesystems really _suck_ when they have to return errors: they take forever to return to the user. When the client then tries with several WRITE requests (it can cache huge numbers of requests) then the cumulative effect of the delays are quite noticeable as you can see above. I've got a tentative client-side patch to deal with this sort of server. Basically, when the client sees that a cached write returns an error, then it will stop caching, and start doing O_SYNC-style writes until the error conditions stop. That won't fix the server side problem, but it does ensure that the application gets notified of the error as soon as possible. Cheers Trond
| Al Boldi | Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu sched... |
| Ingo Molnar | Re: [patch] sched_clock(): cleanups |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Denys Vlasenko | [PATCH 1/2] bnx2: factor out gzip unpacker |
