Tôi có một vài TB dữ liệu cá nhân rất có giá trị trong một zpool mà tôi không thể truy cập do hỏng dữ liệu. Nhóm ban đầu được thiết lập trở lại vào năm 2009 hoặc lâu hơn trên hệ thống FreeBSD 7.2 chạy bên trong máy ảo VMWare trên hệ thống Ubuntu 8.04. FreeBSD VM vẫn khả dụng và chạy tốt, chỉ có hệ điều hành máy chủ hiện đã thay đổi thành Debian 6. Các ổ cứng được truy cập cho VM khách bằng các thiết bị SCSI chung của VMWare, tổng cộng 12 chiếc.
Có 2 hồ bơi:
- zpool01: 2x 4x 500GB
- zpool02: 1x 4x 160GB
Một cái hoạt động trống rỗng, cái bị hỏng chứa tất cả các dữ liệu quan trọng:
[user@host~]$ uname -a
FreeBSD host.domain 7.2-RELEASE FreeBSD 7.2-RELEASE #0: \
Fri May 1 07:18:07 UTC 2009 \
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
[user@host ~]$ dmesg | grep ZFS
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
ZFS filesystem version 6
ZFS storage pool version 6
[user@host ~]$ sudo zpool status
pool: zpool01
state: UNAVAIL
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool01 UNAVAIL 0 0 0 insufficient replicas
raidz1 UNAVAIL 0 0 0 corrupted data
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
da8 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
pool: zpool02
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool02 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da9 ONLINE 0 0 0
da10 ONLINE 0 0 0
da11 ONLINE 0 0 0
da12 ONLINE 0 0 0
errors: No known data errors
Tôi đã có thể truy cập vào hồ bơi một vài tuần trước. Kể từ đó, tôi đã phải thay thế khá nhiều phần cứng của máy chủ và cài đặt một số hệ điều hành máy chủ.
Sự nghi ngờ của tôi là một trong những cài đặt hệ điều hành này đã viết một bộ tải khởi động (hoặc bất cứ thứ gì) cho một (ổ đầu tiên?) Của ổ đĩa 500 GB và phá hủy một số siêu dữ liệu zpool (hoặc bất cứ điều gì) - 'hoặc bất cứ điều gì' có nghĩa là đây chỉ là một ý tưởng rất mơ hồ và chủ đề đó không chính xác là mặt mạnh của tôi ...
Có rất nhiều trang web, blog, danh sách gửi thư, v.v. về ZFS. Tôi đăng câu hỏi này lên đây với hy vọng nó giúp tôi thu thập đủ thông tin cho một cách tiếp cận lành mạnh, có cấu trúc, kiểm soát, thông báo, có hiểu biết để lấy lại dữ liệu của tôi - và hy vọng giúp đỡ người khác trong tình huống tương tự.
Kết quả tìm kiếm đầu tiên khi tìm kiếm 'zfs recovery' là chương Xử lý sự cố và khôi phục dữ liệu ZFS từ Hướng dẫn quản trị ZFS của Solaris. Trong phần Chế độ Thất bại ZFS đầu tiên , nó nói trong đoạn 'Dữ liệu ZFS bị hỏng':
Tham nhũng dữ liệu luôn là vĩnh viễn và cần được xem xét đặc biệt trong quá trình sửa chữa. Ngay cả khi các thiết bị cơ bản được sửa chữa hoặc thay thế, dữ liệu gốc sẽ bị mất vĩnh viễn.
Hơi bất công.
Tuy nhiên, kết quả tìm kiếm thứ hai của google là weblog của Max Bruning và trong đó, tôi đã đọc
Gần đây, tôi đã được gửi một email từ một người có 15 năm video và nhạc được lưu trữ trong nhóm ZFS 10TB mà sau khi mất điện, đã bị lỗi. Thật không may, anh ta không có một bản sao lưu. Anh ấy đã sử dụng ZFS phiên bản 6 trên FreeBSD 7 [...] Sau khi dành khoảng 1 tuần để kiểm tra dữ liệu trên đĩa, tôi đã có thể khôi phục về cơ bản tất cả dữ liệu đó.
và
Đối với ZFS mất dữ liệu của bạn, tôi nghi ngờ nó. Tôi nghi ngờ dữ liệu của bạn ở đó, nhưng bạn cần tìm đúng cách để có được nó.
(nghe có vẻ giống với những gì tôi muốn nghe ...)
Bước đầu tiên : chính xác vấn đề là gì?
Làm thế nào tôi có thể chẩn đoán tại sao chính xác zpool được báo cáo là bị hỏng? Tôi thấy có zdb mà dường như không được tài liệu chính thức bởi Sun hay Oracle ở bất cứ đâu trên web. Từ trang người đàn ông của nó:
NAME
zdb - ZFS debugger
SYNOPSIS
zdb pool
DESCRIPTION
The zdb command is used by support engineers to diagnose failures and
gather statistics. Since the ZFS file system is always consistent on
disk and is self-repairing, zdb should only be run under the direction
by a support engineer.
If no arguments are specified, zdb, performs basic consistency checks
on the pool and associated datasets, and report any problems detected.
Any options supported by this command are internal to Sun and subject
to change at any time.
Hơn nữa, Ben Rockwood đã đăng một bài viết chi tiết và có một video về Max Bruning nói về nó (và mdb) tại Hội nghị nhà phát triển Open Solaris ở Prague vào ngày 28 tháng 6 năm 2008.
Chạy zdb với quyền root trên zpool bị hỏng sẽ cho đầu ra sau:
[user@host ~]$ sudo zdb zpool01
version=6
name='zpool01'
state=0
txg=83216
pool_guid=16471197341102820829
hostid=3885370542
hostname='host.domain'
vdev_tree
type='root'
id=0
guid=16471197341102820829
children[0]
type='raidz'
id=0
guid=48739167677596410
nparity=1
metaslab_array=14
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=4795262086800816238
path='/dev/da5'
whole_disk=0
DTL=202
children[1]
type='disk'
id=1
guid=16218262712375173260
path='/dev/da6'
whole_disk=0
DTL=201
children[2]
type='disk'
id=2
guid=15597847700365748450
path='/dev/da7'
whole_disk=0
DTL=200
children[3]
type='disk'
id=3
guid=9839399967725049819
path='/dev/da8'
whole_disk=0
DTL=199
children[1]
type='raidz'
id=1
guid=8910308849729789724
nparity=1
metaslab_array=119
metaslab_shift=34
ashift=9
asize=2000412475392
children[0]
type='disk'
id=0
guid=5438331695267373463
path='/dev/da1'
whole_disk=0
DTL=198
children[1]
type='disk'
id=1
guid=2722163893739409369
path='/dev/da2'
whole_disk=0
DTL=197
children[2]
type='disk'
id=2
guid=11729319950433483953
path='/dev/da3'
whole_disk=0
DTL=196
children[3]
type='disk'
id=3
guid=7885201945644860203
path='/dev/da4'
whole_disk=0
DTL=195
zdb: can't open zpool01: Invalid argument
Tôi cho rằng lỗi 'đối số không hợp lệ' ở cuối xảy ra do zpool01 không thực sự tồn tại: Nó không xảy ra trên zpool02 đang hoạt động, nhưng dường như không có bất kỳ đầu ra nào nữa ...
OK, ở giai đoạn này, có lẽ tốt hơn để đăng bài này trước khi bài viết quá dài.
Có lẽ ai đó có thể cho tôi một lời khuyên về cách di chuyển từ đây và trong khi chờ phản hồi, tôi sẽ xem video, xem chi tiết về đầu ra zdb ở trên, đọc bài viết của Bens và cố gắng tìm hiểu xem gì...
20110806-1600 + 1000
Cập nhật 01:
Tôi nghĩ rằng tôi đã tìm ra nguyên nhân gốc rễ: Max Bruning rất tốt bụng khi trả lời email của tôi rất nhanh, yêu cầu đầu ra zdb -lll. Trên bất kỳ một trong 4 ổ đĩa cứng trong nửa 'tốt' raidz1 của nhóm, kết quả đầu ra tương tự như những gì tôi đã đăng ở trên. Tuy nhiên, trên 3 trong số 4 ổ đĩa đầu tiên trong nửa 'bị hỏng', zdbcác báo cáo failed to unpack labelcho nhãn 2 và 3. Ổ đĩa thứ tư trong nhóm có vẻ ổn, zdbhiển thị tất cả các nhãn.
Googling rằng thông báo lỗi mang đến bài viết này . Từ phản hồi đầu tiên cho bài viết đó:
Với ZFS, đó là 4 nhãn giống hệt nhau trên mỗi vdev vật lý, trong trường hợp này là một ổ cứng. L0 / L1 khi bắt đầu vdev và L2 / L3 ở cuối vdev.
Tất cả 8 ổ đĩa trong hồ bơi là cùng một mô hình, Seagate Barracuda 500GB . Tuy nhiên, tôi nhớ rằng tôi đã khởi động bể bơi với 4 ổ đĩa, sau đó một trong số chúng đã chết và được Seagate thay thế theo bảo hành. Sau đó, tôi đã thêm 4 ổ đĩa. Vì lý do đó, các định danh ổ đĩa và phần sụn khác nhau:
[user@host ~]$ dmesg | egrep '^da.*?: <'
da0: <VMware, VMware Virtual S 1.0> Fixed Direct Access SCSI-2 device
da1: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da2: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da3: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da4: <ATA ST3500418AS CC37> Fixed Direct Access SCSI-5 device
da5: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da6: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da7: <ATA ST3500320AS SD15> Fixed Direct Access SCSI-5 device
da8: <ATA ST3500418AS CC35> Fixed Direct Access SCSI-5 device
da9: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da10: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da11: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
da12: <ATA SAMSUNG HM160JC AP10> Fixed Direct Access SCSI-5 device
Tôi nhớ rằng tất cả các ổ đĩa có cùng kích thước. Nhìn vào các ổ đĩa bây giờ, nó cho thấy kích thước đã thay đổi đối với ba trong số chúng, chúng đã bị thu hẹp 2 MB:
[user@host ~]$ dmesg | egrep '^da.*?: .*?MB '
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da1: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da2: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da3: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da4: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da5: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da6: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da7: 476938MB (976771055 512 byte sectors: 255H 63S/T 60801C) <--
da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C)
da9: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da10: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da11: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
da12: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C)
Vì vậy, bởi vẻ bề ngoài của nó, nó không phải là một trong những bản cài đặt hệ điều hành 'đã viết một bộ tải khởi động cho một ổ đĩa' (như tôi đã giả định trước đó), nó thực sự là bo mạch chủ mới ( ASUS P8P67 LE ) tạo ra máy chủ 2 MB khu vực được bảo vệ ở cuối ba trong số các ổ đĩa đã làm rối tung siêu dữ liệu ZFS của tôi.
Tại sao nó không tạo ra HPA trên tất cả các ổ đĩa? Tôi tin rằng điều này là do việc tạo HPA chỉ được thực hiện trên các ổ đĩa cũ có lỗi đã được sửa sau đó bởi bản cập nhật BIOS của ổ cứng Seagate: Khi toàn bộ sự cố này bắt đầu vài tuần trước, tôi đã chạy SeaTools của Seagate để kiểm tra xem có bất cứ điều gì sai về mặt vật lý với các ổ đĩa (vẫn trên phần cứng cũ) và tôi nhận được một thông báo cho tôi biết rằng một số ổ đĩa của tôi cần cập nhật BIOS. Vì hiện tại tôi đang cố gắng tái tạo các chi tiết chính xác của thông báo đó và liên kết đến bản tải xuống bản cập nhật firmware, có vẻ như vì bo mạch chủ đã tạo ra HPA, cả hai phiên bản SeaTools DOS đều không phát hiện ra ổ cứng trong câu hỏi - nhanh invalid partitionhay tương tự nhấp nháy khi họ bắt đầu, đó là nó. Trớ trêu thay, họ cũng tìm thấy một bộ ổ đĩa Samsung.
(Tôi đã bỏ qua các chi tiết đau đớn, tốn thời gian và cuối cùng là vô ích khi vặn vít trong vỏ FreeDOS trên một hệ thống không nối mạng.) Cuối cùng, tôi đã cài đặt Windows 7 trên một máy riêng biệt để chạy SeaTools Windows phiên bản 1.2.0.5. Chỉ là một nhận xét cuối cùng về DOS SeaTools: Đừng bận tâm cố gắng khởi động chúng độc lập - thay vào đó, hãy đầu tư một vài phút và tạo ra một chiếc USB có thể khởi động với CD Ultimate Boot tuyệt vời - ngoài DOS SeaTools còn mang đến cho bạn nhiều thứ khác thực sự Công cụ hữu ích.
Khi bắt đầu, SeaTools cho Windows hiển thị hộp thoại này:
Các liên kết dẫn đến Trình kiểm tra số sê-ri (vì lý do nào đó được bảo vệ bởi captcha - của tôi là 'Người dùng xâm lấn') và một bài viết cơ sở kiến thức về cập nhật chương trình cơ sở . Có thể có thêm các liên kết cụ thể cho mô hình ổ đĩa cứng và một số tải xuống và những gì không, nhưng tôi sẽ không đi theo con đường đó vào lúc này:
Tôi sẽ không vội vã cập nhật chương trình cơ sở của ba ổ đĩa tại một thời điểm có các phân vùng bị cắt ngắn và là một phần của nhóm lưu trữ bị hỏng. Đó là yêu cầu rắc rối. Đối với người mới bắt đầu, bản cập nhật phần sụn rất có thể không thể hoàn tác - và điều đó có thể hủy hoại cơ hội của tôi để lấy lại dữ liệu của tôi.
Do đó, điều đầu tiên tôi sẽ làm tiếp theo là hình ảnh các ổ đĩa và làm việc với các bản sao, do đó, có một bản gốc để quay lại nếu có bất cứ điều gì sai. Điều này có thể giới thiệu một sự phức tạp bổ sung, vì ZFS có thể sẽ nhận thấy rằng các ổ đĩa đã bị tráo đổi (bằng số sê-ri ổ đĩa hoặc một UUID khác hoặc bất cứ thứ gì), mặc dù đó là bản sao dd chính xác trên cùng một mô hình ổ đĩa cứng. Hơn nữa, zpool thậm chí không sống. Chàng trai, điều này có thể nhận được khó khăn.
Tuy nhiên, tùy chọn khác sẽ là làm việc với các bản gốc và giữ các ổ đĩa được nhân đôi làm bản sao lưu, nhưng sau đó có lẽ tôi sẽ gặp phải sự phức tạp ở trên khi có sự cố xảy ra với bản gốc. Naa, không tốt.
Để xóa ba ổ cứng sẽ đóng vai trò thay thế hình ảnh cho ba ổ đĩa với BIOS bị lỗi trong bể bị hỏng, tôi cần tạo một số không gian lưu trữ cho những thứ hiện có, vì vậy tôi sẽ đào sâu vào hộp phần cứng và lắp ráp một zpool tạm thời từ một số ổ đĩa cũ - mà tôi cũng có thể sử dụng để kiểm tra cách ZFS xử lý các ổ đĩa hoán đổi.
Có lẽ sẽ mất một lúc...
20111213-1930 + 1100
Cập nhật 02:
Điều này đã thực sự mất một thời gian. Tôi đã dành nhiều tháng với một số vỏ máy tính mở trên bàn với nhiều ngăn đựng ổ cứng khác nhau và cũng ngủ vài đêm với nút tai, vì tôi không thể tắt máy trước khi đi ngủ vì nó đang hoạt động rất lâu. . Tuy nhiên, cuối cùng tôi đã thắng thế! :-) Tôi cũng đã học được rất nhiều trong quá trình và tôi muốn chia sẻ kiến thức đó ở đây cho bất cứ ai trong tình huống tương tự.
Bài viết này đã dài hơn nhiều so với bất kỳ ai có máy chủ tệp ZFS không có thời gian để đọc, vì vậy tôi sẽ đi vào chi tiết ở đây và tạo câu trả lời với những phát hiện quan trọng dưới đây.
Tôi đã đào sâu trong hộp phần cứng lỗi thời để lắp ráp đủ dung lượng lưu trữ để di chuyển các thứ ra khỏi các ổ đĩa 500 GB duy nhất mà các ổ đĩa bị lỗi được nhân đôi. Tôi cũng đã phải lấy ra một vài ổ đĩa cứng trong các hộp đựng USB của họ, vì vậy tôi có thể kết nối chúng trực tiếp qua SATA. Có một số vấn đề khác không liên quan và một số ổ đĩa cũ bắt đầu thất bại khi tôi đưa chúng trở lại hoạt động yêu cầu thay thế zpool, nhưng tôi sẽ bỏ qua điều đó.
Mẹo: Ở giai đoạn nào đó, có tổng cộng khoảng 30 ổ cứng liên quan đến việc này. Với phần cứng lớn như vậy, sẽ giúp ích rất nhiều cho việc xếp chúng đúng cách; dây cáp bị lỏng hoặc ổ cứng rơi ra khỏi bàn của bạn chắc chắn sẽ không giúp ích gì trong quá trình và có thể gây tổn hại thêm cho tính toàn vẹn dữ liệu của bạn.
Tôi đã dành một vài phút để tạo ra một số đồ đạc ổ cứng thay đổi thực sự giúp sắp xếp mọi thứ:
Trớ trêu thay, khi tôi kết nối các ổ đĩa cũ lần đầu tiên, tôi nhận ra rằng có một zpool cũ ở đó tôi phải tạo để thử nghiệm với một phiên bản cũ hơn của một số, nhưng không phải tất cả dữ liệu cá nhân bị mất, vì vậy trong khi mất dữ liệu giảm bớt phần nào, điều này có nghĩa là dịch chuyển qua lại các tập tin.
Cuối cùng, tôi đã nhân đôi các ổ đĩa có vấn đề sang các ổ đĩa sao lưu, sử dụng các ổ đĩa cho zpool và khiến các ổ đĩa gốc bị ngắt kết nối. Các ổ đĩa sao lưu có chương trình cơ sở mới hơn, ít nhất SeaTools không báo cáo bất kỳ cập nhật chương trình cơ sở cần thiết nào. Tôi đã thực hiện phản chiếu với một dd đơn giản từ thiết bị này sang thiết bị khác, vd
sudo dd if=/dev/sda of=/dev/sde
Tôi tin rằng ZFS không nhận thấy sự thay đổi phần cứng (bởi một số UUID ổ cứng hoặc bất cứ điều gì), nhưng dường như không quan tâm.
Tuy nhiên, zpool vẫn ở trạng thái tương tự, không đủ bản sao / dữ liệu bị hỏng.
Như đã đề cập trong bài viết Wikipedia HPA đã đề cập trước đó, sự hiện diện của một khu vực được bảo vệ máy chủ được báo cáo khi Linux khởi động và có thể được điều tra bằng cách sử dụng hdparm . Theo như tôi biết, không có công cụ hdparm nào có sẵn trên FreeBSD, nhưng đến lúc này, dù sao tôi cũng đã cài đặt FreeBSD 8.2 và Debian 6.0 làm hệ thống khởi động kép, vì vậy tôi đã khởi động vào Linux:
user@host:~$ for i in {a..l}; do sudo hdparm -N /dev/sd$i; done
...
/dev/sdd:
max sectors = 976773168/976773168, HPA is disabled
/dev/sde:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdf:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdg:
max sectors = 976771055/976773168, HPA is enabled
/dev/sdh:
max sectors = 976773168/976773168, HPA is disabled
...
Vì vậy, vấn đề rõ ràng là bo mạch chủ mới đã tạo ra một HPA gồm vài megabyte ở cuối ổ đĩa, nơi ẩn giấu hai nhãn ZFS phía trên, tức là ngăn ZFS nhìn thấy chúng.
Đắm chìm với HPA dường như là một công việc nguy hiểm. Từ trang man hdparm, tham số -N:
Get/set max visible number of sectors, also known as the Host Protected Area setting.
...
To change the current max (VERY DANGEROUS, DATA LOSS IS EXTREMELY LIKELY), a new value
should be provided (in base10) immediately following the -N option.
This value is specified as a count of sectors, rather than the "max sector address"
of the drive. Drives have the concept of a temporary (volatile) setting which is lost on
the next hardware reset, as well as a more permanent (non-volatile) value which survives
resets and power cycles. By default, -N affects only the temporary (volatile) setting.
To change the permanent (non-volatile) value, prepend a leading p character immediately
before the first digit of the value. Drives are supposed to allow only a single permanent
change per session. A hardware reset (or power cycle) is required before another
permanent -N operation can succeed.
...
Trong trường hợp của tôi, HPA được loại bỏ như thế này:
user@host:~$ sudo hdparm -Np976773168 /dev/sde
/dev/sde:
setting max visible sectors to 976773168 (permanent)
max sectors = 976773168/976773168, HPA is disabled
và theo cách tương tự cho các ổ đĩa khác có HPA. Nếu bạn nhận được ổ đĩa sai hoặc một cái gì đó về tham số kích thước bạn chỉ định là không hợp lý, hdparm đủ thông minh để tìm:
user@host:~$ sudo hdparm -Np976773168 /dev/sdx
/dev/sdx:
setting max visible sectors to 976773168 (permanent)
Use of -Nnnnnn is VERY DANGEROUS.
You have requested reducing the apparent size of the drive.
This is a BAD idea, and can easily destroy all of the drive's contents.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.
Sau đó, tôi khởi động lại máy ảo FreeBSD 7.2 mà zpool ban đầu được tạo và trạng thái zpool báo cáo một nhóm hoạt động trở lại. YAY! :-)
Tôi đã xuất pool trên hệ thống ảo và nhập lại nó trên hệ thống FreeBSD 8.2 của máy chủ.
Một số nâng cấp phần cứng lớn hơn, hoán đổi bo mạch chủ khác, cập nhật nhóm ZFS lên ZFS 4/15, một sự cọ sát kỹ lưỡng và bây giờ zpool của tôi bao gồm các bộ phận raidz2 8x1TB cộng với 8x500GB:
[user@host ~]$ sudo zpool status
pool: zpool
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zpool ONLINE 0 0 0
raidz2 ONLINE 0 0 0
ad0 ONLINE 0 0 0
ad1 ONLINE 0 0 0
ad2 ONLINE 0 0 0
ad3 ONLINE 0 0 0
ad8 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad14 ONLINE 0 0 0
ad16 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0
da7 ONLINE 0 0 0
errors: No known data errors
[user@host ~]$ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/label/root 29G 13G 14G 49% /
devfs 1.0K 1.0K 0B 100% /dev
zpool 8.0T 3.6T 4.5T 44% /mnt/zpool
Như một từ cuối cùng, đối với tôi, các nhóm ZFS rất, rất khó bị tiêu diệt. Những kẻ đến từ Sun, người đã tạo ra hệ thống đó có tất cả lý do gọi đó là từ cuối cùng trong các hệ thống tập tin. Sự tôn trọng!