I'm curious what you mean by the above? It makes me wonder if you know what you're talking about.
Don't misunderstand me. It's not my intention to be unduly critical of Linux. See below for a few limits, with references.
I've decided that you're uninformed and haven't even attempted to research Linux. At first I wanted to through this story into edit. But since we don't have that I was going to vote 0, but I think you've posted this just to do it, and it shows.
That wasn't my intention at all when I posted this. I simply saw this on a mailing list I was on, and felt that other k5 readers would find it interesting, too. Maybe not the most interesting thing in the world, but interesting nonetheless, IMO.
Note that when I say that I saw it on a mailing list, it was basically just the URL and someone's two-sentence blurb about this. What I wrote for submission is a slightly edited version of a posting I sent to a (different) mailing list. Yes, I should have taken some more time to add some more polish, but I was very tired at the time, and it seemed "good enough".
After reading a few of the comments in the submission queue yesterday, I started questioning myself as to whether or not this should should be posted, but I found myself hoping it would so that I could reply to you. (Rusty, can we have replies on the voting pages?) What follows is a list of a few of the limitations that I was referring to. (I had done this research for a Linux startup that paid me to find out some of the limitations. This is because the company [whose CIO and co-founder is the founder of Oracle or Zope, both applications that store most all of their information in a single file, in an enterprise-type setup, when Linux does not yet (in the stable kernel, that is; we're not talking about using development kernels in a production environment) support file sizes over 2 GB, for example. So without further ado:
Max file size:
That's pretty much the entire text of my report, at least, the part regarding the kernel. (I just added such niceties as hyperlinks, as the original text was a flat ASCII file.) I have done my research, and I am currently doing more. Oh, and note while that I am retaining copyright on the above report (obviously, I don't have copyright on someone else's words that I quoted, but on the parts that I didn't quote, and on the entire compilation), feel free to use the above if you need it (although you might be better helped by a forthcoming HOWTO, which will be available in (what I'll call) a "first public draft" form at or near the beginning of May. (Publish early, publish often -- we want to get it out there for people to start using as soon as possible, and this will allow us to get feedback on it much sooner.) Full disclosure and shameless plug: A Linux startup in the Philadelphia area, LinuxForce, paid me to research the above, and they'll also be paying me a little each month to co-author and maintain the forthcoming HOWTO. Note that the only relationship that I have with LinuxForce is that of a Linux enthusiast and someone that does some occasional work for them on a per-job consulting-type basis; I wasn't involved in the founding of the company.
2GB for 32-bit architectures, much larger for 64-bit. (Note: Although I've not seen documentation, I believe this to be 8,388,608 terabytes. (2^32)/(2*1027*1024*1024)==2GB; I applied the same formula for 2^64.)
Max open files:
With 2.2.x you can have 1024. Various patches exist which allow you to increase these limits. Note that this can break select(2).
Max filesystem size:
The limit for a single filesystem (partition) on a 32 bit CPU is 4 Gi blocks. Each block is 512 Bytes, so that works out to 2 TiB.
16, using the Intel MP specification
Max files per process:
Max swap: On i386, 2 GB (16 swap areas * 128 MB/swap area). On Alpha and Sparc64, 8 GB (16 swap areas * 512 MB/swap are).
Max RAM: Kernels 2.2.11 and 2.3.9 and onwards support 2GB of RAM out of the box, you can just select a special config option and it'll work. Support for more than 2GB of RAM is in the works and will probably be in kernel version 2.4. Since kernel 2.3.24, Linux supports up to 64 GB of physical memory and up to several TB of swap on the x86 platform. This means that this howto is now obsolete. The easiest way to use more than 1GB of memory is to get a newer kernel and run that.
For memory, you really want to look at the "Linux Memory Management subsystem" page. It includes such updates as "Linux now (kernel >2.3.24) supports up to 64GB of physical memory and up to several terabytes (that's no typo) of swap space" and "Since kernel version 2.3.28 the kernel supports large files (> 2GB) on x86 machines. Matti Aarnio's LFS patches have been integrated and the maximum file size on ext2 with 4k block sizes is now 8TB."
Also, there is a resource at http://linuxperf.nl.linux.org/unknown/limits.txt, where he also references the Documenation/proc.txt under the source subdirectory as his "definitive source."
Anyway, I hope that that answers any questions that you might have about the veracity of my claims. In particular, the statement about the filesystem size wasn't entirely accurate (I don't have a 2 TB parition lying around, do you?), but the statements in the submission were made from memory. I also hope that this can be of help to other people. Also note that the statements I made were based on the production kernel (2.2 as of this writing, of course) on a 32-bit architecture, which is what I suspect is what most people are using.
I closing I want to say that while I am enthusiastic about and supportive of Linux as much as the next Linux fan, that dealing with business is forcing me to be more practical. Linux is not the be-all and end-all of operating systems; such an animal does not exist. While it is my OS of choice, there are situations where is neither practical (because of limitations) nor advisable (because of advocacy reasons) to use or recommend the use of Linux. A good amount of this stuff will go away when 2.4 is the production kernel, but I suspect it's not a good idea (in general) to use a development kernel in a production environment (at least, not as your primary box for $TASK; it can certainly be good for development work). Linux still needs work, but it's coming along marvellously and rapidly. Don't forget the old saying that all operating systems suck. :) (Linux, IMO, just happens to suck less.) And neither is any one operating system suited for all tasks. Oh, and if you know of any resources that document more limits the kernel (either 2.2 or the forthcoming 2.4), feel free to let me know, if you want to. (The email address I'll be using for HOWTO-related stuff is this one. Proper credit will be given in the Acknowledgements or Credits section. Just say how you want to be credited [ie, by name, email address, etc].)
What we really need are documents that detail the same sorts of things about other OS's, like NT/2K, *BSD, Solaris, etc....
"If you haven't gotten where you're going,
you aren't there yet." --George Carlin
[ Parent ]