> -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > John Campbell > The problem arises when your application-- being multi-threaded and > moving up to 2.2 million files in a day-- *depends* upon linking and unlinking > being *fast* in order to "move" the files being manipulated. > All running on HF (Huge) Solaris boxes and the F/S's in question residing in > a > SAN. While not normally a problem, when there is a single directory that gets > all of the files being processed for auditing you can end up with one *hell* > of > a nightmare that cannot be solved without a major re-design of the > application itself. > > Mind you, the locking mechanism around directory manipulation is hidden > and won't show up in the stats... and it was, in hindsight, a miracle that I > even > remembered, during a meeting on this, that directory manipulation is single > threaded. (We discovered, in some follow-ups, that we were near the limit > even on a single box with the non-clustered architecture; We have ways to > avoid this, now.)
Ugh. Tell that set of programmers to back away from the keyboard so nobody gets hurt. Classic concrete proof that no matter how much hardware, operating systems and application and system development tools improve, lusers writing brute force Fortran-style applications will outlive us all. Stuff like that needs to be taken out back of the barn, and put down before it breeds. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
