那么Linux最初的目标市场是什么呢？当然，是替代微软的桌面环境。后来， Linux从桌面运行转移到运行在许多来自Sun、IBM和SGI的大型SMP（对称多处理器结构）服务器上面。但是，作为一个操作系统，Linux以及其Linux文件系统可以应对来自高性能I/O的挑战吗？
你可能会想你不需要高性能I/O，但是即使是简单到备份和恢复这样的操作，每个服务器也都需要这种类型的I/O性能。目前的LTO-4（线性磁带开放协议）磁带驱动器在无压缩的情况下可以以每秒120MB的速率运行，在带压缩情况下，可以支持高达每秒240MB的数据速率。如果你的文件系统并不支持这种流式数据速率I/O，那么备份和恢复将会花费比预期更多的时间。对于带许多磁带驱动器的大型环境来说，不能在全数据速率下使用这些磁带驱动器意味着需要更多的磁带驱动器来满足备份时间窗口的要求，同时恢复操作也会受到影响。因此，我觉得，即使只是针对备份和恢复，每个人都应该对Linux文件系统的性能感兴趣。
那么Linux文件系统--我的定义是在ext-4、XFS 和xxx--是否能够达到其他的基于UNIX的诸如Sun和IBM这样的大型SMP服务器的文件系统的性能呢？一些人可能还会问到SGI，但是SGI有一个名为ProPack的软件包，这个包包含了针对Linux高速I/O的一系列优化，而且SGI同时还有它们自己的名为CxFS的开放私有域Linux文件系统，而这个文件系统并不是标准的Linux产品的一部分。由于SGI ProPack和CxFS都不是标准Linux产品的一部分，因此我们这里不考虑它们。我们坚持讨论标准Linux是因为这是大多数人所使用的。
我们将关注两个领域：
作为操作系统的Linux以及Linux文件系统。
Linux操作系统的问题
我们将暂时不考虑Linux未来所可能发生的事情，而是专注于现在已有的情况。Linux有一些功能可以达到AIX和Solaris的I/O性能，例如直接I/O，但是底线是Linux并不是围绕着高性能多线程I/O而设计的。
有一些领域限制了Linux的性能，例如和其他操作系统相比的页大小，Linux在直接I/O和页对齐上的限制，以及Linux不能通过自动根据请求大小来进行直接I/O的情况--我看到过Linux内核将大的I/O请求（大于512KB）分解成128KB大小的请求。鉴于Linux I/O性能和文件系统当初是为了替代Windows桌面而设计的，因此出现这种情况并不奇怪。
就我所见，Linux还有其他问题。对于初学者而言，缺乏能够负责的人。在Linux上，如果你发现一个问题，会有各个组的人来同意解决这个问题，但是当初写Linux的人却并不一定会响应你所遇到的问题。如果一个大型的Linux厂商同意你的问题，并提供解决方法，这并不意味着这种方法将会被--或很快会被--Linux社区所接受。而且，针对你的问题的补丁还会带来维护的问题。
Linux文件系统和Linux内核设计的目标看起来似乎是试图解决和AIX或Solaris完全不同的问题，而如果你有问题，IBM和Sun也比Linux社区更直接负责得多。如果你运行AIX或Solaris，并且向IBM或Sun抱怨并反映问题，它们不可能说我们没法控制。