我有 3 个硬盘,在以下段落中分别命名为 /dev/sda、/dev/sdb 和 /dev/sdc,最新的在前。注:/dev/sdc有1个主分区/dev/sdc1,1个扩展分区/dev/sd2,3个逻辑分区/dev/sdc5、/dev/sdc6和/dev/sda7。
我使用 /dev/sda5 和 /dev/sdb5 创建了一个降级的 RAID 5 设备 /dev/md0(计划将 /dev/sdc5 添加到 RAID 以将其变为正常状态),然后使用 /dev/md0 作为唯一的 pv LVM,并使用 ext4 文件系统 /dev/mapper/vg0-lv0 创建了一个 lv。
不幸的是,在探索和使用 LVM 时,我dd if=/dev/zero of=/dev/sdc1 bs=64M count=10在删除 /dev/sdc1 后运行。所以实际上零被写入/dev/sdc2,并且分区表的损坏部分存储在/dev/sdc2和/dev/sdc5的开始部分。
当意识到这一点,我立即通过这样DD制成的/ dev / SDC的图像:dd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img。
几天后,我终于有时间尝试恢复/dev/sdc上的数据,实际上只有/dev/sdc7,因为它是唯一没有备份的分区。我用镜像文件 sdc.img 运行 testdisk,使用它的快速搜索功能重建分区表,将它丢失到 /dev/loop0。/dev/loop0p7(它是 /dev/sdc7 的映像)已返回并可挂载,所有文件似乎都没有问题。然后我跑去find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum为 /dev/loop0p7 上的所有文件构建 MD5 校验和列表。
在处理物理 /dev/sdc 设备时,测试磁盘的快速搜索不会找到所有分区,深度搜索会。然后我使用类似的命令为物理 /dev/sdc7 上的所有文件构建了 MD5 校验和列表 sdc7.md5sum。将其与 sdc7_image.md5sum 进行比较时,我发现有 4 …
Red Hat 建议不要在 SSD 上使用 mdadm RAID 1 的其他问题中已经提到过。
Red Hat 还警告说,不建议在 SSD 上使用软件 RAID 级别 1、4、5 和 6。在这些 RAID 级别的初始化阶段,一些 RAID 管理实用程序(例如 mdadm)会写入存储设备上的所有块以确保校验和正常运行。这将导致 SSD 的性能迅速下降。
我明白这背后的原因。但是,我怀疑这是在mdtrim到来之前编写的,它是专门为 mdadm RAID 1 设计的。这是否回避了问题?如果我对 TRIM 的理解是正确的,那么我相信它确实如此,但我不确定,因此我在问。
不过,TRIM 可能不适合我。我需要这个用于生产系统,而 mdtrim 看起来充其量是实验性的。更重要的是,我需要强大的加密功能,研究表明,TRIM 通过突出显示驱动器的哪些部分实际在使用,从而透露了太多信息。有什么方法可以避免性能问题并且仍然具有强大的加密功能?我想知道是否有可能进行部分 TRIM,释放一些块以提高性能,但不要太多以至于放弃太多。
我看到的一个建议是只使用每个磁盘的 80% 左右,这样在 mdadm 进行初始检查后,仍有少量块未使用。但是这些块不会是第一个在随后使用磁盘时使用的块吗?它们仍然会很快用完,然后我也不会好过,对吧?
前几天我有了一个我认为是个好主意 - 我可以买一堆便宜的 USB 2.0 驱动器,并填满我的 7 端口 USB 集线器中的空间,用于超快速 RAID 设备!但在白天,它看起来并不那么好。我认为这至少会给我更快的读取时间,但是写入时间会如何?哪种 RAID 级别最适合此目的?(我正在尝试优化速度,任何数据都不需要特别安全。)
如果这是一个“好主意”,或者至少不是完全鲁莽,我将如何设置它?我运行 Ubuntu 12.10 和 Windows 8。
RAID 1 的驱动器大小是否必须完全相同?
RAID 选项是灰色的——一些研究表明驱动器需要具有相同的大小,但它们的大小是否必须完全相同(以字节为单位)或者是否有一些余地(可能是百分比)?
我有两个 1TB 驱动器,不同的制造商。一个是 953980 Mb,另一个是 953740 Mb,所以两者都声称是 1TB,但相差 240MB。
服务器规格为:
我正在设置一个带有两个 3TB 硬盘驱动器作为存储支持的系统。由于它是一个桌面工作站,我想知道以下磁盘设置:
sda
+ /boot with 500MB
+ btrfs for the remaining GBytes
sdb
+ btrfs for all the 3000GB
Run Code Online (Sandbox Code Playgroud)
然后我考虑将single-mode 用于数据/并/home使用raid1作为数据模式为(以及可能的其他人)创建一个子卷。当前的(内核 3.7.X)btrfs 可以实现吗?有没有人有资源,我找不到任何东西。
更新:我做了一个小测试设置,其中包含两个作为环回设备连接的普通文件,用于播放。在这些文件上,我创建了一个普通的 btrfs。然后我做了以下事情:
btrfs subvolume create test
dd if=/dev/urandom of=foo bs=1024 count=1 # use random data to prevent dedup
dd if=/dev/urandom of=test/bar bs=1024 count=1 # use random data to prevent dedup
btrfs balance start -dconvert=raid1 test
btrfs balance start -dconvert=single .
btrfs filesystem df .
Run Code Online (Sandbox Code Playgroud)
这表明文件系统在单模式下使用,而不是部分 RAID1 …
我在这里工作的服务器上有一个新的 RAID-5 设置。我刚刚创建了 RAID-5,它的大小略高于 2.7 TB。现在,我知道 MBR 不支持超过 2.2 TB 的任何内容,但是,我在网上看到一些帖子说某些操作系统,例如 Windows XP 32 位,无法读取 GPT 磁盘。现在,如果我将其设置为 GPT 并将其分区为服务器的多个驱动器,XP32 上的用户是否能够在网络上看到和使用这些驱动器,或者他们实际上根本看不到它们?
正如标题所暗示的那样简单。
/dev/sda是一个来自/dev/md127- RAID1 驱动器的单元。
我目前正在运行一个测试 - 启动了一个smartctl -t long /dev/sda.
之后,我开始通过 WinSCP (SFTP) 将文件复制到挂载的 mdadm 阵列。
我没有注意到任何性能下降,但我有点不确定 - 不是系统管理员,我只是在开发一个自动化系统。
在驱动器进行智能检查时“使用”(写入/读取)磁盘是否安全?会出什么问题?有什么缺点吗?
如果不是,是不是表示RAID模式下的Btrfs是完全抗断电的?
我有一个带有 2 个 3TB 驱动器的家庭媒体服务器。它目前使用 mdraid (1)、LVM 和 EXT4 进行设置。设置是使用 ncurses Ubuntu Server 安装程序完成的。
目标
将设置转换为使用 ZFS (RAIDZ) 并添加第三个 3TB 驱动器。我想启用即时压缩和重复数据删除。转换不需要重新安装 Ubuntu 和所有软件包。应该没有数据丢失(当然除非磁盘在此过程中崩溃)。
我该怎么做呢?
额外的问题,使用 btrfs 这样做是否更好,因为据我所知,我可以用一个磁盘初始化阵列,复制数据,然后用 btrfs 添加第二个磁盘,而不是用 zfs?
我的/proc/mdstat:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md4 : active raid1 sdb2[1] sda2[0]
2930070069 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Run Code Online (Sandbox Code Playgroud)
我的 pvs -v
Scanning for physical volume names
PV VG Fmt Attr PSize PFree DevSize PV UUID
/dev/md4 Data lvm2 a- 2,73t 0 2,73t …Run Code Online (Sandbox Code Playgroud) 我们经常看到有关为 RAID 阵列混合硬盘驱动器型号或品牌的建议(也适用于任何磁盘组,例如 ZFS 池)。
基本原理是:同一批次生产的驱动器往往具有相同的内在问题,因此往往会一起出现故障。
多年来,我在 60 多个系统上使用相同的驱动器进行 RAID。我从来没有注意到任何问题。
但其他人会。
观点、统计数据、巧合、运气、命运……还是真正的危险?
是否有任何关于 RAID 中驱动器配对的(严肃的)研究或资料来源?
到目前为止,我知道的唯一好的论点是关于固件:当驱动器由于固件错误而变砖时,孪生很可能会在很短的时间内出现故障。但也是另一批次的类似驱动器。这是一个罕见的事件,但我们谈论的是两种方法之间的小改进,因此罕见事件在平衡中很重要。