升级RAID固件和延迟，似乎已经增加。 您能否以最准确的方式提醒您检查磁盘读取和写入延迟？
我在RAID 5上运行mkfs.ext4，并花费数小时才能完成。 这是一个3TB，四个磁盘设置，我只是在做： mkfs.ext4 /dev/md0 我的条纹大小和宽度看起来不错。 我怎样才能加速呢？
我们目前有一台DELL 2950，配有RAID 5中的4个400Gb 10krpm SAS驱动器，其中一个驱动器出现故障。 没有任何相同的备件（不要拍我，这不是我的错），并且不能find任何相同的替代品，我们决定将驱动器升级到最新的“标准”尺寸和速度。 实质上，我们将购买7个450Gb 15krpm硬盘（这样我们就有了一个备用硬盘），并且慢慢地用新硬盘replace所有的硬盘。 这是我们从戴尔已经发现的。 用450Gb代替400Gb是可以的，但是只能使用400Gb 我们可以一次添加一个磁盘到arrays中，控制器将扩展这个arrays 主轴速度混合好，他们将基本上得到平均 我们不知道什么时候所有的驱动器被更换，现在是450Gb驱动器，RAID控制器会自动增长arrays，以使用每个磁盘上的所有450Gb，否则我们最终会浪费50Gb的空间驾驶？ 如果我们在每个驱动器上都浪费了50Gb空间，那么控制器会允许我们使用这些6 x 50Gb空间创build一个新的RAID 5arrays，然后在我们的操作系统中使用这个arrays。 如果我们不能使用50Gb，那么我们并不在乎（只有100英镑的存储空间！），但是知道我们并不认为我们可以使用它！
我有一个RAID 1arrays（2个磁盘镜像），其中一个磁盘sda失败。 所以我用一个新磁盘replace了坏磁盘，但似乎停滞在如何让第二个磁盘备份并作为arrays的一部分运行。 系统运行Ubuntu Server 9.04，configuration如下： MD0 => sda1，sdb1 MD1 => sda3，sdb3 MD2 => sda2，sdb2 mdadm –detail /dev/md0 显示两个驱动器： 0 /dev/sdb1 "Active Sync" 1 [nothing] "Removed" MD1和MD2看起来一样。 我发现的教程说，使用该命令将每个分区标记为失败： mdadm –manage /dev/md0 –fail /dev/sda1 但是，由于驱动器不在那里，我得到： mdadm: cannot find /dev/sda1: No such file or directory 我可以跳过失败的步骤吗？ 还是有其他的方式来失败一个不再存在的分区？ 或者，如果我从旧的驱动器复制分区表到新的，它会自动拿起它是替代？ 我是新来的，不想把它搞砸。 🙂
RAID控制器在负载情况下有多聪明？ 给定一个中等到高端的控制器和机柜（即当前标准的戴尔或惠普现成的套件…），RAID 5,10gb光纤，至less3/4的空间利用率，顺序与重型混合读/写访问文件，如可以在文件或电子邮件服务器上find… 实际的实施问题 ：给定相同数量的空间，less量大型高速驱动器（即4x 1TB 15,000 rpm）或更小数量的中等或低速驱动器（即9x 500GB 7200或更less） 10,000转）驱动器？ 理论问题 ：RAID机柜/控制器是否知道当前驱动器的磁头位置以及它们需要寻求的位置，以便能够以最小磁头行程距离将读取分配给磁带机？ 还是有关系？ 还有哪些其他variables可以最大限度地减less响应时间，并通过共享存储arrays上的大量非顺序小文件实现吞吐量最大化？ 请注意，由于数据的性质，高速caching不会发挥重要作用。
我正在研究如何制作DIY SASarrays，就像戴尔MD1000一样。 我的理解是这些设备不包含RAID控制器，而是将所有在SAS域中的驱动器都显示给主机。 我想build立相同types的数组。 MD1000和所有类似的设备都包含内置SAS扩展器，以便通过一根电缆向主机提供4个以上的驱动器。 我的问题是，他们使用什么SAS扩展器？ 我能find的唯一扩展卡是PCI卡，它必须连接到主板上。 我的JBODarrays是否需要主板，或者是否有独立于主板的独立（即哑）SAS扩展器？
我在18个月前购买了1TB希捷Barracuda 7200.12-ST31000528AS驱动器，因为它具有5年保修期，并且在Ubuntu服务器下与Samsung Spinpoint一起使用，作为软件RAID-1arrays的一半。 昨天，smartd开始报告一个问题： Jan 18 06:08:03 svr smartd[2672]: Device: /dev/sdb [SAT], 2 Currently unreadable (pending) sectors Jan 18 06:08:03 svr smartd[2672]: Device: /dev/sdb [SAT], 2 Offline uncorrectable sectors 我通过smartctl进行了调查，并在调度一些testing之后得到了以下结果： $ smartctl -l error /dev/sdb smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.0.0-14-generic] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA […]
我有一个带有LSI MegaRAID SAS 9260-4i控制器的服务器，带有3 x 2 TB磁盘的RAID-5。 我做了一些性能testing（使用iozone3），数字清楚地表明写caching策略也会影响读取性能。 如果将策略设置为WriteBack，则与WriteThrough相比，我可以获得大约2倍的读取性能。 写入caching如何影响读取性能？ 以下是设置的详细信息： megacli -LDInfo -L0 -a0 Adapter 0 — Virtual Drive Information: Virtual Drive: 0 (Target Id: 0) Name : RAID Level : Primary-5, Secondary-0, RAID Level Qualifier-3 Size : 3.637 TB Is VD emulated : Yes Parity Size : 1.818 TB State : Optimal Strip […]
大多数便宜的SATA磁盘驱动器被评为“每10 ^ 14位读取1次不可恢复的读取错误”。 这是什么意思？ 10 ^ 14位只有12.5 TByte。 如果我有一个完整的2TB磁盘，我把它复制到第二个磁盘，实际上有一个几乎1/6的机会，其中一个文件被破坏？ 如果发生这种情况，受影响的区块是否会被标记和重新分配？ 我这样认为是因为如果读重试成功，这不是一个不可恢复的读取错误。 但是现在我使用了很多这样的磁盘驱动器，我没有注意到坏块数量的增加，RAID控制器日志也没有显示任何读取问题。 编辑：RAID控制器每周巡逻读取每个磁盘，所以每年约100 TByte。 这还不到10 ^ 15位。 另一方面，2年内有50个磁盘共有4个磁盘出现故障，增加了出错率。 我没有足够的统计学意义的数据来作出陈述，但在我的情况下，实际的错误率似乎在10 ^ 14和10 ^ 15之间，这与规范是一致的。
我在我的小networking上有一个Windows Server 2003框。 它是一个Promise Fasttrak RAID控制器和两个并行ATA Western Digital硬盘，采用RAID-1（镜像）configuration。 当我设置这个时，我预计这将是一个可靠的存储系统，RAID控制器会告诉我什么时候出现问题，所以我可以做出反应。 但是，现在这两方面都失败了。 当我从该服务器复制文件时，我发现大文件已损坏。 例如，我最近将XP SP3networking安装（〜320MB）复制到另一台PC上。 提取失败。 我以为我之前使用过可执行文件，所以觉得很奇怪。 所以我再次从networking上复制它两次，并使用FileAlyzer ，我发现3个不同副本的MD5＆SHA1哈希值变化。 我从networking上的其他PC进行类似的testing，我可以复制这个错误。 更糟的是，RAID BIOS从不抱怨任何错误！ 这导致我相信控制器本身可能是坏的。 （注：我不认为这是networking，因为其他电脑可以可靠地将文件复制到对方。） 但是我的问题是： Windows有什么样的工具来“certificate”文件系统的行为是可靠的，RAID还是其他？ 例如，我购买了一个名为GoldMemory的工具，当我构build一台新的PC时，将运行一个详尽的内存testing。 我不会相信一台新电脑，直到它在GoldMemory下24个小时存活，没有内存错误。 我还购买了史蒂夫·吉布森的SpinRitetesting个人ATA磁盘。 有没有一个工具，我可以在Windows中运行testing一个NTFS文件系统，无论是否基于RAID，将反复读取和写入，并检查损坏？ 我不能相信我目前的服务器，如果我换出组件来尝试修复，或者build立一个新的系统，我想合理地确信我的文件系统在下注之前可靠地运行。 虽然我想相信一个品牌的RAID控制器和体面的硬盘驱动器是可靠的，但我现在需要采取Horatio Caine方法：“相信，但是validation。 谢谢你的帮助！ 🙂 更新： 所以，我在服务器上运行了一些本地testing（在cygwin中）以排除networking问题。 这应该给你一个我正在争论的想法。 BIG文件大部分时间都会发生问题。 （下面的是462MB。） $ md5sum VMware-workstation-6.5.2-156735.exe 7bf6145eb7d3e4fbcc945d87017fb6bd * VMware-workstation-6.5.2-156735.exe $ for（（c = 1; c <= 50; c ++））; 做md5sum VMware-workstation-6.5.2-156735.exe; […]