Please stop apps going into state D uninterrupted sleep !!

[Tim]

On Tue, 2012-05-08 at 16:02 -0430, Patrick O'Callaghan wrote:
> As I tried to explain, rewriting a couple of apps is not going to hack
> it. The apps don't *know* they're using a networked filesystem,
> they're just accessing files. They could find out and try to take
> measures, but then what about all the other apps that also write
> files? Rewrite tar, cpio, dd, cat, ...?
>  
> The price of treating a networked fs as equivalent to a local one is
> that you get screwed when it doesn't behave like a local one. Dealing
> with this in a coherent and consistent way is hard. See the literature
> on distributed filesystems. The semantics of an NFS system are *not*
> the same as a local system. We brush this under the carpet most of the
> time because it usually works, but sometimes the differences bite.

And thinking out loud...  In Linux, when anything wants file system
access, does it directly access the file system, or does it ask the
system to access it?

If it's direct access, then I can see that you'd need to change every
program that wants access.  But if everything asks the system to access
the drive, then you have the potential to change how the system works,
solving the problem in (mostly) one place.

i.e. The ability to set more reasonable timeout periods (seconds, not
minutes or hours).  And for the system to report access success or
failure to whatever wanted to access the drives, and that accessing
program would have to accept failure (this part being a problem that has
to be implemented in each application - though they should already have
failure handling built in, unless programmed by a fool).

That'd prevent the infinite waits for a non-available file system, and
deal with programs thinking they're writing files when they're really
dumping data nowhere.

-- 
[tim at localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.