Có cách nào để tạo bản sao bò trong ZFS không?

Tôi đang cố gắng tạo các bản sao của một số tệp / thư mục, nhưng trong một số cách tôi biết, tất cả dường như không tối ưu.

Ví dụ, btrfs có thể, với việc sử dụng cp --reflink=autonhanh chóng tạo các bản sao của tệp.

Những gì tôi đã thử:

1. Liên kết: Không tốt. Đổi tên tập tin, liên kết bị hỏng.
2. Hardlinks: Tốt hơn, nhưng vẫn không tốt. Thay đổi đối với một tệp sẽ thay đổi tệp khác và tôi không nhất thiết muốn tệp khác thay đổi.
3. Tạo ảnh chụp nhanh của tập dữ liệu, sau đó sao chép ảnh chụp nhanh: Điều này có thể hoạt động, nhưng không tốt. Thường thì tôi không tìm kiếm một bản sao của toàn bộ tập dữ liệu hoặc để các bản sao hoạt động như một tập dữ liệu khác. Sau đó, có các mối quan hệ cha / con giữa bản sao / ảnh chụp / bản gốc, mà theo tôi hiểu là khó, nếu không muốn nói là không thể phá vỡ.
4. Sử dụng zfs send/receivevà kích hoạt khấu trừ, sao chép tập dữ liệu sang tập dữ liệu mới: Điều này tránh các mối quan hệ cha / con sử dụng bản sao, nhưng vẫn không cần thiết tạo một tập dữ liệu khác và vẫn bị chậm trong các tệp phải đọc 100% và các khối tham chiếu lại thay vì bằng văn bản.
5. Sao chép tệp và để cho phần mềm thực hiện công việc của mình: Điều này hoạt động, nhưng chậm vì (các) tệp phải được đọc 100% và sau đó các khối được tham chiếu lại thay vì viết.

Sự chậm chạp của việc gửi / nhận zfs và sao chép hoặc rsyncing vật lý càng trở nên trầm trọng hơn vì hầu hết mọi thứ được lưu trữ nén và phải được giải nén trong quá trình đọc, sau đó được nén trước khi trích xuất để tham chiếu các khối trùng lặp.

Trong tất cả các nghiên cứu của tôi, tôi đã không thể tìm thấy bất cứ điều gì từ xa giống như sự đơn giản của --reflink trong btrfs.

Vì vậy, có cách nào để tạo bản sao bò trong ZFS không? Hoặc là sao chép "vật lý" và để cho các khoản trích lập thực hiện công việc của mình là lựa chọn thực sự duy nhất?

Tôi nghĩ tùy chọn 3 như bạn đã mô tả ở trên có lẽ là đặt cược tốt nhất của bạn. Vấn đề lớn nhất với những gì bạn muốn là ZFS thực sự chỉ xử lý bản sao này khi viết ở cấp độ tập dữ liệu / ảnh chụp.

Tôi thực sự khuyên bạn nên tránh sử dụng khấu trừ trừ khi bạn đã xác minh rằng nó hoạt động tốt với môi trường chính xác của bạn. Tôi có kinh nghiệm cá nhân với suy luận hoạt động tuyệt vời cho đến khi có thêm một người dùng hoặc cửa hàng VM được chuyển đến, và sau đó nó rơi khỏi một vách đá hiệu suất và gây ra rất nhiều vấn đề. Chỉ vì có vẻ như nó hoạt động rất tốt với mười người dùng đầu tiên của bạn, máy của bạn có thể bị đổ khi bạn thêm thứ mười một (hoặc mười hai, hoặc mười ba, hoặc bất cứ điều gì). Nếu bạn muốn đi theo con đường này, hãy chắc chắn rằng bạn có một môi trường thử nghiệm mô phỏng chính xác môi trường sản xuất của bạn và nó hoạt động tốt trong môi trường đó.

Quay lại tùy chọn 3, bạn sẽ cần thiết lập một bộ dữ liệu cụ thể để giữ từng cây hệ thống tệp mà bạn muốn quản lý theo cách này. Khi bạn đã thiết lập xong và bắt đầu nhập cư, hãy chụp ảnh nhanh (một cho mỗi tập dữ liệu sẽ hơi khác nhau) và sau đó quảng cáo thành bản sao. Không bao giờ chạm vào tập dữ liệu gốc một lần nữa.

Vâng, giải pháp này có vấn đề. Tôi không nói là không, nhưng với những hạn chế của ZFS, nó có lẽ vẫn là thứ tốt nhất. Tôi đã tìm thấy tài liệu tham khảo này cho ai đó sử dụng bản sao một cách hiệu quả: http://thegreyblog.blogspot.com/2009/05/spared-disk-space-with-zfs-clones.html

Tôi không thực sự quen thuộc với btrfs, nhưng nếu nó hỗ trợ các tùy chọn mà bạn muốn, bạn đã xem xét việc thiết lập một máy chủ riêng chỉ để hỗ trợ các bộ dữ liệu này, sử dụng Linux và btrfs trên máy chủ đó?

Tùy chọn 5 là lựa chọn tốt nhất.

Liên quan đến bộ dữ liệu cha / con trong tùy chọn 3, bạn có thể quảng cáo một bản sao và nó sẽ không còn là con của bộ dữ liệu nhân bản. Nó vẫn không sử dụng hết khối. Chỉnh sửa: Lưu ý rằng điều này chỉ đảo ngược mối quan hệ cha mẹ / con cái, không phá hủy nó.

Đối với những thứ được nén / mã hóa và làm chậm bản sao, điều đó hoàn toàn sai. Bộ xử lý của bạn nhanh hơn nhiều so với thiết bị khối của bạn (ngay cả khi sử dụng SSD). Chỉ với một số số ví dụ, giả sử rằng phải mất 10 giây để đọc một khối, nhưng chỉ mất một giây để giải nén nó và 2 giây để giải mã nó. Khối 1 được đọc trong 10 giây và gửi đến CPU. CPU bắt đầu giải nén và giải mã trong khi đĩa bắt đầu đọc khối 2. CPU sẽ hoàn thành nhiệm vụ trong 3 giây và sau đó dành 7 giây tiếp theo chờ vào đĩa. Trong khi đó, đĩa đã dành chính xác thời gian đọc hai khối đó (20 giây) bất kể các khối có được nén hay không.

Tương tự như vậy trong khi viết, chỉ có khối đầu tiên bị trì hoãn. CPU nén / mã hóa khối 1 và gửi nó vào đĩa. Trong khi đĩa ghi khối 1, CPU sẽ bắt đầu nén / mã hóa các khối tiếp theo. CPU sẽ nhai qua các khối nhanh hơn nhiều so với đĩa có thể ghi chúng để nó không thành vấn đề. (Vâng, nó phức tạp hơn thế này, nhưng đây là ý chính.)

Xin lỗi vì lời giải thích quá dài về một điểm nhỏ trong câu hỏi của bạn, nhưng tôi muốn làm sáng tỏ quan niệm sai lầm đó.