Tóm tắt vấn đề:
Tôi đã tìm hiểu về JBOD trong nhiều năm nhưng cuối cùng cũng cần một 'trung tâm dữ liệu vi mô' thực sự. Tôi đã mua 3 ổ đĩa cho hộp truyền phát centos8 của mình trong vài tháng, nhưng tôi nghe nói rằng việc mua cùng một ổ đĩa từ cùng một số lô có thể vừa tốt vừa xấu. Chúng đều là ổ WD Red TB: WD80EFAX*. Nhưng quỷ quyệt, cái đầu tiên là wd80efax-68LHPN0, Mfg chứa đầy khí heli. Vào tháng 7 năm 2019, hai cái sau được bán là WD80EFAX-68KNBN0 chứa đầy khí heli từ năm 2020. Các trường hợp trông khác nhau, nhưng tôi vẫn tiếp tục vì chúng giống nhau phiên bản chính và hầu hết các nhà bán lẻ thậm chí không liệt kê hoặc phân biệt phần còn lại. Thật không may, những nỗ lực đầu tiên của tôi không suôn sẻ, và chắc chắn rằng đó là nỗ lực duy nhất chứa đầy khí heli dường như không tham gia lại mảng mdadm/RAID.
Thông tin chi tiết và bất kỳ nghiên cứu nào: Hiện tại tôi đang sử dụng cái này làm bộ lưu trữ/NAS, không phải máy chủ web. Trên thực tế, tôi không cần nó khả dụng khi khởi động, có thể không muốn khả năng đó tùy thuộc vào cách máy tính được sử dụng vào ngày hôm đó. Tôi có thể cần phải ra ngoài một chút và tôi không có đối tác đáng tin cậy nào ở gần ngày hôm đó, vì vậy tôi cần hiểu và điều chỉnh cấu hình bất cứ lúc nào. Không phải tôi giỏi đến thế, nhưng sẽ thật tệ nếu mảng không đáng tin cậy này ghi ở tốc độ 1/10 vào thời điểm tồi tệ nhất có thể. Dù sao thì,
Tôi đã tạo mảng của mình như vậy:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
bỏ qua việc thiết lập một phân vùng, vì nghe nói điều này là không cần thiết nếu bạn chỉ muốn một tập liền kề mà bạn sẽ không bao giờ thay đổi và thậm chí có thể khiến mọi thứ trở nên khó khăn hơn. Nó dường như hoạt động tốt ngoại trừ một ổ đĩa không tự liên kết với mảng.
cryptsetup luksFormat /dev/md0, để định dạng mảng đột kích của tôi cho một số loại luks
đã mở, thiết lập hệ thống tập tin. Để linh hoạt trong tương lai, tôi đã chọn LVM
pvcreate/dev/mapper/tên thiết bị
xác minh tạo thành công với: pv (có vẻ tốt)
tạo nhóm âm lượng với lưu trữ vgcreate/dev/mapper/devname, và sau đó đặt lvm trên đó. lvcreate -n myLVMname -L 16T storageName
Trên thực tế đã phải sử dụng 14,55T vì có vẻ như một số không gian được dành riêng hoặc có sự tính toán sai về không gian ở kích thước này khi sự khác biệt giữa TB và TiB tăng lên. Dù sao, tôi có thể thấy tất cả đều tốt với:
pv, vgs và lv.
Thời gian làm FS:
mkfs.ext4 /dev/mapper/devname, và tại thời điểm này lsblk hiển thị tất cả các ổ đĩa của tôi như vậy:
sde // đĩa
ââmd0 // cuộc đột kích của chúng tôi
ââcrypt-storage //enc container
ââstorage-https //mountable vol
với bản in giống hệt cho /dev/sdd và /dev/sdc. Nó được mở và gắn kết ngay bây giờ.
đã mở /etc/fstab, có thể thấy `/dev/mapper/devicename được gắn tại /run/media/username/moutpoint.
Nếu tôi muốn nó gắn kết khi khởi động, tại thời điểm này, tôi sẽ cần thực hiện thêm một số thao tác. Nhưng tôi không muốn, tôi muốn tự gắn nó khi cần thiết. Để có biện pháp tốt, hãy tạo mdadm.conf với mdadm --verbose --detail --scan > /etc/mdadm.conf, mặc dù nó có thể xây dựng lại mảng với dữ liệu từ siêu khối phải không?
Nếu tôi muốn gắn kết khi khởi động, tôi cần cập nhật /etc/crypttab bằng UUID của thiết bị đột kích của mình /dev/md0, cập nhật initramfs của tôi, với bản nháp -f -vvà cập nhật grub với grub2-mkconfig -o /etc/grub2-efi.cfghoặc đối với centos, cấu hình thường được liên kết với /boot/efi/EFI/centos/grub.cfg. Tuy nhiên, tôi đã không cập nhật grub hoặc crypttab vì tôi không nghĩ rằng mình cần/không muốn nếu không cần thiết, tất cả điều này sẽ xảy ra sau khi khởi động đúng cách.
Tôi đã khởi động lại, nhưng lsblk hiển thị vấn đề: (cắt bớt)
`
sdc
ââsdc1
sđd
ââmd0
sde
ââmd0
`
có vẻ như wd80efax-68LHPN0 chứa đầy heli (/ dev/sdc ở đây) không được đưa vào mảng md0 (ngay cả trước lvm trên luks). Nó nghĩ rằng có một phân vùng 'sdc1'. Đây có phải là do sự cố với cách tôi định cấu hình, phần cứng khác hoặc phần sụn khác không? như đã đề cập trước đây, các nhà bán lẻ thường không cung cấp các ký tự cuối cùng của số kiểu máy, vì vậy tôi có hy vọng tất cả WD80EFAX* sẽ hoạt động cùng nhau không? WD dường như không cung cấp phần sụn cho ổ cứng đơn giản ?? https://community.wd.com/t/firmware-wdc-wd80efzx-68uw8n0/218166/2
Là duckduckgo không tìm thấy nó? (đôi khi nó có thể đánh bại google, chắc chắn là chức năng tìm kiếm của WD)
Tôi đã từng tháo rời một số bảng logic trước đây và luôn muốn gây rối với phần sụn, nhưng không phải trong khi tất cả dữ liệu của tôi vừa được di chuyển (đây là bản sao lưu) vào ngăn xếp được mã hóa này, với một số ổ đĩa trước đó đã bị xóa để sử dụng làm ổ đĩa lớn. Thật xấu hổ vì tôi không có bản sao lưu khác, nó vẫn có thể đọc được, nhưng tôi cũng bị hạn chế về tài nguyên và đang cố gắng hợp nhất hơn 5 ổ JBOD này để tôi có thể sắp xếp lượng dữ liệu ngày càng tăng không ngừng này trong đời mình để có thời gian cho nhiều hoạt động tình nguyện/công việc kinh doanh hơn nỗ lực. Ít nhất bây giờ tôi đã học được bước đáng sợ là khôi phục/làm việc trên một mảng đột kích được mã hóa, ở một mức độ nào đó.
Khi thích hợp, hãy mô tả những gì bạn đã thử:
tôi có thể ngăn chặn md0 thiết bị (mdadm --stop /dev/md0, thêm nó:
mdadm --add /dev/md0 /dev/sdc (và sdc1 mặc dù sẽ không thêm phân vùng)
(không thêm lại và sợ sử dụng --assume-sạch (nghe nói nếu không phải dân chuyên nghiệp thì đừng dùng)), nhưng sau đó nó cần 2 ngày re-sync mỗi khi khởi động máy, hao mòn không cần thiết chưa kể thời gian chết. Không tốt cho sản xuất hoặc thực sự bất cứ điều gì.sử dụng mdadm --detail /dev/md0 trạng thái cho thấy nó thực sự bị 'xuống cấp', một thiết bị bị 'gỡ bỏ'. Tôi vẫn có thể mở khóa hai ổ đĩa, gắn kết và đọc nó, ghi có vẻ chậm hơn, nhưng dữ liệu của tôi hiện đang bị treo trên vách đá được mã hóa nếu 2 ổ đĩa còn lại này bị lỗi.
Vì vậy, tôi (lại) thêm cùng một ổ đĩa, để nó đồng bộ hóa, sử dụng đồng hồ trên /proc/mdstat. Tôi đảm bảo rằng tôi đã cập nhật initramfs của mình (mặc dù tôi không cần phải làm vậy?) với bản nháp -f -v, sao chép tất cả thông tin ổ đĩa với blkid chỉ trong trường hợp, khởi động lại. Cùng một vấn đề, /dev/sdc (ổ đĩa helium số kiểu cũ hơn nhưng giống nhau) không phải là một phần của md0.
sử dụng mdadm -v --assemble /dev/md0 --uuid=<thông tin từ /etc/mdadm.conf> nó quét và tò mò nói:
không tìm thấy siêu khối RAID nào trên/dev/sdc hoặc /dev/sdc1, phép thuật mong đợi a92something, có 00000000*,
đối với /dev/sdc1 ("phân vùng" (không nên ở đó), không phải thiết bị), ma thuật mong đợi a92somethingRAIDUUIDthing, có 00000401.
Các ổ đĩa tốt:
mdadm: /dev/sdf được xác định là thành viên của /dev/md0, vị trí <1 hoặc 2>
Cho nên Tôi nghi ngờ vấn đề là ở đây nếu đó là điều tôi đã làm trong cấu hình. Một số bài đăng ở nơi khác đề xuất điều gì đó có thể đang xóa sạch siêu khối, nhưng tôi không biết bất cứ điều gì trong quá trình tắt máy hoặc khởi động lại của mình sẽ làm điều này, nhưng tôi đã không thực hiện kiểm tra người giúp việc xấu xa trong một thời gian, và tôi cũng không muốn cần thiết để làm một cái, và tôi sẽ sử dụng các công cụ và ghi chú trên máy này để làm như vậy. Có lẽ không phải vậy, nhưng nó có thể.
Tôi vẫn có thể cập nhật grub hoặc /etc/crypttab của mình, nhưng có vẻ như tôi không cần phải làm điều này, về cơ bản, đây là một ổ đĩa RAID khổng lồ mà đôi khi tôi cần kết nối với phần còn lại của hệ thống. Có vẻ như có điều gì đó rắc rối khác đang xảy ra liên quan đến siêu khối, phần cứng hoặc phần sụn, đặc biệt là khi có sự khác biệt rõ ràng trên vỏ và bo mạch giữa ổ đĩa helium và hai ổ đĩa khác hoạt động tốt (không may).
bất kỳ ý tưởng?
Thích:
- kiểm tra tốt hơn các chương trình khởi động của tôi? (có vẻ khó xảy ra, nhưng)
- một số cách để flash chương trình cơ sở mới vào các ổ đĩa? Mặc dù tôi muốn OEM hoặc các phương thức mở nếu có thể. Họ đọc các khối có cùng kích thước, v.v. đúng như vậy không nên dù sao cũng quan trọng?
- mua thêm ổ đĩa cho đến khi tôi tìm thấy một trận đấu hoặc đi lùng sục ebay và đoán ?? nghe có vẻ tốn kém và lãng phí
- Tôi có thể thử đoán tại cửa hàng máy tính địa phương, nhưng ai đó không có một trong những thứ này thì phải làm sao?
- tôi sẽ làm gì với ổ đĩa helium sau nếu nó vô dụng như một ổ đĩa dự phòng cho mảng?
- đăng trên SuperUser hoặc một nơi nào khác? Nơi này có vẻ tuyệt vời
không quan tâm đến:
- khởi động các cửa sổ (nó không hoạt động tốt với Linux và ẩn hoàn toàn trình điều khiển chưa được ký của tôi cho các dự án có quyền ghi đè để truy cập vào quyền ghi đè được chôn trong bios, bởi vì f*ck M$)
- mặc dù tôi có một hộp 8.1 cho M$ Teams cần khóa khôi phục và một số giá đỡ ổ cứng nếu tôi cần
- một số tiện ích ổ cứng nguồn đóng sơ sài ngay cả khi ASM được mã hóa thủ công bởi chính Chúa Giêsu Kitô
- loại bỏ cuộc đột kích (Tôi biết có những câu chuyện kinh dị, đặc biệt là thêm mã hóa, được cho là không cần thiết cho hệ thống tĩnh mà phụ thuộc vào env mối đe dọa của bạn, nhưng cũng có rất nhiều công ty đặt cược hoạt động kinh doanh của họ vào chúng). Tôi muốn học hỏi từ điều này và xây dựng thêm một số điều nữa, bây giờ sự cố này đã buộc tôi phải tìm hiểu rất nhiều về chúng.
Dường như có đủ công cụ và kiến thức mở để tìm ra điều này, nó không phải là khoa học tên lửa, mà là rất nhiều bộ phận chuyển động hoạt động cùng nhau mà tôi có thể không hoàn toàn quen thuộc, sau vài tuần mày mò, thu thập dữ liệu các bài đăng, và RTFM, nghĩ rằng tôi nên hỏi. Tôi hy vọng tôi đã cung cấp đủ chi tiết nhưng không kéo nó ra.
