尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Linux存储三层实战:RAID、LVM与磁盘配额配置指南
做运维这行最怕的不是服务挂了而是服务没挂、磁盘先满了或者是磁盘明明还有空间、应用却写不进去。我待过的几个机房里存储层出事子的频率远高于 CPU 和内存原因很朴素——CPU 和内存不够监控一报警你加机器就行存储一旦规划歪了扩容要停机、迁移要备份、数据丢了就真没了。这篇内容聊的就是把LVM 逻辑卷管理、磁盘配额、RAID 磁盘阵列这三样东西捏在一起用的一套完整打法从几块裸盘开始做出一个既有冗余、又能弹性扩容、还能限制单个用户乱占空间的存储目录最后跑通一整套配置流程。适合正在管服务器、准备上线新业务目录、或者被磁盘满了但文件删不掉这类问题折磨过的朋友。不管你是刚接触 Linux 存储的新手还是已经用过 mdadm 但没系统串过 LVM 的老人下面这些踩坑记录和参数取舍应该都能直接抄。1. 整体方案设计与选型思路拆解1.1 三套技术各自解决的是哪一类问题很多人第一次接触这三个名词时会犯迷糊觉得它们功能重叠实际上分工非常清楚。RAID 解决的是盘坏了数据还在不在它站在物理磁盘这一层把多块硬盘组成一个逻辑设备通过镜像或者校验码实现冗余顺带提升一点读写吞吐。LVM 解决的是空间不够了能不能不停机加它站在块设备这一层把一块或多块物理设备包括 RAID 阵列抽象成卷组再从卷组里切逻辑卷逻辑卷可以随时变大、跨盘分布。磁盘配额解决的是这台机器上多个用户共用一块盘怎么防止某一个人把空间吃光它站在文件系统这一层按用户、组或项目维度限制 inode 数量和块数量。这三层叠起来逻辑是这样的底层硬盘做成 RAID 阵列保证不丢数据阵列交给 LVM 变成可伸缩的卷组逻辑卷格式化成文件系统挂到业务目录最后在文件系统上开配额限制使用者。缺任何一层都会留下短板——只有 RAID 没 LVM扩容得重新做阵列只有 LVM 没 RAID一块盘挂了整个卷组跟着废两者都有但没配额一个失控的日志进程就能把整台机器的写入堵死。1.2 为什么要在同一套环境里叠加使用我见过两种极端的做法。一种是什么都上八块盘做 RAID6上面套三层 LVM再开项目配额结果一台机器光存储配置就写了一百多行文档后来扩容时没人敢动。另一种是什么都不上四块盘各自挂载应用自己往 /dev/sdb1 里写盘一坏数据全没还找不回来。合理的做法是按数据重要性和增长预期来决定层级。我一般的判断标准是数据丢了业务会停摆超过半天就必须上 RAID目录容量未来一年内预计增长超过 50%就套 LVM这块盘上有三个以上不同的使用者不同的系统用户、不同的业务模块、不同的项目组就开配额。三条都命中的场景其实很常见比如日志归档目录、数据集存放目录、多租户的共享存储这时候三层叠加才有意义。1.3 环境与硬件选型的几个实际考量盘的选择上做 RAID 的硬盘尽量同型号、同容量、同批次转速一致。原因不是玄学是阵列的可用容量取决于最小那块盘而重建速度取决于最慢那块盘混插会让整个阵列的性能被拖到地板。我有一次图省事拿两块 4T 和一块 2T 拼了个 RAID5结果可用容量只有 4T白白浪费了一块盘的空间。系统层面mdadm负责软 RAID主流发行版的软件源里都有不用额外编译。LVM2 工具包同理。配额这块要注意文件系统的差异ext4 用usrquota,grpquota挂载参数配合quota系列命令XFS 用uquota,gquota或者等价的usrquota,grpquota配合xfs_quota两套命令完全不通用别记混。提示如果业务目录已经存在且正在被写入改文件系统类型或者加配额参数都需要重新挂载这一步会短暂中断写入。上线前规划好比事后补救省十倍力气。2. RAID 磁盘阵列的级别取舍与建阵实操2.1 RAID 0/1/5/6/10 到底怎么选选级别本质是在容量、性能、冗余这三个值之间做减法没有全能选手。我把常用级别的实际表现整理成一张表都是实机跑出来的体感不是理论值级别最少盘数可用容量读性能写性能容错典型场景RAID 02全部高高零临时缓存、可重算的数据RAID 12一半中高中坏一块系统盘、小容量关键数据RAID 53(N-1) 块高中坏一块通用数据盘RAID 64(N-2) 块高偏低坏两块大盘、重建窗口长的场景RAID 104一半高高每组坏一块数据库、高并发写入容量算法要记牢RAID5 有效容量 盘数 − 1× 最小盘容量RAID6 盘数 − 2× 最小盘容量RAID10 盘数 ÷ 2 × 最小盘容量。举例四块 8T 盘RAID5 得 24TRAID6 得 16TRAID10 得 16T。同样是 16TRAID6 抗两块盘同时坏RAID10 抗的是不同镜像组各坏一块后者在重建时压力小得多所以数据库类场景我几乎一律推 RAID10。单盘容量超过 4T 的时候我要多说一句RAID5 的重建时间会非常长一块 8T 盘做全量重建机械盘动辄十几个小时这段时间阵列处于降级状态再坏一块就全没了。所以大盘我更倾向 RAID6宁可少一块盘的容量也要把重建期间的风险窗口堵上。2.2 mdadm 建阵的完整命令与参数解释假设机器上有四块空闲盘/dev/sdb、/dev/sdc、/dev/sdd、/dev/sde各 8T准备做 RAID5。第一步一定是确认盘没被占用lsblk看一眼有没有残留的分区表或者旧阵列成员标记。旧阵列残留是最常见的坑mdadm --create会直接拒绝报设备正忙。清理旧标记用这条mdadm --zero-superblock /dev/sdb四块盘都要跑一遍报Couldnt open这类错误可以忽略说明本来就没有超级块。接着建阵mdadm --create /dev/md0 \ --level5 \ --raid-devices4 \ --chunk512 \ --bitmapinternal \ /dev/sdb /dev/sdc /dev/sdd /dev/sde几个参数值得展开说。--chunk512是条带大小单位 KB默认 512K。这个值决定了单次 I/O 落在几块盘上业务以大文件顺序读写为主备份、视频、日志归档chunk 大一点更划算512K 到 1M 都行业务以小文件随机读写为主数据库、大量小文件chunk 小一点128K 甚至 64K让 I/O 能分散到更多盘上。设错了不会崩但性能会打折。--bitmapinternal是写意图位图作用是阵列非正常关机后只重建脏块不用全量同步。不加这个参数一次意外断电就可能触发十几个小时的完整重建。代价是位图会占用阵列末尾一小块空间几百 MB 级别完全值得。建完立刻用cat /proc/mdstat看状态会看到[UUUU]和resync进度。同步期间阵列可用但性能下降如果业务已经在线可以限速echo 200000 /proc/sys/dev/raid/speed_limit_max单位是 KB/s200000 大约是 200MB/s。这个值调太低同步会拖很久调太高会抢占业务 I/O我一般设在磁盘顺序写带宽的 60% 左右。2.3 阵列的持久化、状态监控与坏盘替换建完阵列还有一步绝对不能漏把阵列信息写进配置文件否则重启后阵列名可能变化/dev/md0变成/dev/md127挂载直接失败。mdadm --detail --scan /etc/mdadm.conf这行输出大致是ARRAY /dev/md0 metadata1.2 namehostname:0 UUIDxxxxUUID 是识别关键别手抄一定要用命令生成。写完重启验证一次mdadm --detail /dev/md0能正常输出才算过。日常巡检我主要看两个地方。cat /proc/mdstat一眼看健康度[UUUU]全 U 正常出现_就是有盘掉了或者被标记失败。mdadm --detail /dev/md0看细节重点看State、Active Devices、Failed Devices三个字段。盘真坏了怎么换流程是标记失败、移除、拔盘、插新盘、添加、等重建mdadm --manage /dev/md0 --fail /dev/sdc mdadm --manage /dev/md0 --remove /dev/sdc # 物理更换后 mdadm --manage /dev/md0 --add /dev/sdc新盘加进去会自动开始重建/proc/mdstat里看到recovery进度条就是在干活。这时候千万别手贱去重启或者做别的重 I/O 操作重建期间阵列最脆弱。注意换盘时新盘的容量必须大于等于原盘否则--add会被拒绝。我遇到过一次采购回来的同型号盘实际容量少了几个扇区加不进去白折腾一下午。买盘时核对一下blockdev --getsize64的输出。还有一个容易被忽略的细节软 RAID 的盘如果被fdisk或者分区工具动过超级块会被覆盖阵列就认不出来了。平时操作块设备前先确认这块盘是不是阵列成员lsblk -o NAME,SIZE,TYPE,MOUNTPOINT看清楚再动手。3. LVM 的三层结构与弹性扩容实战3.1 PV、VG、LV 到底谁是谁LVM 的概念第一次看会觉得绕我用一个生活化的类比物理卷 PV 是砖头卷组 VG 是砌好的墙逻辑卷 LV 是从墙上凿出来的房间。砖头可以是一整块盘也可以是 RAID 阵列甚至可以是阵列上的一个分区。墙把所有砖头粘成一个连续的存储池容量相加。房间从池子里划划多大自己定后续墙里还有空间就能继续把房间扩大。三层里最关键的单位是PEPhysical Extent默认 4MiB是 LVM 分配空间的最小粒度。也就是说你划一个 10G 的逻辑卷实际占用的是 2560 个 PE10240 ÷ 4。这意味着逻辑卷大小永远是 4MiB 的整数倍lvcreate -L 1G没问题-L 1000M会被向上取整。PE 大小可以在vgcreate时用-s指定8M、16M、32M 都支持。PE 设大一点卷组能管理的最大容量更大元数据开销更小PE 设小一点碎片更少。一般业务场景默认 4M 就够用除非你要做几十 TB 的超大卷组。3.2 从阵列到可用目录的创建流程接着上一节的 RAID5 阵列继续。第一步把阵列变成 PVpvcreate /dev/md0然后建卷组起个有意义的名字别用默认的vg00后期机器一多根本分不清vgcreate data_vg /dev/md0接着划逻辑卷。这里有个实操建议不要一次性把卷组空间全划完。四块 8T 做 RAID5卷组可用约 24T我只划 20T 给业务用留 4T 在卷组里当缓冲。原因是逻辑卷扩容只能往大了扩、且有空间才能扩一旦划满后续想给某个卷加点空间就得先缩别的卷而缩容比扩容危险十倍。lvcreate -L 20T -n data_lv data_vg格式化。这里的选择会影响后面配额怎么配XFS 扩容方便、不支持缩容适合只增不减的业务目录ext4 扩缩都支持适合容量需要来回调整的场景。mkfs.xfs /dev/data_vg/data_lv挂载到业务目录/etc/fstab里写 UUID 而不是设备路径理由和 RAID 一样设备名可能变mkdir -p /data blkid /dev/data_vg/data_lv # 拿到 UUIDfstab 里加一行UUIDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 03.3 在线扩容最常用的操作也是最容易做错的操作扩容分两种场景。卷组里还有空间直接扩逻辑卷lvextend -L 2T /dev/data_vg/data_lv卷组里没空间了得先加 PV。物理上插一块新盘做成 PV 加进卷组pvcreate /dev/sdf vgextend data_vg /dev/sdf然后照常lvextend。加 PV 这一步是 LVM 最大的价值所在——整个过程业务不用停文件系统不用卸载数据不用迁移。lvextend之后逻辑卷变大了但文件系统还没变大这是新手最容易漏的一步。df -h看容量没变化就是因为这个。补上文件系统扩容# XFS xfs_growfs /data # ext4 resize2fs /dev/data_vg/data_lv新版 LVM 支持一条命令搞定加-r参数自动 resize 文件系统lvextend -L 2T -r /dev/data_vg/data_lv我现在的习惯是一律带-r少一步就少一个忘掉的机会。实测下来这条命令在 XFS 和 ext4 上都很稳。3.4 缩容这件事能不做就不做lvreduce是 LVM 里风险最高的操作做错一步就是文件系统损坏、数据全丢。顺序必须是先卸载、先检查文件系统、先缩文件系统、再缩逻辑卷一步都不能颠倒。XFS 根本不支持缩容硬缩就是数据毁掉。遇到 XFS 要缩只有一条路备份数据、删卷重建、导回数据。ext4 可以缩但流程严格umount /data e2fsck -f /dev/data_vg/data_lv resize2fs /dev/data_vg/data_lv 15T lvreduce -L 15T /dev/data_vg/data_lve2fsck -f是强制检查不能省跳过这一步resize2fs会拒绝执行。而且resize2fs的目标值必须小于当前文件系统大小、大于已用空间lvreduce的目标值必须大于等于缩完的文件系统大小两个值留一点余量别卡得刚刚好。提示我给团队定的规矩是缩容必须两人复核、必须先有完整备份。单个操作失误的代价是整块盘的数据不值得为省几块盘的空间去赌。3.5 快照LVM 一个被低估的能力LVM 还有一个很好用的功能是快照原理是写时复制创建快照的瞬间不复制数据只记录原始卷的块映射之后原卷被修改的块才会复制到快照空间里。所以快照空间不用给太大一般给原卷的 10% 到 20%够撑过一次备份窗口就行。lvcreate -L 200G -s -n data_snap /dev/data_vg/data_lv典型用法是备份前打快照然后把快照挂到临时目录慢慢拷原卷该写就写互不干扰。快照满了会自动失效所以备份任务结束后记得及时删掉lvremove /dev/data_vg/data_snap。4. 磁盘配额的实施细节与验证方法4.1 开配额之前必须先确认的三件事配额不是想开就能开动手前得确认三件事少一件都会白忙活。第一文件系统类型决定命令体系。前文提过XFS 和 ext4 两套命令完全不通用。quota、repquota、edquota是 ext 系列的工具xfs_quota是 XFS 的。在 XFS 上跑repquota会报不支持。第二挂载参数必须带上配额标志。XFS 用uquota,gquotaext4 用usrquota,grpquota。这一步写在/etc/fstab里然后重新挂载生效。已经挂载的目录改参数必须 remountmount -o remount /data就行不用卸载写入会短暂中断几秒。第三配额对 root 用户无效。这是设计如此root 是超级用户任何限制都拦不住。所以配额要针对普通业务账号配置用 root 跑业务进程的机器开配额基本没意义。4.2 XFS 环境下的配额配置全流程假设业务目录是/data要给几个业务账号分别限制空间。第一步改 fstabUUIDxxxxxxxx /data xfs defaults,uquota,gquota 0 0重新挂载并确认mount -o remount /data mount | grep /data输出里能看到uquota,gquota就说明生效了。接着给具体用户设限额xfs_quota -x -c limit -u bsoft500g bhard550g user1 /databsoft是软限制bhard是硬限制。软限制触发后系统只警告不拦截同时启动一个宽限倒计时默认 7 天倒计时内不降到软限以下就升级成硬拦截硬限制是直接拒绝写入超过就报Disk quota exceeded。这两个值之间的间隔我一般留 10%给用户留出清理的缓冲。除了块限制还有 inode 限制对应参数是isoff、ihardxfs_quota -x -c limit -u isoft100000 ihard120000 user1 /datainode 限制容易被忽略但很关键。一个用户可能只占了 1G 空间但里面塞了一百万个小文件把文件系统的 inode 耗尽其他用户一个文件都建不了。这种情况在日志目录、缓存目录上特别常见光限块数拦不住。批量配置的话把限额写进一个文件用-c一条条喂进去更省事xfs_quota -x -c limit -u bsoft500g bhard550g user1 /data xfs_quota -x -c limit -u bsoft200g bhard220g user2 /data4.3 ext4 环境下的配额配置流程ext4 的流程稍微绕一点因为要先quotacheck生成配额文件。fstab 改成UUIDxxxxxxxx /data ext4 defaults,usrquota,grpquota 0 0重新挂载后生成配额数据库quotacheck -cum /data-c创建、-u用户、-m强制文件系统已挂载时必需。然后开启配额quotaon -vug /data给用户设限额用edquota它会打开一个编辑器界面edquota -u user1界面里blocks和inodes各有 soft 和 hard 两列blocks默认单位是 KB要写 500G 就是524288000容易算错。我一般先用edquota -p user1 user2 user3复制一个模板再单独微调比每个都手算省事。批量查看用repquota -aug输出是一张表各用户的已用量、软硬限、宽限状态一目了然。quota -u user1查单个用户。4.4 配额的验证方法与告警设计配完必须验证不能配完就完事。最直接的办法是用被限制的账号往目录里写大文件dd if/dev/zero of/data/test.bin bs1M count600000超过 550G 的时候应该报错。注意要在被限制的用户下执行root 跑不受限。查看当前状态xfs_quota -x -c report -h /data-h是 human readable输出是 G、M 单位比原始字节数好读太多。-u只看用户-g只看组-i看 inode。告警这块配额本身不会主动通知你得自己配。我一般写个定时任务扫报告把超过软限 90% 的账号抓出来发通知xfs_quota -x -c report -h -u /data | awk NR4 $2 ~ /[0-9]/ {print}实际脚本里还要做数值比较和去重这里只给思路。重点是软限是预警位硬限是兜底位靠软限在用户把盘写爆之前把人叫醒别等硬限触发才知道出事。注意宽限期可以改。默认 7 天xfs_quota -x -c timer -u -b 3days /data改成 3 天。设太短会让正常用户频繁踩线设太长等于没设3 到 7 天比较合理。5. 三层技术串联的完整实战与容量规划5.1 从裸盘到可用目录的完整工序把前面的步骤串成一条完整的工序线这是实际交付时我照着跑的清单。第一步清盘查状态。lsblk确认四块目标盘无挂载、无分区、无阵列标记。有旧标记就mdadm --zero-superblock清掉。第二步建 RAID5 阵列。mdadm --create /dev/md0 --level5 --raid-devices4 --chunk512 --bitmapinternal /dev/sd{b,c,d,e}然后cat /proc/mdstat确认同步开始。第三步持久化阵列配置。mdadm --detail --scan /etc/mdadm.conf重启后阵列名必须还能对上/dev/md0。第四步创建 PV 和 VG。pvcreate /dev/md0、vgcreate data_vg /dev/md0pvs、vgs确认结果。第五步划逻辑卷。卷组 24T 只划 20Tlvcreate -L 20T -n data_lv data_vglvs确认。第六步格式化并挂载。mkfs.xfs /dev/data_vg/data_lvblkid拿 UUID写 fstabmount -a验证。第七步开配额。fstab 加uquota,gquotamount -o remount /dataxfs_quota -x -c limit ...逐个配置。第八步验证。用测试账号跑 dd 打满确认硬限生效xfs_quota -x -c report -h /data看报告正常reboot一次确认所有配置能自动恢复。第八步的reboot验证千万别省。我吃过一次亏fstab 里 UUID 抄错一位当场没问题第二天机房断电重启机器直接卡在紧急模式起不来一堆业务停了两小时。5.2 容量规划的计算过程与余量设置规划容量不是拍脑袋得按公式算。以四块 8T 盘、RAID5、XFS、配额为例RAID 层可用容量 4 − 1× 8T 24T。文件系统元数据和日志占用大约 2% 到 5%实际可用约 22.8T 到 23.5T。LVM 划 20T卷组里留 4T 缓冲。20T 里给配额分配假设五个业务账号两个各 500G、两个各 2T、一个 10T合计 15T剩下 5T 是公共空间和其他用途。这个分配里有两处余量。卷组余量 4T用于后续哪个账号超了能临时扩容不用重新规划整块盘。文件系统余量 5T保证硬限加起来不会真的把盘占满——如果五个账号的硬限加起来正好等于 20T那五个账号同时写满的时候文件系统会最先崩配额还没来得及拦。我给的经验值是所有硬限之和不超过文件系统容量的 85%。还有一块经常被算漏RAID 重建时的性能衰减。RAID5 降级状态下读性能基本不变但写性能会掉到 30% 左右因为每一笔写都要重算校验码。所以业务高峰期的磁盘使用率我一般控制在 70% 以内留 30% 给重建和突发。5.3 一块盘坏掉之后的完整处理流程这是整套方案的实战检验。假设某天巡检发现/proc/mdstat显示[UUU_]/dev/sde掉了。先看细节确认是盘挂了还是被误标记mdadm --detail /dev/md0 dmesg | grep -i sdedmesg里如果有大量 I/O 错误、超时、复位信息基本就是物理故障。确认后按流程换盘。换的过程中业务不受影响阵列降级但照常读写只是性能下降。新盘插上后lsblk确认识别到mdadm --manage /dev/md0 --add /dev/sde加回去看着/proc/mdstat的 recovery 进度跑完。8T 盘大概要几小时到十几小时视磁盘速度而定。这段时间里我建议把非关键的大 I/O 任务批量备份、日志归档推迟把重建带宽让出来。重建完成后mdadm --detail /dev/md0的State应该回到cleanActive Devices : 4Failed Devices : 0。如果想主动扫一遍全盘有没有潜在坏块echo check /sys/block/md0/md/sync_action这个动作只读不改数据比 repair 安全适合作为例行巡检。5.4 扩容的两种路径与执行时机扩容路径一卷组有余量。直接lvextend -L 2T -r /dev/data_vg/data_lv秒级完成业务无感。扩容路径二卷组没余量。这一步要动硬件流程是插新盘、pvcreate、vgextend、lvextend -r。其中vgextend会做一次元数据写入但也不影响正在读写的逻辑卷。两种路径都建议放在业务低峰做。虽然理论上在线但xfs_growfs在大文件系统上会花几分钟期间元数据锁有一定影响。我的习惯是凌晨两点窗口执行扩完立刻df -h和xfs_quota -x -c report -h /data对一遍数。6. 常见问题与排查技巧实录6.1 高频问题速查表下面这张表是我这几年攒下来的基本都是真出过的问题现象大概率原因处理办法mdadm --create报设备忙盘上有旧阵列标记或残留分区mdadm --zero-superblock清标记wipefs -a清分区表重启后阵列变成 md127没写/etc/mdadm.confmdadm --detail --scan /etc/mdadm.confdf -h扩容后容量没变只扩了 LV没扩文件系统补xfs_growfs或resize2fs或直接lvextend -r用户报磁盘空间不足但df有空间触发了配额硬限或 inode 耗尽xfs_quota -x -c report -h -i查 inodedf -i对照repquota报不支持文件系统是 XFS用了 ext 工具改用xfs_quota配额配了但没生效fstab 缺配额参数或没 remountmount | grep data确认参数mount -o remountlvreduce后目录打不开缩容顺序错了文件系统被破坏只能从备份恢复这是不可逆的阵列重建极慢建阵时没加 bitmap在做全量同步下次建阵加--bitmapinternal本次只能等vgextend报 PE 大小不一致新 PV 的 PE 和卷组不同卷组 PE 建好后不能改只能重建卷组6.2 几条用血换来的避坑经验第一条别信这块盘不会坏。我经手的机器里硬盘故障是最高频的硬件问题比内存、电源高一个数量级。做阵列的时候多买一块同型号的冷备盘放机柜里坏盘直接换比等采购流程快三五天。冷备盘不用插上去闲置状态就行插上去反而增加运行时间。第二条fstab 里别写设备名。/dev/sdb这种名字会随插拔顺序变化/dev/md0会随组装顺序变化/dev/data_vg/data_lv相对稳一点但也不绝对。大写特写一律用 UUID。blkid拿一遍抄进去mount -a验证通过再重启验证一遍。第三条配额一定要限 inode。我见过一个案例某台机器的/var/log分区只用了 8% 的空间但 inode 用了 99%因为里面堆了几百万个小日志文件结果所有服务都写不进日志。块限制拦不住这种情况必须把 inode 硬限一起配上。巡检的时候df -i和df -h要一起看。第四条软限和硬限要留间隔硬限总和要留余量。软硬限贴在一起用户踩线就直接被拒绝没有任何缓冲清理时间体验极差。硬限总和等于盘容量配额就形同虚设因为盘先满了。这两个数值得一起算。第五条阵列降级不等于安全。降级状态下数据还在但已经失去冗余了。这时候如果再来一次意外断电导致阵列不同步或者另一块盘也出问题数据就可能救不回来。所以发现降级要立刻安排换盘别抱着还能用先用着的心态拖我见过拖了两周然后第二块盘也坏了的最后靠备份恢复损失了两天的增量数据。第六条备份策略和 RAID 是两回事。RAID 防的是硬件故障防不了误删除、防不了文件系统损坏、防不了人为误操作。rm -rf下去RAID 会忠实地把每块盘上对应的数据都删掉。所以配额、RAID、LVM 这三样配好之后备份还得单独做这是另一个话题但别把它们混为一谈。第七条配置文档要跟着改。每次扩卷、加盘、改配额都要同步更新文档。我接手过一台别人留下的机器卷组里有一块盘的 PV 是在哪台设备上都没记录pvs显示/dev/sdf但实体机上找不到对应位置最后是拆开机箱一块块看序列号对出来的。文档这件事平时不起眼出问题时能救命。6.3 一套可复用的巡检脚本思路日常巡检我不用逐个命令敲写个脚本一次出结果。核心就几个检查点cat /proc/mdstat看阵列状态里有没有_mdadm --detail看Failed Devices是不是 0pvs、vgs、lvs看三层有没有异常标记df -h和df -i一起看使用率xfs_quota -x -c report -h看有没有账号接近或超过软限。脚本输出我要求做到一眼判生死全部正常就打印一行 OK有异常就把异常项和对应命令打出来。定时任务每小时跑一次异常就发告警。这套东西搭起来大概半天但能把磁盘悄无声息地满掉这类事故拦在发生之前。实际配置的时候我最大的体会是这三样技术单独学都不难难的是搞清楚它们之间的边界和顺序。RAID 建好才能给 LVMLVM 挂好才能开配额顺序错了就得推倒重来。另外就是老老实实做重启验证配置写完不重启就当没写完这个习惯帮我躲过好几次深夜被叫起来处理开机故障的场面。
RELATED

相关推荐

大模型性能对比方法论:如何科学评估LLM推理能力

大模型性能对比方法论:如何科学评估LLM推理能力

我无法根据当前输入生成符合要求的博文。原因如下:输入中缺少项目正文、关键词和摘要描述三项必要字段,仅提供了项目标题“Reflection Beam 与 Mistral Large 4 追平 GLM-5.2”及空置的热搜词与网络搜索内容区块(内容为空)&#x…

📅 2026/10/26 3:59:17
双指针法高效解决LeetCode接雨水问题

双指针法高效解决LeetCode接雨水问题

1. 问题背景与核心挑战这道来自LeetCode热门100题榜单的"接雨水"问题,是算法面试中的经典题型。题目描述看似简单:给定n个非负整数表示的高度图,计算按此排列的柱子能接多少雨水。但实际解决时需要处理多种边界情况,对空…

📅 2026/10/26 3:59:17
Cocos Creator 3D渲染管线与Shader实战:从成像链路到卡通着色排查

Cocos Creator 3D渲染管线与Shader实战:从成像链路到卡通着色排查

美术同学把模型丢进场景,编辑器里预览一切正常,打包到真机上却成了一块死黑的方块;或者角色明明站在主光下,轮廓边缘却糊着一圈脏兮兮的灰边。这类问题十有八九不是模型的问题,而是 Cocos Creator 3D 的成像链路和 Sha…

📅 2026/10/26 3:59:17
MORE NEWS

更多资讯

📰

AI芯片软硬件协同设计:从内存墙到指令集的全栈实现

1. 这不是在造芯片,而是在重新定义“思考”的物理边界“AI芯片的软硬件设计”这八个字,听起来像一句技术口号,但在我过去十年参与过七款不同定位AI加速器的流片与落地项目里,它其实是一场持续不断的拉锯战——一边是算法研究员不断…

📰

UDP协议深度解析:从协议头设计到实战选型与避坑指南

UDP 这个词,做网络的人几乎天天挂在嘴边,但真要把它讲透、用对,其实比想象中难。我见过太多项目,一上来就无脑选 UDP,理由是"快",结果丢包丢到业务方怀疑人生;也见过另一批人&#xf…

📰

前端三件套的隐形合约:HTML、CSS与JavaScript的协作之道

1. 前端三件套的「隐形合约」:当结构、表现与行为开始互相背叛在Web开发领域,HTML、CSS和JavaScript被称为"前端三件套",它们各自承担着不同的职责:HTML负责结构,CSS负责表现,JavaScript负责行为…

📰

VSCode处理超大目录的性能优化与问题解决

1. VSCode处理超大目录时的性能陷阱解析当你在VSCode中打开一个包含数万文件的超大目录时,编辑器会立即启动后台索引进程。这个看似简单的操作背后,实际上触发了三个关键机制:文件系统遍历、内容索引构建和元数据缓存。我曾在处理一个包含12万…

📰

VSCode处理超大目录的性能优化与解决方案

1. VSCode处理超大目录时的性能陷阱与解决方案 当你在VSCode中打开一个包含数万文件的超大目录时,编辑器会立即启动后台索引进程。这个看似简单的操作背后,实际上触发了三个高负载任务:递归文件遍历、全文检索索引构建、以及文件系统元数据缓…

📰

Android平台Modbus主站实现:串口通信与协议解析实战

简介:这份资源面向需要在 Android 平台上实现 Modbus 通信的开发者,尤其适合从事工业自动化设备对接、希望用手机或平板控制 PLC、温控器、变频器等硬件的工程师。项目以 Java 为主,将开源 Modbus 库 jamod 适配到 Android 环境,覆…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬