A file is simply an ordered sequence of elements, where an element could be a machine word, a character, or a bit, depending upon the implementation. A user may create, modify or delete files only through the use of the file system. At the level of the file system, a file is formatless. All formatting is done by higher-level modules or by user-supplied programs, if desired. As far as a particular user is concerned, a file has one name, and that name is symbolic. (Symbolic names may be arbitrarily long, and may have syntax of their own. For example, they may consist of several parts, some of which are relevant to the nature of the file, e.g., ALPHA FAP DEBUG.) The user may reference an element in the file by specifying the symbolic file name and the linear index of the element within the file. By using higher-level modules, a user may also be able to reference suitably defined sequences of elements directly by context.

A directory is a special file which is maintained by the file system, and which contains a list of entries. To a user, an entry appears to be a file and is accessed in terms of its symbolic entry name, which is the user’s file name. An entry name need be unique only within the directory in which it occurs. In reality, each entry is a pointer of one of two kinds. The entry may point directly to a file (which may itself be a directory) which is stored in secondary storage, or else it may point to another entry in the same or another directory. An entry which points directly to a file is called a branch, while an entry which points to another directory entry is called a link. Except for a pathological case mentioned below, a link always eventually points to a branch (although possibly via a chain of links to the branch), and thence to a file. Thus the link and the branch both effectively point to the file. (In general, a user will usually not need to know whether a given entry is a branch or a link, but he easily may find out.)

?

It’s something I do worry about; and I do share your concern. At the same time, the reality is that we are a little like the Old Dutch Masters, who had take into account the preference of their patrons (i.e., in our case, those who pay our paychecks .

One of those rare moments when art, commerce, and engineering collide to produce comedy.

The counter argument, in its best form, can be found at QNX.

http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/fsys.html

“This will blow away any RTOS,” said Cauchy. “We speed up execution by doing things like vector interrupts, I/O memory mapping, and turning off timers.”

By Gad!

150,000,000
Number of Windows 7 licenses sold, making Windows 7 by far the fastest growing operating system in history.
<10
Percentage of US netbooks running Windows in 2008.
96
Percentage of US netbooks running Windows in 2009.
9,000,000
Number of customer downloads of the Office 2010 beta prior to launch, the largest Microsoft beta program in history. [source]
24%
Linux Server market share in 2005.
33%
Predicted Linux Server market share for 2007 (made in 2005).
21.2%
Actual Linux Server market share, Q4 2009.

http://blogs.technet.com/b/microsoft_blog/archive/2010/06/25/microsoft-by-the-numbers.aspx

Those last numbers are especially damning since Linux started with superior technology, has an easier business model if your only goal is market share, and did not have a legacy ball-and-chain anywhere near the size MS has to drag along. But years of directionless bloat have taken a toll and the sponsor driven decisions to go for traditional “server/OS” technology methods in place of trying to find solutions to current customer problems has been very damaging.

Even discounting the obvious PR froth of this article: http://www.eweek.com/c/a/Linux-and-Open-Source/Linux-Losing-Market-Share-to-Windows-Server it is an interesting trend.

and just for kicks from April 2000

“During his presentation on scaling Linux to the enterprise, BitMover, Inc. CEO Larry McVoy raised a few furrowed eyebrows at the recently-held Colorado Linux Info Quest (CLIQ). His message: Symetric multiprocessing (SMP) scaling may be hazardous to your operating system (OS) health.”

“McVoy said that the level of harm is “directly proportional” to the amount of scaling and is “worse than linear” in the number of processors. Converting a uniprocessor OS to a four-way SMP OS introduces a “small amount of damage.” Converting the four-way SMP OS to a 32-way SMP OS does even more damage, he told the crowd. McVoy calls this phenomenon “the locking cliff.”"

“The bottom line, said McVoy, is that: “Linux needs to have bragging rights on ‘big iron’ to be taken seriously in the enterprise. But the traditional way of getting those rights involves a series of changes which do a lot of damage to the source base. So the problems are that Linux needs to scale, and traditional scaling is a bad idea. Linux will use traditional scaling if nothing else shows up,” he said, “but SMP clusters is a better way to do it. I’m the driving force behind that and I’m not driving because I’m wrapped up in BitKeeper.”"

http://www.linuxtoday.com/news_story.php3?ltsn=2000-04-13-010-06-NW&tbovrmode=3

Re: Schedule idle
MOLNAR Ingo (mingo@chiara.csoma.elte.hu)
Wed, 11 Nov 1998 04:09:32 +0100 (CET)
[...]
> _please_ We can do better than this. Only semaphores (not spinlocks) need
> to have the priority inheritance. [...]
nope there are _not_ only semaphores, but many other types of locks.
> [...] This can be done with lists off the
> semaphore and tasks… [...]
it’s _not_ easy to extend Linux semaphores to handle priority inheritance. currently semaphore operations can be done via hw-atomic test-and-set instructions. If we do anything more complex, we cannot use simple instructions anymore. Linux semaphores are 2 instructions for an up() and 2 for a down(), and thats one of our crown jewels

the whole point is not quite valid, RT and filesystem IO doesnt mix well anyway … the solution: use system calls that are guaranteed to not block, either by design, or by system policy (ie. separate filesystem on a RAMDISK) … or use a device that doesnt introduce large latencies. (RAMdisk or solid state disk)

And then ….

Percentage of lock acquisitions for global TCP/IP locks that do not succeed
immediately.

L2 Data cache misses per KB of transmitted data.

Here is a related discussion

.

* RTLnux is a  trademark now belonging to WindRiver/Intel.