Unionfs vs Aufs vs Overlayfs vs mhddfs, tôi sử dụng cái nào


15

Tôi đã ngẫu nhiên đọc về hệ thống tệp hợp nhất cho phép người dùng gắn kết nhiều hệ thống tệp lên nhau.

Tuy nhiên, tôi đang gặp khó khăn khi quyết định sử dụng cái nào (Unionfs vs Aufs vs Overlayfs vs mhddfs) và tại sao như tôi không tìm thấy thông tin cụ thể về chủ đề này ở bất cứ đâu. Ví dụ, tôi biết rằng lớp phủ đã được sử dụng trong nhân Linux chính, điều đó có nghĩa là nó có thể được áp dụng rộng rãi hơn. Sẽ đánh giá cao nếu ai đó sẽ cho tôi một số quan điểm.

Ngoài ra, tôi không thể tìm thấy bất kỳ trường hợp sử dụng nào cho hệ thống tệp Union trên một cái gì đó như LVM (theo khuyến nghị của người dùng trong câu hỏi riêng ) hoặc thiết lập RAID ngoại trừ trong thực tế LVM yêu cầu định dạng tất cả các ổ đĩa có thể không mong muốn nếu bạn đã có dữ liệu có giá trị trên các ổ đĩa.


Tổng quát hơn, tôi vẫn đang chờ câu trả lời trên unix.stackexchange.com/questions/282393/union-mount-on-linux
Gilles 'SO- ngừng trở nên xấu xa'

Câu trả lời:


4

Dưới đây là một số suy nghĩ - tôi vẫn đang học điều này và sẽ cập nhật điều này khi tôi đi.

Cách chọn hệ thống tập tin công đoàn

Có hai cách để xem xét điều này:

  • Làm thế nào để các tính năng của mỗi một so sánh?
  • Đối với một số trường hợp sử dụng phổ biến, tôi nên chọn cái nào?

Tôi sẽ so sánh unionfs / unionfs-fuse / overlayfs / aufs / mergerfs, sau này là sự thay thế cho mhddfs.

Đặc điểm của từng người

Tình trạng phát triển

Hỗ trợ phân phối / hạt nhân

Có chế độ nhân và hệ thống tập tin chế độ người dùng, sau này chạy trên FUSE. Các chế độ hạt nhân có ít chi phí hoạt động hơn (có chi phí hoạt động khi mã chuyển đổi giữa không gian người dùng và không gian nhân) nhưng duy nhất hiện được hỗ trợ trong nhân Linux là lớp phủ . Hệ thống tập tin chế độ người dùng dễ dàng hơn cho việc phân phối gói.

  • unionfsaufs cần bản vá kernel
  • unionfs không được phân phối bởi Debian (phần còn lại là)
  • unionfs-fusemergerfs dựa trên FUSE, vì vậy không cần thêm các mô-đun trong kernel
  • lớp phủ đã là một phần của kernel kể từ 3.18 (Debian Stretch)

Sao chép trên viết

Điều này liên quan đến trường hợp sử dụng Live CD bên dưới:

  • sáp nhập không có bản sao trên ghi
  • Những người khác làm

Trường hợp sử dụng

Root chỉ đọc / Trường hợp sử dụng Live CD

Ý tưởng là có một phân vùng CD-ROM / chỉ đọc của hệ thống linux. Hệ thống tập tin liên kết làm cho nó trông giống như người dùng giống như nó là một hệ thống đọc-ghi để họ có thể thay đổi. Có một hệ thống tệp đọc-ghi (ví dụ: đĩa RAM tmpfs) lưu trữ "Delta" của bất kỳ thay đổi nào được thực hiện bởi người dùng, nhưng không phải là ảnh chụp nhanh.

Ở đây bất kỳ hệ thống tập tin công đoàn sẽ làm.

Trường hợp sử dụng Docker

Tôi biết đây là trường hợp sử dụng chính, nhưng không biết chi tiết - ai đó có thể cung cấp hướng dẫn về vấn đề này không?

Sáp nhập đĩa cứng

Ví dụ: bạn có thể có hai bộ /homethư mục trên các hệ thống tệp khác nhau. Hoặc bạn có thể nâng cấp máy tính ở nhà của bạn với một đĩa cứng thứ hai và muốn có một khối lượng logic duy nhất.

Đây là nơi bạn không thực sự muốn sao chép trên văn bản, vì vậy có thể sáp nhập là sự lựa chọn tốt nhất.

Liên kết hệ thống tập tin so với LVM để tổng hợp đĩa

Tôi sẽ liệt kê một số trường hợp sử dụng có thể đạt được với các hệ thống tập tin công đoàn nhưng không phải LVM:

Nếu bạn đang nâng cấp hệ thống hiện có với đĩa thứ hai, một cái gì đó như sáp nhập có thể tốt hơn vì LVM sẽ yêu cầu bạn định dạng lại đĩa cứng đầu tiên do đó làm mất dữ liệu trên đó. Một hệ thống tập tin công đoàn sẽ tránh bước này.

LVM có thể chia một tệp trên hai đĩa cứng vật lý (giả sử RAID 0), do đó bạn sẽ mất tệp nếu một đĩa cứng bị lỗi.

Một số người dùng có thể thích, ví dụ, để giữ /homethư mục của họ trên thẻ USB mà họ có thể lấy đi.

Trong trường hợp sử dụng một phân vùng ảo trên hai đĩa vật lý, với LVM, bạn không cần phải lo lắng về việc liệu các tệp được lưu trên một đĩa này hay đĩa kia. Với sự hợp nhất, hệ thống có thể tự động chọn cái nào cho bạn tùy thuộc vào dung lượng trống có sẵ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 cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.