David Boyes wrote: >> I just want to insert a comment about a Clustered F/S (better than a C/F, >> right?) in an application environment where there are a sh!tload of links and >> unlinks within a single directory... >> Don't do it. >> Just... don't. > > Newer cluster file systems like PVFS2 and Ceph have mechanisms to limit the > impact of this kind of activity.
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.) I hate IE right now since WXP keeps dropping characters as I type them into this browser window. -soup -- John R. Campbell Speaker to Machines souperb at gmail dot com MacOS X proved it was easier to make Unix user-friendly than to fix Windows ---------------------------------------------------------------------- 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/
