Giới hạn thực tế về số lượng ảnh chụp nhanh btrfs?

Tôi đang xem xét sử dụng btrfs trên ổ dữ liệu của mình để tôi có thể sử dụng snapper , hoặc một cái gì đó như snapper, để chụp ảnh nhanh dựa trên thời gian. Tôi tin rằng điều này sẽ cho phép tôi duyệt các phiên bản cũ của dữ liệu của mình. Điều này sẽ bổ sung cho bản sao lưu trang web hiện tại của tôi vì lỗi ổ đĩa sẽ xóa sạch dữ liệu và ảnh chụp nhanh.

Theo hiểu biết của tôi, ảnh chụp nhanh btrfs không chiếm nhiều dung lượng (dữ liệu meta và các khối đã thay đổi, cộng với có thể là một số chi phí), vì vậy không gian dường như không phải là một hạn chế.

Nếu tôi có một triệu ảnh chụp nhanh (ví dụ: một ảnh chụp nhanh mỗi phút trong hai năm) sẽ gây ra sự tàn phá, giả sử tôi có đủ dung lượng đĩa cho dữ liệu, dữ liệu thay đổi và dữ liệu meta?

Nếu có giới hạn thực tế về số lượng ảnh chụp nhanh, nó có phụ thuộc vào số lượng tệp và / hoặc kích thước của tệp không?

Là một người đang sử dụng một btrfshệ thống tập tin Arch Linuxtrong gần 2nhiều năm nay, tôi có thể nói một cách an toàn rằng dường như không có giới hạn thực tế nào về số lượng ảnh chụp nhanh có thể dễ dàng đạt được. Có một số hãy cẩn thận mặc dù. btrfshệ thống tập tin có thể dẫn đến phân mảnh. Do đó, nên sử dụng tính năng chống phân mảnh trực tuyến được tích hợp btrfs. Hơn nữa, người ta có thể sử dụng tốt btrfstính năng nén của. Các biện pháp này sẽ quan tâm đến hầu hết các vấn đề về hiệu năng có thể phát sinh một cách hợp lý trên một máy tính khá hợp lý từ việc tạo ra nhiều ảnh chụp nhanh.

Như bạn có thể biết btrfscoi các subvolume là các hệ thống tệp và do đó số lượng ảnh chụp nhanh thực sự bị giới hạn: cụ thể là bởi kích thước của các tệp. Theo btrfswiki, kích thước tệp tối đa có thể đạt được là 2^64 byte == 16 EiB^[1] .

Ngoài những hạn chế đó, có thể luôn có vấn đề khi bạn hết dung lượng mà bạn không nhận ra ngay lập tức vì việc kiểm tra không gian trống trên các btrfshệ thống tệp đôi khi có thể khó khăn, tức là không thể phân biệt giữa các phương pháp đo không gian trống trên btrfshệ thống tệp. dễ dàng sử dụng theo dõi lượng không gian thực sự còn lại. Một cách có thể để ngăn chặn kịch bản này là sử dụng hạn ngạch. Điều này đảm bảo rằng người dùng (hoặc người dùng nếu chỉ có một) chỉ có thể sử dụng một lượng không gian nhất định. Khái niệm này được thảo luận rất ably ở đây và cũng ở đây .

Cuối cùng nhưng không kém phần cảnh báo: Tôi không phải là chuyên gia về btrfshệ thống tập tin và chỉ đọc về những điều này khi tôi có cùng một câu hỏi trước đây. Hơn nữa, luôn có vấn đề btrfslà "mục tiêu di chuyển nhanh" (từ ngữ hay bị đánh cắp từ một Arch Linuxtrang wiki tôi nghĩ vậy) nên mọi thứ có thể thay đổi.

Mặc dù về mặt kỹ thuật không có giới hạn về số lượng ảnh chụp nhanh, tôi đã hỏi trong danh sách gửi thư BTRFS :

Câu trả lời (thực tế) phụ thuộc vào một mức độ nào đó vào cách bạn sử dụng btrfs.

Btrfs không có vấn đề mở rộng do có quá nhiều ảnh chụp nhanh (hoặc thực tế là sử dụng ảnh chụp nhanh phản xạ, việc sử dụng tính năng phản xạ có thể gây ra các vấn đề tỷ lệ tương tự) và các ảnh chụp nhanh hai chữ số thấp cho mỗi ảnh chụp nhanh được lưu lại vẫn là khuyến nghị mạnh mẽ cho lý do đó.

Nhưng các vấn đề mở rộng chủ yếu ảnh hưởng đến chính các lệnh bảo trì btrfs, cân bằng, kiểm tra, xóa subvolume. Mặc dù hàng triệu ảnh chụp nhanh sẽ khiến cân bằng không thể hoạt động hiệu quả (nó sẽ hoạt động nhưng có thể mất vài tháng), các hoạt động của hệ thống tệp thông thường như đọc và lưu tệp không có xu hướng bị ảnh hưởng, ngoại trừ việc phân mảnh trở thành vấn đề ( các hệ thống tập tin bò như btrfs được ghi chú cho phân mảnh, trừ khi các bước như chống phân mảnh được thực hiện để giảm bớt nó).

Có vẻ như sử dụng ảnh chụp nhanh như một bản sao lưu lưu trữ tương tự như cỗ máy thời gian / snapper không phải là một ý tưởng tốt.

Bạn có thể có tổng cộng 2 ⁶⁴ ảnh chụp nhanh và subvolume.

Các btrfstrang thiết kế wiki nói (mỏ empahsis):

Subvolume về cơ bản là một btree có tên chứa các tệp và thư mục. Chúng có các nút bên trong cây rễ cây và có thể có các chủ sở hữu và nhóm không gốc. Subvolume có thể được đưa ra một hạn ngạch của các khối, và một khi đạt được hạn ngạch này, không được phép ghi mới. Tất cả các khối và phạm vi tệp bên trong các tệp con được tính tham chiếu để cho phép chụp nhanh. Có thể tạo tối đa 2 ⁶⁴ subvolume trên FS.

Ảnh chụp nhanh giống hệt với subvolume , nhưng khối gốc của chúng ban đầu được chia sẻ với một subvolume khác. Khi ảnh chụp nhanh được thực hiện, số tham chiếu trên khối gốc được tăng lên và bản sao trên hệ thống giao dịch ghi đảm bảo các thay đổi được thực hiện trong ảnh chụp nhanh hoặc subvolume nguồn là riêng tư đối với gốc đó. Ảnh chụp nhanh có thể ghi và chúng có thể được chụp lại bất kỳ số lần nào. Nếu các ảnh chụp nhanh chỉ đọc được mong muốn, hạn ngạch khối của chúng được đặt thành một tại thời điểm tạo.