主页 / server / 问题

问题[raid5](server)

Martin Hope
ATLief
Asked: 2022-03-01 15:44:55 +0800 CST
  • 15

假设您有两个 RAID 阵列，一个有 N 个磁盘，一个有 N+1 个磁盘。具有 N 个磁盘的阵列被格式化为RAID 5并单独放置，而另一个阵列在其中一个磁盘被移除之前被格式化为RAID 6 。现在两个阵列都有 N 个磁盘，N-1 个磁盘的可用存储空间，并且可以在丢失一个（更多）磁盘的情况下幸存下来。

除了 RAID 控制器使用的任何元数据之外，这两个阵列之间是否有任何区别（在数据布局、性能和可靠性方面）？我是否可以将缺少一个磁盘的 RAID 6 阵列转换为具有最少“重塑”/“重写”的预期磁盘的 RAID 5？

我知道 RAID 5 和 RAID 6 中有不同的“策略”/“对齐方式”，但这可能超出了这个问题的范围。也许应该假设两个阵列都使用两个 RAID 级别通用的策略。

performance raid raid5 raid6 fault-tolerance
Martin Hope
ADY
Asked: 2022-01-28 11:13:14 +0800 CST
  • 1

我刚刚订购了一台新的 PowerEdge R650，它将成为我们公司的主服务器。它将运行带有 10 到 12 个虚拟机的 HyperV，主要是 Windows，但也有一些 Ubuntu。所有标准：域控制器、文件服务器、Web 服务器、Exchange（混合如此少的流量/存储）等。最密集的磁盘将是 SQL Server，800Gb 的数据库预计将在未来三年内增长到 1.1Tb服务器更换。

目前对于数据驱动器，我在 RAID 5 中有 5 个 1.92Tb SAS 12Gb 企业混合使用 SSD，总共 7.2Tb。我们正在使用其中的 3.8Tb。新服务器将在 PERC 755 RAID 控制器上配备 6 个相同类型的驱动器。操作系统驱动器将是带有两个 480 SSD 的 RAID1。

每晚对每个虚拟机进行完全备份，并且每周在异地进行复制。因此，我关心容错，但并不过分担心，好像我们遇到了故障，我们会启动副本并恢复自上次完整备份以来发生的任何变化。对于这些，最有效/最宽容但最快的配置是什么？我认为一个大型 RAID5 阵列不是即使我们目前正在运行的也没有任何问题。两个 RAID5 阵列每个都是 3.84Tb，我可以相应地拆分虚拟机。一个 RAID10 给了我 5.76 并且还有足够的未来空间，但我正在读取/写入单个阵列。我什至可以创建三个独立的 RAID1 阵列，但这对我来说似乎有点矫枉过正，但可能比 RAID10 更有意义。

有什么建议么？在上述每种情况（RAID5、2x RAID5、1x RAID10 或 3x RAID1）中，我将拥有至少 2Tb 的扩展空间，因此最终磁盘大小不是问题，只是性能/效率/容差。

raid5 raid10 windows-server-2019 raid1 dell-perc
Martin Hope
Rinaldo Jonathan
Asked: 2021-10-09 17:06:05 +0800 CST
  • -1

自从（我认为）3 年前我就有了这个问题，但是由于我从未真正计划过构建服务器，所以我只是耸了耸肩。但是今晚，我真的无法入睡，因为这个紧迫的问题。

假设我有 3 个 2TB 磁盘。根据 Wikipedia，RAID 5 至少需要三个磁盘，通过这种设置，我可以获得 4TB 的 RAID 容量。
现在，让我们用 2 个 1TB 磁盘替换其中一个 2TB 磁盘。现在我有 2x 2TB 磁盘和 2x 1TB 磁盘。是否可以对 1TB 磁盘进行 RAID 0（以获得 2TB），然后对所有磁盘进行 RAID 5？
更糟糕的是，让我们用 4x 500GB 磁盘替换另一个 2TB 磁盘，然后对它们进行 RAID 0。现在我想用（RAID 0 2x 1TB）、（RAID 0 4x500GB）和 2TB 磁盘制作 RAID 5。

是的，我已经知道 RAID 0 的缺点，即当其中一个磁盘发生故障时，所有数据都会丢失。但是，这是最重要的 RAID 5。假设 500GB 失败，我可以在那里再放一个 500GB 磁盘，然后从 RAID 5 重建所有内容。对吗？正确的？

更糟糕的是，让我们用 2x500GB 磁盘替换其中一个 1TB 磁盘，然后将它们 RAID 0，然后再用 1TB RAID 0 将它们变成 2TB，依此类推……

这甚至可能吗？这值得么？
现在更糟糕的是，让我们从 USB 2.0 运行所有磁盘 :(

raid raid5 software-raid raid0
Martin Hope
jrwren
Asked: 2021-07-01 12:40:37 +0800 CST
  • 3

文件系统位于 LVM RAID5 上。它似乎工作正常：

$ sudo pvs
[sudo] password for jrwren: 
  PV         VG     Fmt  Attr PSize    PFree 
  /dev/sda2  datavg lvm2 a--    <7.28t  2.80t
  /dev/sdb2  datavg lvm2 a--    <3.64t     0 
  /dev/sdc2  datavg lvm2 a--    <7.28t <7.28t
  /dev/sdd2  datavg lvm2 a--    <7.28t     0 
  /dev/sde2  datavg lvm2 a--    <7.28t 73.82g
  /dev/sdf1  datavg lvm2 a--    <3.64t     0 
  /dev/sdg2  datavg lvm2 a--    <7.28t  3.99t
  /dev/sdh2  datavg lvm2 a--  <447.11g  8.00m
  /dev/sdi2  datavg lvm2 a--    <9.10t  2.21t
 $ sudo lvs
  LV       VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lxd2     datavg -wi-ao---- 147.10g                                                    
  mirrored datavg -wi-ao---- 300.00g                                                    
  m        datavg Rwi-aor---   3.52t                                    100.00          
  m3       datavg Rwi-aor---   4.00t                                    100.00          
  mu       datavg Rwi-aor---   1.00t                                    100.00          
  nomirror datavg -wi-ao----   2.20t                                                    
  photos   datavg Rwi-aor--- 200.00g                                    100.00          
  stor     datavg Rwi-aor--- 300.00g                                    100.00          
  storj    datavg -wi-ao----   1.00t                                                    
  t        datavg Rwi-aor---   6.00t                                    100.00          
  t2       datavg Rwi-aor---   3.90t                                    100.00

我有一个进程对名为 m 的逻辑卷进行多次读取。这是设备 dm-12。最终，它会随着以下内核消息而死。

Jun 30 16:02:33 delays kernel: [393661.035286] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: com[68/1946]t main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.039726] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.044175] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)                               
Jun 30 16:02:33 delays kernel: [393661.048584] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.054717] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.060977] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.063736] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.066283] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.068773] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:02:33 delays kernel: [393661.071232] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

我卸载文件系统并运行 e2fsck：

$ sudo e2fsck -p /dev/datavg/m
movies contains a file system with errors, check forced.
movies: Inode 118751237 has an invalid extent node (blk 475078659, lblk 0)


movies: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
$ sudo e2fsck -y /dev/datavg/movies
e2fsck 1.45.7 (28-Jan-2021)
movies contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 177471496 has an invalid extent node (blk 709943175, lblk 0)
Clear? yes
...

Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(709943175--709943176) -(868210688--868212735) -(868214784--868216831) -(868253696--868255743) -(868257792--868259839) -(868886528--868888575) -(868892672--868894719) -(868896768--868898815) -(868900864--868902911) -(868904960--868907007) -(868909056--868911103) -(868913152--868917247) -(868921344--868923391) -(868925440--868927487) -(868929536--868931583) -(868933632--868935679) -(868937728--868939775) -(868941824--868943871) -(868945920--868947967) -(868950016--868954111) -(868958208--868960013) -(869894144--869922573)
Fix? yes

Free blocks count wrong for group #21665 (24561, counted=24563).
Fix? yes

Free blocks count wrong for group #26495 (28672, counted=32768).
Fix? yes

Free blocks count wrong for group #26497 (18432, counted=22528).
Fix? yes

Free blocks count wrong for group #26516 (22528, counted=32768).
Fix? yes

Free blocks count wrong for group #26517 (16384, counted=32768).
Fix? yes

Free blocks count wrong for group #26518 (16626, counted=26624).
Fix? yes

Free blocks count wrong for group #26547 (2290, counted=30720).
Fix? yes

Free blocks count wrong (366951912, counted=367025158).
Fix? yes



movies: ***** FILE SYSTEM WAS MODIFIED *****
movies: 6896/236224512 files (20.8% non-contiguous), 577868794/944893952 blocks
$ sudo e2fsck -p /dev/datavg/movies
movies: clean, 6896/236224512 files, 577868794/944893952 blocks

它说它很干净，所以我重新安装它并重新运行阅读软件。

几分钟后：

Jun 30 16:34:49 delays kernel: [395595.309814] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.317838] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.320836] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:34:49 delays kernel: [395595.323418] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:35:14 delays kernel: [395619.785771] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0) 
Jun 30 16:35:14 delays kernel: [395619.793135] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

这里发生了什么？LVM 是否腐败并在欺骗我？有没有我可以运行检查的命令？我应该运行一个坏块（e2fsck -c）还是什么？

内核没有相应的 LVM 消息。如果底层磁盘有问题，我预计会出现 LVM 错误。到底是怎么回事？

更新：有人要求 dmesg 输出。这正是上面 EXT4-fs 消息的内容。dmesg 输出中除了标准引导消息之外的唯一其他消息是重复的：

[527724.593062] rptaddrs[3948921]: segfault at 7ffc7a7a50b5 ip 00007fd9f0f86820 sp 00007ffc7a7a3fc8 error 4 in libc-2.28.so[7fd9f0e4c000+148000]                                                                                                                  [527724.593075] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44
lvm filesystems raid raid5 ext4
Martin Hope
elliotp
Asked: 2020-11-10 12:27:54 +0800 CST
  • 3

示例硬件/主机：

  • 现代 64 核 CPU，128GB 内存
  • 8 个美光 Pro 15.36TB u.2 SSD
  • 每个设备通过专用 Oculink 连接 SSD（无背板或 PCIe 共享）
  • Ubuntu 20.04

用例：

  • 数百台主机的备份服务器。备份是通过增量 rsync 执行的，首先是来自远程主机的 rsync，然后是本地副本（使用 cp）以创建快照。- - - 数以百万计的小文件（电子邮件、html 文件等）是典型的备份。
  • 在任何时候，服务器都可以处理 50 个传入的 rsync（cpu 轻加密算法和无压缩）
  • 冗余虽然是有利的，但不是必需的。最多单个驱动器故障。
  • 文件轮换所需的极端本地 i/o
  • rsync 和硬链接差异复制（'rsnapshot'）的使用不能改变，这是已部署并投入生产的备份软件所要求的 - 所以 BTRFS 快照是不可能的。

我提出了两种可能的解决方案：

  1. 分片我的数据存储，没有冗余。BTRRFS 中基于每个驱动器的格式，并使用内联 LZO 压缩进行安装。
  • 优点：简单轻量，无raid管理开销
  • 优点：独立故障，在磁盘故障时只有一小部分备份丢失，可以快速重新建立
  • 优势：获得的最大总容量
  • 缺点：容量管理的复杂性——没有一个大容量意味着战略性地平衡特定磁盘上的数据以充分利用它们
  • 缺点：磁盘故障确实会丢失数据
  1. 一个大卷跨所有磁盘的 ZFS RAIDz1/2
  • 优点：1或2个磁盘故障冗余
  • 优点：易于管理，所有内容都集中在一个巨大的体积中 - 空间充足。
  • 缺点：损失 1 或 2 个磁盘的容量

问题：与选项 1 相比，是否存在显着的 ZFS RAID 管理开销会降低阵列的性能？- 在他设计的每个级别以最大限度地提高操作系统和 SSD 之间的磁盘吞吐量的配置中，以每秒 10 千兆比特为单位，ZFS RAID 管理的开销是否会导致性能显着下降和/或 CPU 或内存过载？

谢谢你。

ssd zfs raid5 btrfs hpc
Martin Hope
ZioByte
Asked: 2020-11-09 03:32:46 +0800 CST
  • 1

我有一堆相同的全新 HD（4*3T，如果重要的话）我需要用于单个 RAID5 阵列（Linux mdmadm）。

是否将整个组合内容用于单个文件系统（ext4？），或者我将使用 LVM 在多个虚拟驱动器中进行分区，目前还没有决定。

RAID5 将跨越磁盘的全部内容，我不需要引导扇区（从另一个设备引导）。

在这种情况下，使用单个分区对驱动器进行“传统分区”与使用整个未分区设备作为基础是否有任何优点（或缺点）mdmadm assemble？

用不同的方式说同样的事情：做有什么好处吗

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --spare-devices=1 /dev/sde1

相对

mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd --spare-devices=1 /dev/sde

除了前者的一些部门的微不足道的损失（这是一个可以忽略不计的“缺点”）？

raid raid5 software-raid
Martin Hope
guyyst
Asked: 2020-05-02 09:37:39 +0800 CST
  • 1

编辑：

此 wiki中的场景，其中 1 个驱动器的事件计数略低于阵列的其余部分，另一个驱动器的事件计数显着低于阵列的其余部分，建议在组装--force时省略最旧的驱动器，然后添加它（或者如果磁盘是新的驱动器，则实际上很糟糕）在阵列以降级状态组装后返回。

在我的情况下这样做是否有意义，或者--force考虑到两个过时的驱动器具有相同的事件计数，尝试与所有 4 个驱动器进行组装是否更可取？

鉴于我有限的 RAID 知识，我想我会在尝试任何事情之前询问我的具体情况。丢失这 4 个驱动器上的数据对我来说并不是世界末日，但找回它仍然很好。

我最初将 RAID5 阵列从旧机器迁移到新机器，没有任何问题。我用了大约 2 天，直到我注意到 2 个驱动器没有在 BIOS 引导屏幕中列出。由于进入 linux 后阵列仍然组装并且工作正常，我并没有考虑太多。

第二天阵列停止工作，所以我连接了一张 PCI-e SATA 卡并更换了我所有的 SATA 电缆。之后，所有 4 个驱动器都出现在 BIOS 启动屏幕中，所以我假设我的电缆或 SATA 端口导致了最初的问题。

现在我留下了一个损坏的数组。mdadm --assemble将两个驱动器列为(possibly out of date)，并mdadm --examine显示22717过期驱动器和23199其他两个驱动器的事件。这个 wiki 条目表明<50可以通过组装来克服事件计数差异--force，但是我的 4 个驱动器被482事件分开。

以下是所有相关的突袭信息。在阵列发生故障之前，我知道所有 4 个驱动器的主 GPT 表都已损坏，但由于当时一切正常，我还没有解决这个问题。

mdadm --assemble --scan --verbose

mdadm: /dev/sde is identified as a member of /dev/md/guyyst-server:0, slot 2.
mdadm: /dev/sdd is identified as a member of /dev/md/guyyst-server:0, slot 3.
mdadm: /dev/sdc is identified as a member of /dev/md/guyyst-server:0, slot 1.
mdadm: /dev/sdb is identified as a member of /dev/md/guyyst-server:0, slot 0.
mdadm: added /dev/sdb to /dev/md/guyyst-server:0 as 0 (possibly out of date)
mdadm: added /dev/sdc to /dev/md/guyyst-server:0 as 1 (possibly out of date)
mdadm: added /dev/sdd to /dev/md/guyyst-server:0 as 3
mdadm: added /dev/sde to /dev/md/guyyst-server:0 as 2
mdadm: /dev/md/guyyst-server:0 assembled from 2 drives - not enough to start the array.

mdadm --examine /dev/sd[bcde]

/dev/sdb:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 356cd1df:3a5c992d:c9899cbc:4c01e6d9
           Name : guyyst-server:0
  Creation Time : Wed Mar 27 23:49:58 2019
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 7813772976 (3725.90 GiB 4000.65 GB)
     Array Size : 11720658432 (11177.69 GiB 12001.95 GB)
  Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=688 sectors
          State : clean
    Device UUID : 7ea39918:2680d2f3:a6c3b0e6:0e815210

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri May  1 03:53:45 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 76a81505 - correct
         Events : 22717

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)



/dev/sdc:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 356cd1df:3a5c992d:c9899cbc:4c01e6d9
           Name : guyyst-server:0
  Creation Time : Wed Mar 27 23:49:58 2019
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 7813772976 (3725.90 GiB 4000.65 GB)
     Array Size : 11720658432 (11177.69 GiB 12001.95 GB)
  Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=688 sectors
          State : clean
    Device UUID : 119ed456:cbb187fa:096d15e1:e544db2c

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri May  1 03:53:45 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : d285ae78 - correct
         Events : 22717

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)



/dev/sdd:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 356cd1df:3a5c992d:c9899cbc:4c01e6d9
           Name : guyyst-server:0
  Creation Time : Wed Mar 27 23:49:58 2019
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 7813772976 (3725.90 GiB 4000.65 GB)
     Array Size : 11720658432 (11177.69 GiB 12001.95 GB)
  Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=688 sectors
          State : clean
    Device UUID : 2670e048:4ebf581d:bf9ea089:0eae56c3

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri May  1 04:12:18 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 26662f2e - correct
         Events : 23199

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)



/dev/sde:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 356cd1df:3a5c992d:c9899cbc:4c01e6d9
           Name : guyyst-server:0
  Creation Time : Wed Mar 27 23:49:58 2019
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 7813772976 (3725.90 GiB 4000.65 GB)
     Array Size : 11720658432 (11177.69 GiB 12001.95 GB)
  Used Dev Size : 7813772288 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=688 sectors
          State : clean
    Device UUID : 093856ae:bb19e552:102c9f77:86488154

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri May  1 04:12:18 2020
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 40917946 - correct
         Events : 23199

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : A.AA ('A' == active, '.' == missing, 'R' == replacing)

mdadm --detail /dev/md0

/dev/md0:
           Version : 1.2
        Raid Level : raid0
     Total Devices : 4
       Persistence : Superblock is persistent

             State : inactive
   Working Devices : 4

              Name : guyyst-server:0
              UUID : 356cd1df:3a5c992d:c9899cbc:4c01e6d9
            Events : 23199

    Number   Major   Minor   RaidDevice

       -       8       64        -        /dev/sde
       -       8       32        -        /dev/sdc
       -       8       48        -        /dev/sdd
       -       8       16        -        /dev/sdb

fdisk -l

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFRX-68N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 79F4A900-C9B7-03A9-402A-7DDE6D72EA00

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 7814035455 7814033408  3.7T Microsoft basic data


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdc: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFRX-68N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 43B95B20-C9B1-03A9-C856-EE506C72EA00

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048 7814035455 7814033408  3.7T Microsoft basic data


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdd: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFRX-68N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1E276A80-99EA-03A7-A0DA-89877AE6E900


The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sde: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFRX-68N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 11BD8020-C9B5-03A9-0860-6F446D72EA00

Device     Start        End    Sectors  Size Type
/dev/sde1   2048 7814035455 7814033408  3.7T Microsoft basic data

smartctl -a -d ata /dev/sd[bcde]

作为pastebin，因为它超过了字符限制：https ://pastebin.com/vMVCX9EH

linux raid mdadm raid5 software-raid
Martin Hope
MKZ
Asked: 2020-04-23 21:31:12 +0800 CST
  • 4

RAID5 阵列中的一个 SAS 磁盘昨天发生故障，我正要更换它，但是我注意到前机箱与其余磁盘不匹配。该阵列由 300GB 10K SAS 磁盘和左侧机箱组成。我找到了一个带有正确机箱的 300GB 10K SAS 磁盘。在打开密封包装之前，这些可以互换吗？

我认为服务器是 HP Proliant DL360 G8（目前不在现场）。

来自 https://www.ebay.com/itm/HP-1TB-6G-SAS-7-2K-SFF-SC-MDL-G8-HDD-652749-B21-653954-001-/381206195989?ef_id=EAIaIQobChMI6- 6Uubr_6AIV0yMrCh2EYwPrEAQYAiABEgJUCvD_BwE:G:s

https://tshop.r10s.com/f4f/087/47b3/4dcf/8094/108e/4696/114de88dc654ab3a295add.jpg

sas hp-proliant raid5 hp-smart-array hpe