Buộc zpool sử dụng / dev / đĩa / by-id trong Ubuntu Xenial

15

Tôi đang dùng thử OpenZFS kèm theo trên Ubuntu 16.04 Xenial.

Khi tạo nhóm, tôi luôn tham chiếu các ổ đĩa theo sê-ri của chúng trong /dev/disk/by-id/(hoặc /dev/disk/gpttrên FreeBSD) để có khả năng phục hồi. Các ổ đĩa không phải lúc nào cũng theo thứ tự /devkhi máy khởi động lại và nếu bạn có các ổ đĩa khác trong máy thì nhóm có thể không lắp đúng.

Ví dụ: chạy zpool statustrên hộp 14.04 tôi nhận được điều này:

NAME                                  STATE     READ WRITE CKSUM
tank                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0

Nhưng khi tôi tạo một nhóm mới vào ngày 16.04 với điều này (viết tắt):

zpool create pool raidz \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..]

Tôi nhận được điều này với zpool status:

NAME        STATE     READ WRITE CKSUM
tank        ONLINE       0     0     0
  raidz1-0  ONLINE       0     0     0
    sdf     ONLINE       0     0     0
    sde     ONLINE       0     0     0
    sdd     ONLINE       0     0     0
    sda     ONLINE       0     0     0

Có vẻ như zpool đã theo các liên kết tượng trưng, ​​thay vì tham khảo chúng.

Có cách nào để buộc zpool vào ngày 16.04 tôn trọng các tham chiếu ổ đĩa của tôi khi tạo một nhóm không? Hoặc cách khác, là những hiểu lầm của tôi về những gì nó làm ở đây bị đặt sai chỗ?

Cập nhật: Giải pháp thay thế

Tôi tìm thấy một chủ đề cho zfsonlinux trên Github gợi ý cách giải quyết. Tạo zpool của bạn với /dev/sdXcác thiết bị trước, sau đó làm điều này:

$ sudo zpool export tank
$ sudo zpool import -d /dev/disk/by-id -aN

Tôi vẫn muốn có thể làm điều này với ban đầu zpool createmặc dù nếu có thể.

ubuntu  zfs 
— Schenenen
nguồn
Không quan trọng bạn tạo ra chúng như thế nào. Nếu nó trở lại / dev / sd? Tên thiết bị, zfs exportvà zfs import -dsẽ vẫn hoạt động. BTW, trừ khi bạn thực sự cần mỗi byte không gian, hãy sử dụng hai cặp được nhân đôi thay vì raidz. Hiệu suất của raidz tốt hơn so với raid-5 nhưng vẫn kém hơn nhiều so với các cặp nhân đôi raid-10 hoặc zfs. Việc mở rộng một nhóm được tạo thành từ các cặp được nhân đôi cũng dễ dàng hơn, chỉ cần thêm hai đĩa cùng một lúc ... với raidz, bạn phải thay thế mỗi ổ đĩa bằng các ổ đĩa lớn hơn và chỉ khi bạn thay thế tất cả chúng thì bạn mới thay thế hồ bơi có nhiều không gian có sẵn.
— cas
Tôi vẫn còn một số hồ bơi đột kích, và rất tiếc đã làm chúng. Khi tôi có thể đủ khả năng mua đĩa thay thế, tôi sẽ tạo các nhóm mới với các cặp được nhân đôi và sử dụng zfs sendđể sao chép dữ liệu của mình sang nhóm mới. Trên thực tế, raid-z là ổn đối với hộp huyền thoại của tôi khi hiệu suất không quan trọng trừ khi tôi đang chạy 6 hoặc 8 công việc chuyển mã cùng một lúc. Thay đổi thành các cặp được nhân đôi sẽ rất đáng chú ý trên hồ bơi nơi /home thư mục của tôi sống.
— cas
2
Sự phản chiếu của ZIL là để bạn có thể thoát khỏi việc sử dụng ổ SSD giá rẻ thông thường thay vì những chiếc đắt tiền có tụ điện lớn để bảo vệ chống mất điện. IMO, phản chiếu ZIL không phải là tùy chọn, cho dù bạn có loại SSD nào - nếu ZIL của bạn chết, bạn sẽ mất tất cả dữ liệu chưa được ghi trong đó và có khả năng làm hỏng nhóm của bạn. Đối với L2ARC, tôi đặc biệt nói KHÔNG phản chiếu chúng ... phản chiếu bộ đệm L2ARC là lãng phí thời gian, tiền bạc và không gian SSD tốt (và sẽ không làm gì để tránh mất bộ nhớ cache - bạn lấy ý tưởng đó từ đâu?)
— cas
1
:) BTW, bộ não của tôi không hoạt động đúng khi tôi giải thích lý do phản chiếu ZIL. Đó không phải là để bảo vệ chống mất điện, điều đó hoàn toàn vô nghĩa và tôi không bao giờ nên nói điều đó. Đó là để bảo vệ chống lại sự thất bại của ổ ZIL. tức là gương đột kích-1 cho ZIL. Nhìn chung, hai ổ SSD có giá hợp lý tốt hơn một ổ cực kỳ đắt tiền (trừ khi ổ SSD đắt hơn có giao diện nhanh hơn nhiều, như PCI-e vs SATA). và một UPS là thiết yếu ... bảo vệ giá rẻ chống mất điện.
— cas
1
@cas Mirrored ZIL bảo vệ chống lại lỗi thiết bị SLOG cùng lúc với việc tắt đột ngột. Trong các hoạt động bình thường, ZIL chỉ ghi và ghi vào bộ lưu trữ liên tục là từ RAM (ARC). Nếu hệ thống tắt đột ngột, nhật ký ý định (ZIL, SLOG) được sử dụng để hoàn thành việc ghi bị gián đoạn. Chỉ khi tắt đột ngột trùng với sự cố của thiết bị SLOG, bạn mới cần SLOG chuyển hướng để khôi phục việc ghi bị gián đoạn. Đối với hầu hết các khối lượng công việc không phải máy chủ (và nhiều máy chủ), SLOG là quá mức cần thiết, vì ZIL thực sự chỉ phát huy tác dụng với việc ghi đồng bộ.
— một CVn

Câu trả lời:

1

Một thời gian, zpool import -d /dev/disk/by-idkhông hoạt động.

Tôi đã nhận thấy điều này trên nhiều môi trường. Tôi có một tập lệnh nhập, ngoài việc thực hiện một số logic ma thuật và hiển thị các thiết bị ZFS được gắn vật lý, về cơ bản cũng thực hiện điều này:

zpool import -d /dev/disk/by-id POOL
zpool export POOL
zpool import POOL

Lần thứ hai, ngay cả khi không có công -dtắc, nhập bằng ID thiết bị ngay cả khi lần đầu tiên không có lệnh rõ ràng.

Có thể đây chỉ là do lỗi ZFS trong khoảng thời gian vài tuần hoặc tháng (một hoặc hai năm trước) và điều này không còn cần thiết nữa. Tôi cho rằng lẽ ra tôi nên nộp một báo cáo lỗi, nhưng việc này không quan trọng lắm.

— Jim
nguồn
1

Tôi biết chủ đề này là loại cũ, nhưng có một câu trả lời. Bạn cần cập nhật tệp bộ nhớ cache sau khi nhập. Ví dụ này hiển thị vị trí mặc định cho tệp bộ đệm.

$> sudo zpool export POOL
$> sudo zpool import -d /dev/disk/by-id POOL
$> sudo zpool import -c /etc/zfs/zpool.cache
$> sudo zpool status POOL
NAME                                  STATE     READ WRITE CKSUM
POOL                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0
— Steve O
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.