Re: gets, fconfigure question

Donal K. Fellows <donal.k.fellows@xxxxxxxxxxxxxxxx> wrote:


Kip Rugger wrote:
I think what you are seeing is that files don't really support the
non-blocking mode -- this is an operating system thing.

It would be more accurate to say that files don't support _blocking_
mode; a read of a plain file should never block for anything. Which
isn't to say that it's instantaneous, but it certainly pretends to be.
Alas, this is true even with networked filing systems, where blocking
most certainly is possible, but that's a real multi-level abstraction
buster of a problem, and not something we can solve.

Indeed, it reminds me of when I worked at a place where the applications
were all served out of a single central NFS server which hadn't had
sufficient investment in hardware support for a few years. One day, it
got hardware hiccups because of overloading, and it took days for things
to be fixed up; large numbers of machines locked solid waiting for
memory (specifically the applications' text segments) to be mapped back
in from the server, the server couldn't stand the load imposed by
serving hundreds of simultaneous requests for the mwm binary (yes, this
was quite a few years ago now) and fell over about 5 seconds after
coming alive each time. To make things even more fun, it insisted on
doing a full fsck every time it booted, so the cycle time wasn't really
5s, but rather about 15 minutes. I was a bit lucky for the first couple
of hours (I used my own custom window manager and application at the
time, and home directories were on a different NFS server) but then the
Xserver got paged and I was stuck for the duration too. Horrible. (The
fix was procured and installed within about two weeks; a distributed
scalable NFS system based on the periodic use of rsync to keep slave NFS
servers - one per ~20 workstations - up to date with a central
application server that did not run NFS. As far as I know, that system
is still in use today.)

Donal (OK, enough off-topic rambling...)

Well, you can certainly get into a situation in which you hate NFS :)

In our organization (as in yours) we use laptops. If the laptop is
not connected to the office network (directly, Internet), then NFS is
totally useless. Instead, you have to rely on a potentially
out-of-date copy of the filesystem in question that is stored on the
laptop.

Our organization may differ from yours in that our primary application
is shareware, and that the work product of our employees is ultimately
the keystrokes they make on their laptops. So the server can be
out-of-date with respect to any laptop (new work, not recorded), while
the laptop copy of the fs may not have the latest updates to the
server or to other laptops.

Rather than NFS, we require a filesystem which is a replicated
database that can survive arbitrary network partitioning.

Now the interesting thing from database theory is that, while general
solutions to the above problem are not theoretically possible, it is
always possible to state what to do in any specific situation -- you
have to add in the business constraints and practices. And this is
how we construct our replicated filesystem.

Because we use a *BSD OS, it is very easy to construct the original
log info that tells what happened to the local filesystem. That part
is easy.

Then there is the logic for re-syncing copies of the filesystem, using
the log files. I do this in Tcl. This is core+tDOM+tclX, or nothing
that readers of this group don't understand. The reason that I use
these tools is that they are *reliable*: I really don't want buggy
software screwing up my distributed filesystem. The special handling
by file type tends to be a few lines of script, and this (I hope) can be
written correctly the first time.

While Tcl cannot be expected to fix NFS, it certainly can be used to
go around the problems that NFS creates.

.

Relevant Pages

  • NFS has a problem
    ... filesystem will get stuck in state D the next time they try to access ... Hmmm, the servers are running Debian stable, and have been providing NFS ... I stop and restart the nfs services on the server side, but client ...
    (comp.os.linux.misc)
  • Re: NFS has a problem
    ... that filesystem barfs, all the processes on N that were using that filesystem will get stuck in state D the next time they try to access that filesystem. ... Hmmm, the servers are running Debian stable, and have been providing NFS services for several years now, and have been working fine with Debian stable clients. ... The Gentoo machine is a new development on the network, with the NFS client becoming operational at the beginning of this year. ... I stop and restart the nfs services on the server side, but client processes remain in state D on the Gentoo machine. ...
    (comp.os.linux.misc)
  • Re: NFS has a problem
    ... that filesystem barfs, all the processes on N that were using that filesystem will get stuck in state D the next time they try to access that filesystem. ... Hmmm, the servers are running Debian stable, and have been providing NFS services for several years now, and have been working fine with Debian stable clients. ... The Gentoo machine is a new development on the network, with the NFS client becoming operational at the beginning of this year. ... I stop and restart the nfs services on the server side, but client processes remain in state D on the Gentoo machine. ...
    (comp.os.linux.misc)
  • Re: [opensuse] 2GB File size limit exceeded over NFS on 10.3
    ... It's trying to copy a 2.7 GB file from a local disk to a filesystem on ... the server that it's mounting using NFS. ... Google showed it may be a restriction of NFS V2 though why that is now ... You might use the old reiserfs format which cannot cope with files ...
    (SuSE)
  • Re: Folder Synchronization
    ... Just to looking for AFS or Coda file system. ... and my server where my documents are stored. ... > just to get NFS to work. ... > all that, but when I am shutting down my laptop, one of the messages I ...
    (Fedora)