我经常被潜在客户问道如果他们可以使用Linux而不是AIX或Solaris操作系统，那么如何应对高I/O的要求。没有人曾经问过我有关 Windows或NTFS上的高性能I/O--高IOPS（每秒输入输出）或高I/O流的问题，因为这是不可能的。自从10年前发布以来，Windows 和NTFS文件系统没有什么变化。鉴于它目前的架构，它也不能进行扩展。NTFS文件系统布局、分配方式和结构不能有效支持多TB文件系统，更不用说PB 级别的文件系统。这并不奇怪，因为这不是微软的目标市场。

那么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抱怨并反映问题，它们不可能说我们没法控制。

Linux文件系统

记住，大部分的Linux文件系统都是围绕替代NTFS而开发的，而不是一些诸如GPFS（IBM）、StorNext（昆腾）或QFS（Sun）这样的高性能文件系统。这些文件系统是为流式I/O 设计的，我们现在知道流式I/O对每个人、对一些高速IOPS以及一些情况下对数据库访问都是很重要的。

现在所通常使用的Linux文件系统（现在是ext-3，很快将有ext-4和xfs）在很长时间内都没有大的结构性变动了。Ext-4在ext-3和ext-2的基础上改进了一些分配，但是没有考虑一些简单的事情，例如RAID（独立磁盘冗余阵列）带超级锁的对齐，以及第一次元数据分配。

此外，类似于将额外文件系统元数据域和RAID带值相对齐这样的事情也没有被考虑，类似于间接分配的功能也没有，而这样的分配是固定值，所以如果系统支持小分配（最大4KB），那么就需要大量的分配数。举200TB的文件系统为例子，如果ext-3使用最大为4KB的分配值，那么这样的文件系统将需要5370亿个分配数来代表200TB。在企业级文件系统中可以使用8MB的分配值，那么分配数量就缩小为可以管理的2620万个。使用这种数字的分配值，位图或分配表甚至小于等于内存！xfs 文件系统拥有和ext-3非常相似的特征。是的，它的分配可以更大，达到64KB，但是超级锁、元数据域的对齐以及其他问题仍然存在。

Linux有它自己的位置

我前面的评述并不代表我是反对Linux的，就像我并不倾向AIX或Solaris。我甚至不反对Windows，因为我使用一台Windows笔记本电脑作为我的主要电脑。但是我认为缺省的Linux文件系统还不足以代替高性能、高可扩展性SMP文件系统。计算机是工具，而操作系统和文件系统也是工具箱中的工具。没有人会在有电锯的情况下却去使用链锯，同样的比喻也适用于操作系统、文件系统以及它们所运行的硬件。

我日常接触的许多人使用MS Word、MS Excel、MS PowerPoint和MS Visio。即使不是全部，我还是可以运行一些来自别人的Windows上的应用程序，但是我经常发现字体不匹配等问题，于是我在很早以前就决定采用 Windows，除非有人可以证明给我看没有问题。我这里的观点是每个计算机都是一个工具，而且有自己的用途。目前，没有一个单一的计算机或文件系统可以满足所有应用的要求。这并不奇怪。Linux是有一席之地，但是就我而言，它的定位并不支持大型文件系统的单实例，不能支持高性能要求下的大型和小型文件系统的良好扩展。而我不认为这种情况会很快改变。

来源：dostor

对文件系统的分析很深入呀。
高性能的文件系统，应该是现在 linux 发展的一个方向吧，可能只是需求不那么强烈，没有刺激它的发展而已。

看了LZ的帖子，对文件系统又有了一些了解！

http://www.enterprisestorageforu ... article.php/3745996
I am frequently asked by potential customers with high I/O requirements if they can use Linux instead of AIX or Solaris.

No one ever asks me about high-performance I/O — high IOPS or high streaming I/O — on Windows or NTFS because it isn't possible. Windows and the NTFS file system, which hasn't changed much since it was released almost 10 years ago, can't scale given its current structure. The NTFS file system layout, allocation methodology and structure do not allow it to efficiently support multi-terabyte file systems, much less file systems in the petabyte range, and that's no surprise since it's not Microsoft's target market.

And what was Linux's initial target market? For desktops, of course. Linux has since moved from the desktop to run on many large SMP servers from Sun, IBM and SGI. But can Linux as an operating system and Linux file systems meet the challenge of high-performance I/O?

You may think you don't need high-performance I/O, but every server needs this type of I/O performance for something as simple as backup and restoration. Current LTO-4 tape drives can operate at 120 MB/sec without compression and can support data rates up to 240 MB/sec with compression. If your file system cannot support I/O at these streaming data rates, then the time to backup and restore will take much longer than expected. For large environments with multiple tape drives, not being able to use the tape drives at their full data rate might require additional tape drives to meet the backup time window, which affects restoration too. Therefore, it seems to me that everyone should be interested in the performance of Linux file systems, if only for backup and restore.

Can Linux file systems, which I will define as ext-4, XFS and xxx, match the performance of file systems on other UNIX-based large SMP servers such as IBM and Sun? Some might also inquire about SGI, but SGI has something called ProPack, which has a number of optimizations to Linux for high-speed I/O, and SGI also has their open proprietary Linux file system called CxFS, which is not part of standard Linux distributions. Because SGI ProPack and CxFS are not part of standard Linux distributions, we won't consider them here. We'll stick to standard Linux because that is what most people use.

We'll focus on two areas:

   1. Linux as an operating system, and
   2. Linux file systems.

Linux Operating System Issues

We'll set aside what might happen with Linux in the future and instead focus on what is available today. Linux has a number of features that match the I/O performance of AIX and Solaris, such as direct I/O, but the bottom line is that Linux wasn't designed around high-performance multi-threaded I/O.

There are a number of areas that limit performance in Linux, such as page size compared with other operating systems, the restrictions Linux places on direct I/O and page alignment, and the fact that Linux does not allow direct I/O automatically by request size — I have seen Linux kernels break large (greater than 512 KB) I/O requests into 128 KB requests. Since the Linux I/O performance and file system were designed for a desktop replacement for Windows, none of this comes as much of a surprise.

Linux has other issues, as I see it; for starters, the lack of someone to take charge or responsibility. With Linux, if you find a problem, groups of people are going to have to agree to fix it, and the people writing Linux might not necessarily be responsive to the problems you're facing. If a large vendor of Linux agrees with your problem and provides a fix, that doesn't mean it will be accepted — or accepted anytime soon — by the Linux community. And getting a patch for your problem could pose maintenance problems.

The goals for Linux file systems and the Linux kernel design seem to be trying to address a completely different set of problems than AIX or Solaris, and IBM and Sun are far more directly responsible than the Linux community if you have a problem. If you run AIX or Solaris and complain to IBM or Sun, they can't say we have no control.

Linux File Systems

Remember that most Linux file systems were designed with desktop use in mind, not some of the high-performance file systems such as GPFS (IBM), StorNext (Quantum) or QFS (Sun). These file systems were designed for streaming I/O, which we now know is important for everyone and for some high-speed IOPS, and in some cases for database access.

The Linux file systems that are commonly used today (ext-3 today and likely soon ext-4 and xfs) have not had huge structural changes in a long time. Ext-4 improves upon ext-3 and ext-2 for some improved allocation, but simple things like alignment of the superblock to the RAID stripe and the first metadata allocation are not considered.

Additionally, things like alignment of additional file system metadata regions to RAID stripe value are not considered, nor are simple things like indirect allocations (see File Systems and Volume Managers: History and Usage), which are fixed values so with the small allocations supported (4 KB maximum), large numbers of allocations are required. Take a 200 TB file system, which will require 53.7 billion allocations to represent the 200 TB using the largest allocation size of 4 KB supported by ext-3. Using 8 MB, which is feasible on enterprise file systems, it becomes a manageable 26.2 million allocations. The bitmap or allocation map could even fit in memory for this number of allocations! The xfs file system has very similar characteristics to ext-3. Yes, allocations can be larger, up to 64 KB if the Linux page size is 64 KB, but the alignment issues for the superblock, metadata regions and other issues still exist.

Linux Has Its Place

That's not to say I am anti-Linux, just as I am not pro-AIX or pro-Solaris. I am not even anti-Windows, since I use a Windows laptop as my main computer. But I do believe that the default Linux file systems are not yet up to the task of replacing the high-performance, highly scalable SMP file systems. Computers are tools, and operating systems and file systems are also tools in the toolbox. No one uses a chainsaw in place of a jigsaw, and the same analogy can be used for operating systems, file systems and the hardware they run on.

Many of the people I deal with daily use MS Word, MS Excel, MS PowerPoint and MS Visio. I could run some if not all of these applications on a Windows emulator from someone, but I routinely get incompatibilities with fonts, and I just decided long ago to live with Windows until someone can prove to me that it all works together with no problems. My point here is that every computer is a tool and has its use. Currently no single computer or file system can meet all application requirements. This should not come as a surprise. Linux has a place, but as far as I can tell, that place does not support single instances of large file systems and scaling well from large to small file systems with high-performance requirements. And I don't see this changing anytime soon.

Henry Newman, a regular Enterprise Storage Forum contributor, is an industry consultant with 27 years experience in high-performance computing and storage.
See more articles by Henry Newman.