- 主题:zfs扩容的正确方法？
一般不是按设备名来算的吧
是按UUID
【 在 hyoga 的大作中提到: 】
: 一直有个疑问，你现在来讲，新的pool里面应该是sdc，sdd两块盘（18T）
: 那么如果把原来的sda，sdb拔掉了（4TB），那么重启之后，sdc，sdd不会变成
: sda，sdb吗？这样会有问题吗？
: ...................
--
FROM 139.227.19.*
你这句话和我说的有什么关系吗？？
【 在 cppbuilder 的大作中提到: 】
: 标 题: Re: zfs扩容的正确方法？
: 发信站: 水木社区 (Wed Nov 29 18:08:59 2023), 站内
:
: zfs一般不传分区
:
: 【 在 JulyClyde 的大作中提到: 】
: : 一般不是按设备名来算的吧
: : 是按UUID
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 1.202.8.*]
--
FROM 139.227.19.*
UUID不是文件系统元信息里的内容吗？
和分区有关系？？
【 在 cppbuilder 的大作中提到: 】
: 所以zfs不能用UUID啊，UUID不都是分区之后才有的吗
--
修改:JulyClyde FROM 139.227.19.*
FROM 139.227.19.*
ZFS的“pool成员”有UUID吗？
不懂ZFS；不过LVM physical volume、soft RAID volume我记得都是有的吧
【 在 cppbuilder 的大作中提到: 】
: 主题不是说了用在zfs里，还没分区也没有文件系统，哪来的“文件系统元信息”呢
--
FROM 139.227.19.*
blkid运行一下看看？
【 在 DreamDreams 的大作中提到: 】
: 分区表这样：
: # fdisk -l /dev/sde
: Disk /dev/sde: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
: Disk model: WDC WD40PURX-78A
: 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: C3BA9AEB-609D-344A-86DE-F7F4C8D01BAA
: Device Start End Sectors Size Type
: /dev/sde1 2048 7814019071 7814017024 3.6T Solaris /usr & Apple ZFS
: /dev/sde9 7814019072 7814035455 16384 8M Solaris reserved 1
--
FROM 139.227.19.*
有些“最佳实践”提倡不要在整盘上直接保存数据，一定要分个区
这样可以避免别人误以为这盘还没启用而手贱替你分上区，导致损毁
ZFS应该是遵守了这种实践的
【 在 cppbuilder 的大作中提到: 】
: 按手册的说法，zfs建议使用整个磁盘，而不是让用户维护分区之后传分区进去。而且pool总应该使用/dev/disk/by-id作为标识，不用sda这种。这两条放在一起，得到的结论是zfs不应该接触UUID，也不应该接触sda。
: zfs接管磁盘之后确实会分区，当然也就会有UUID，但这是接管之后的事。一般是一个part1一个part9，这是为了确保blocks取整，有时候磁盘空间很巧就不会出现这个part9。
: 下面是一个例子，没用by-id而用sda写法，之后就乱了。其他一些帖子里也有类似情况。我并没证实过，我不挑战未定义行为。
: ...................
--
FROM 139.227.19.*
【 在 DreamDreams 的大作中提到: 】
: # zpool status
: pool: nas
: state: DEGRADED
: status: One or more devices are faulted in response to persistent errors.
: Sufficient replicas exist for the pool to continue functioning in a
: degraded state.
: action: Replace the faulted device, or use 'zpool clear' to mark the device
: repaired.
: scan: resilvered 1.21T in 04:04:43 with 0 errors on Sun May 29 14:37:53
: 2022
: config:
: NAME STATE READ WRITE CKSUM
: nas DEGRADED 0 0 0
: raidz2-0 DEGRADED 0 0 0
: sdb FAULTED 0 15 0 too many errors
: sda ONLINE 0 0 0
: sdc ONLINE 0 0 0
: sdd ONLINE 0 0 0
: sde ONLINE 0 4 0
: 5672573410470460000 FAULTED 0 0 0 was /dev/sde1
: errors: No known data errors
: blkid你感兴趣的部分
: /dev/sda1: LABEL="nas" UUID="7731801031414523961" UUID_SUB="1262637789466433
: 8777" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="zfs-16e9cd2648b08d56"
: PARTUUID="685b3130-5f91-414b-9a16-ceb69dc1826a"
那就是zfs_member这个fstype也是存在可以被libblkid识别的UUID的
: /dev/sda9: PARTUUID="42da4b95-5c9b-1646-82c1-89e93cc3459a"
: /dev/sdb1: LABEL="nas" UUID="7731801031414523961" UUID_SUB="1570478843320104
: 2939" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="zfs-de93a417de217a27"
: PARTUUID="7cbf2b83-3a0e-2d49-80ed-7a930f2dca0c"
: /dev/sdb9: PARTUUID="098916f7-d9fb-1d4a-bcb5-b26b18e8e7f5"
: /dev/sdc1: LABEL="nas" UUID="7731801031414523961" UUID_SUB="1766795165654954
: 2840" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="zfs-0d233ad4a0889c04"
: PARTUUID="1b0132b1-b662-b142-96ea-4be3dadf79a5"
: /dev/sdc9: PARTUUID="0b62c8b6-226d-2947-9149-dc5d2af449b5"
: /dev/sdd1: LABEL="nas" UUID="7731801031414523961" UUID_SUB="7743753519071653
: 170" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="zfs-523b1dc62ec7a206"
: PARTUUID="00d6c1f6-8e46-8047-8d84-fe206a601734"
: /dev/sdd9: PARTUUID="1de67224-45ac-7249-82cf-e8826098b857"
: /dev/sde1: LABEL="nas" UUID="7731801031414523961" UUID_SUB="1441643345913500
: 5643" BLOCK_SIZE="4096" TYPE="zfs_member" PARTLABEL="zfs-b8b262fd77e6abc3"
: PARTUUID="156f3779-797f-be47-86a2-c479ce130b97"
--
FROM 139.227.19.*