我有一个在 RAID5 中运行 XFS 的五个磁盘阵列，我想提高它的性能。我已经看到一些提示，将日志放在单独的设备上会有所帮助，将日志放在 SSD 上是否有帮助？
从理论上讲，它应该，但我一直无法找到任何有人实际这样做的案例研究，并且购买 SSD 然后让它无法正常工作充其量是不方便的......
我正在两台相同的服务器上对一个应用程序进行基准测试，一台是 Centos 5.8，另一台是 Centos 6.2。我的应用程序在 Centos 6.2 机器上的运行速度要慢得多（50% 或更少）。
在尝试诊断问题时，我在整个基准测试过程中跟踪 CPU、RAM 和 IO。我看到使用 iostat 测量的 Centos 6.2 机器上的磁盘读取明显更高。
两个系统都在运行我的基准测试所在的 XFS。两者都是惠普服务器，配备 512MB 缓存 RAID 控制器，配备 8 个 300GB SAS 运行 RAID 10。
这是每个 xfs_info 的输出：
centos5
meta-data=/dev/cciss/c0d0p5 isize=256 agcount=32, agsize=8034208 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=257094144, imaxpct=25
= sunit=32 swidth=128 blks, unwritten=1
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
centos6
meta-data=/dev/sda5 isize=256 agcount=4, agsize=57873856 blks
= sectsz=512 …我在硬件 RAID6 中有 10 个磁盘，每个磁盘有 8 TB（因此，8 个数据磁盘 + 2 个奇偶校验）。按照一个非常相似的问题的答案，我希望自动检测所有必要的参数。但是，在最后创建 XFS 文件系统时，我得到了
# mkfs.xfs /dev/vgdata/lvscratch
meta-data=/dev/vgdata/lvscratch isize=256 agcount=40, agsize=268435455 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=10737418200, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
这看起来像没有使用条带化。由于我在不同网站上找到的不同术语（条带大小、条带大小、条带块……），我想问一下我的手动参数是否正确。
RAID 6 的条带大小设置为 256KB：
# ./storcli64 /c0/v1 show all | grep Strip
Strip Size = 256 KB
因此，条带大小为 …
我将在一些大型文件系统（大约 50 TB）上测试“xfs_repair”，因为过去内存使用率很高。虽然我只能在正确的文件系统上测试程序，但最好在损坏的系统上测试它们。
那么破坏文件系统的最佳方法是什么。如果该方法每次都重复出现相同的损坏，则额外加分....
让人们了解我在 2006 年的意思
“要在多 TB 文件系统上成功检查或运行修复，您需要：
xfs_repair 通常会使用比这更少的内存，但是这些数字为您提供了一个大概的数字，了解一个大于 80% 的大型文件系统需要修复的内存。
FWIW，上次在内部出现这种情况时，有问题的 29TB 文件系统需要约 75GB 的 RAM+swap 才能修复。”
我需要将我的 Amazon EC2 ext4 文件系统转换为 XFS 文件系统，以便我可以拍摄一致的快照并将它们发送到 S3。我在 us-east 中使用带有 i686 架构的 ubuntu 服务器 10.10 的自定义小图像。问题是我只对所有文件使用一个 EBS 驱动器，现在这让我很头疼，因为当从 ssh 登录到实例时，我无法真正卸载、格式化驱动器或对驱动器做任何事情。我的猜测是我需要以某种方式将 EBS 卷分成 2 个并将 /var/www 和 /var/lib 移动到第二个 EBS 卷并将其转换为 XFS。我正在使用 apache2、mysql、ispconfig、bind、postfix、courier、pureftp（http://www.howtoforge.com/perfect-server-ubuntu-10.10-maverick-meerkat-ispconfig-3）
谢谢你。
我有一个来自 Buffalo LinkStation 的磁盘，该磁盘上有一个无法安装的 XFS 分区。
将磁盘插入 Ubuntu 机器上的 SATA->USB 盒。我得到以下信息：
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 63 594404 297171 83 Linux
/dev/sdb2 594405 1590434 498015 83 Linux
/dev/sdb4 …我一直在执行一项任务，从我曾经在 RAID 1 中的 2 个完美工作、未损坏、未加密的 NAS 驱动器中的一个中恢复文件。 NAS 是 Patriot Javelin S4，它（正如我从我的研究中发现的那样） ) 使用 Promise Fasttrack 假突袭控制器。
这方面的信息非常稀少，因此对于处于相同情况的谷歌人来说，这里有一些关于这个 NAS 的事实：
执行此操作时，我只有 Windows 10 和 MacOS 计算机，并且我发现没有能够在 LVM2 卷中安装 XFS 的软件（有 1 个例外，更多内容见下文）。我不得不拿出我的旧上网本 Acer Aspire One，并在其上安装 puppy linux（特别是 lxpup 风格）。
在 puppy linux 上，我设法使用名为dmraid. 这个工具有一种挂载 pdc 卷的方法，它是 Promise FastTrack 的 id。一旦我设法跳过安装它的一些箍，我就可以访问实际的 XFS 文件系统，但令我沮丧的是，它原来是 64kb 块大小。
这就是我开始在谷歌上搜索诸如“读取 xfs 64kb 块大小”之类的东西但一无所获的地方。只有几个答案说：“除非您修补内核，否则 linux 无法读取大于 4kb …
我最近经历了文件系统崩溃。我有一台服务器不间断地运行了大约 180 天，没有任何问题，但后来我注意到发生了奇怪的事情，显然 ext3 文件系统处于非常糟糕的状态。我测试了驱动器和内存，它们都很好。最终，我被迫对系统进行软管冲洗并完全重新安装。fsck.ext3只会让事情变得更糟。
现在，我不希望这种情况再次发生，所以这次我改用了 XFS，我觉得它比 ext3 更成熟，但我不知道如何监控文件系统的健康状况。xfs_check根本不会让我在安装时扫描设备。
那么，您如何在系统在线时监控 XFS 文件系统的健康状况？
我在笔记本电脑上运行了一个全新的 Lucid Lynx (Ubuntu 10.04)。我将文件系统定义为：
我在没有交流电源的情况下让机器过夜去做一些任务。第二天早上我发现它处于待机状态，任务完成，但无法访问文件系统。它给了我 I/O 错误
看来jfs和standby有问题。
无论如何，为了避免任何麻烦，我想将此挂载点从 jfs 格式移动到 ext4。
我可以在不丢失数据的情况下执行此操作，并且无需在转换完成之前将数据放置在临时位置吗？
很抱歉提到这一点，但我记得在 Windows 时代，我们会将 FAT16 更改为 FAT32 或将 FAT32 更改为 NTFS，而不必丢失数据。我希望这在 Linux 上可用。
更新 /home 文件系统是 xfs 而不是 jfs，而且由于某种原因，这个文件系统似乎有一个错误，我不得不重新安装操作系统两次，直到我最终使用整个 /
但是，作为结论，似乎没有办法进行转换
我无法理解 ceph 原始空间的使用情况。
我在 7 个服务器上有 14 个 HDD（14 个 OSD），每个 HDD 3TB ~ 总共 42 TB 原始空间。
ceph -s
osdmap e4055: 14 osds: 14 up, 14 in
pgmap v8073416: 1920 pgs, 6 pools, 16777 GB data, 4196 kobjects
33702 GB used, 5371 GB / 39074 GB avail
我创建了 4 个块设备，每个 5 TB：
df -h
/dev/rbd1 5.0T 2.7T 2.4T 54% /mnt/part1
/dev/rbd2 5.0T 2.7T 2.4T 53% /mnt/part2
/dev/rbd3 5.0T 2.6T 2.5T 52% /mnt/part3
/dev/rbd4 5.0T 2.9T 2.2T 57% /mnt/part4
df …