考虑到主题的非常具体的性质（我们不是在谈论邮箱，只是假脱机；我们不是在谈论其他文件系统，只是 ext3；等等......）以及所涉及软件的成熟度（linux 内核） 、ext3fs、postfix）我认为应该或多或少地就文件系统相关调整的最佳实践达成一致。
我正在尝试对它们进行汇总：
data=journal成为最近内核中的默认值（大约 2.6.30 IIRC），所以我们应该可以接受atime必须打开，但 Postfix 文档noatime在谈论Incoming Queue时建议打开。这是否意味着 postfixatime仅需要某些队列目录，而将从noatime其他队列目录中受益？noatime如果我们不使用ETRN，我们可以使用吗？nodev,noexec,nosuid- no* 不会阻止您设置属性（postfix 使用 exec attr），它们只是不会产生任何效果（我们不会从假脱机中运行任何内容）fsync()Wietse 引用的问题和/或可能与 ext3fs 的/选项chattr -S相关，但我对它们的理解不够。使用选项挂载文件系统相当于整个文件系统？看起来它会提高性能，但这会带来“系统崩溃后丢失邮件”的风险还是真的“在 /var/spool/postfix 上安全”？syncasyncasyncchattr -R -S参考：
有时，当您连接到多路径 iSCSI 目标时，您只能访问其部分门户。当启动器直接连接到目标的以太网端口（而不是通过交换机）时，这种情况很常见。
[我手头的此类基础设施的实际示例是具有 4 台直接连接服务器的 Dell MD3200i / MD3220i SAN]
当您进行 iSCSI 发现时，启动器将获得所有门户的列表，甚至包括那些它实际上未连接到且无法与之通信的门户。使用双控制器，每个控制器有四个端口，您会看到类似以下内容：
# iscsiadm --mode discovery --type sendtargets --portal 192.168.130.101
192.168.130.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.131.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.132.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.133.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.130.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.131.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.132.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11C0123456789012345678901234
192.168.133.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
...但主机物理连接到第一个 (192.168.130.101) 和第六个 (192.168.131.102) 端口，因此它永远无法与其他六个门户通信。
按照 iSCSI 目标的典型文档，最终会得到发起者“已知”的所有门户，但发起者只会在感兴趣的门户上进行实际登录（上例中为其中两个）。
是否应该从启动器的配置中删除“无法访问”的配置？即使没有实际登录，他们也会造成“已知”的任何问题吗？
在 VMware ESXi 5.5 中使用最近 (>= 2014) 发行版创建新的 Linux 虚拟机时，是否应该使用discard选项挂载其文件系统？
我假设 VM 的管理员不一定知道实际的底层存储是什么，并且 VM 使用的是推荐的“虚拟控制器”，我希望/怀疑如果 VM 发出TRIM命令，它们可能对瘦有用虚拟磁盘（即使它们位于非 SSD 存储上）或 SSD 存储上的厚虚拟磁盘。
discard当在 ESXi VM 中使用时，挂载选项是否真的起作用（例如，即使虚拟控制器是 SCSI 控制器而不是 SATA 控制器）？
当 VM 使用此类discard选项时，vSphere >= 5.5 是否会执行任何操作？
现在很多服务器系统使用2.5"硬盘，afaik是因为它们可以在同一个机箱中放置更多的主轴，而且可能使用更少的功率。当我不需要/不能放置更多磁盘时，使用2.5"磁盘有什么好处吗？
例如，我可以以类似的价格购买一个带有 4x3.5" 或 4x2.5" 磁盘的 1U 盒子，但 3.5" 的磁盘会更大（我的意思是千兆字节）。当然我说的是类似的磁盘（例如 SAS 10k 或 SAS 15k）。
给定相同的转速和磁盘数量，2.5" 磁盘是否比 3.5" 磁盘有任何优势？
我们有一个 iSCSI SAN，它将用作虚拟机的后备存储。我们使用 Xen 并将 LUN 直接呈现为 VM 的块设备（因此没有文件系统在每个 VM 上都有文件，就像 VMware 在使用 VMFS 数据存储时所做的那样）。
我想知道为每个 vm 的操作系统和数据提供单独的 LUN 是否更好（例如，一个小 lun 用于安装 Linux，一个大 lun 用于保存邮箱，一个小 lun 用于 linux，一个大 lun 用于网络服务器数据，以及等等...）或者每个虚拟机只有一个大 LUN。
看看前者，那么人们可能会问“那么为什么不为交换分区设置另一个 LUN”，直到每个 lun 上只有一个“分区”。
请记住，所有这些 LUN 都来自 SAN 上完全相同的 RAID 卷，因此没有必要区分磁盘速度或 RAID 级别。
在当前版本的 Puppet 和 Facter 中，我得到了相同的信息lsbdistid和operatingsystem事实——我不看，osfamily因为在 Gentoo Linux 上它报告一个通用的“Linux”字符串。
在 Puppet 模块中使用该信息时（例如，用于选择要安装的软件包名称）是否有任何技术原因或已建立的共识来使用lsbdistid或operatingsystem？
iscsi ×2
linux ×2
ethernet ×1
ext3 ×1
facter ×1
hard-drive ×1
hardware ×1
jumboframes ×1
lun ×1
multipath ×1
performance ×1
postfix ×1
puppet ×1
storage ×1
switch ×1
trim ×1
vlan ×1
vmware-esxi ×1
xen ×1