Hiện tại tôi đang sử dụng ArchiveMountđể gắn kết một kho lưu trữ 123.000 kb chứa hơn 3 triệu tệp bên trong. Cho đến nay nó đã được gắn kết hơn 5 giờ và vẫn chưa hoàn thành.

Có cách nào tốt hơn để gắn kết một .tar.gztập tin? Tôi đang cố gắn vào một thư mục, và không nén nó phải mất một vài hợp đồng biểu diễn. Tôi thậm chí không cần chế độ viết, chỉ cần đọc là đủ.

Bạn cũng có thể tạo một hình ảnh squashfs nén

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

Để làm điều này, bạn sẽ cần trích xuất archvie tar.gz của mình.

Ưu điểm là hình ảnh có khả năng chịu lỗi tốt hơn gz.

Tôi đã viết một tỷ lệ thay thế nhanh hơn , "hoạt động cho tôi", bởi vì vấn đề này liên tục làm tôi khó chịu.

Bạn có thể sử dụng nó như thế này:

pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level

Khi bạn hoàn thành, bạn có thể ngắt kết nối nó như bất kỳ ngàm FUSE nào:

fusermount -u mount-folder

Tại sao nó nhanh hơn archivemount?

Nó phụ thuộc vào những gì bạn đo lường.

Dưới đây là điểm chuẩn của dấu chân bộ nhớ và thời gian cần thiết cho lần gắn đầu tiên, cũng như thời gian truy cập cho một cat <file-in-tar>lệnh đơn giản và một findlệnh đơn giản .

Các thư mục chứa mỗi tệp 1k đã được tạo và số lượng thư mục rất đa dạng.

Biểu đồ bên trái phía dưới hiển thị các thanh lỗi cho biết thời gian đo tối thiểu và tối đa cat <file>cho 10 tệp được chọn ngẫu nhiên.

Thời gian tìm kiếm tập tin

Sự so sánh sát thủ là thời gian cần thiết cat <file>để kết thúc. Vì một số lý do, điều này chia tỷ lệ tuyến tính với kích thước tệp TAR (xấp xỉ byte trên mỗi tệp x số tệp) cho lưu trữ trong khi có thời gian không đổi theo tỷ lệ. Điều này làm cho nó trông giống như archivemount thậm chí không hỗ trợ tìm kiếm.

Đối với các tệp TAR nén, điều này đặc biệt đáng chú ý. cat <file>mất hơn hai lần miễn là gắn toàn bộ tệp .tar.bz2! Ví dụ: TAR với các tệp trống 10k (!) Phải mất 2.9 giây để gắn kết với lưu trữ nhưng tùy thuộc vào tệp được truy cập, quyền truy cập catmất từ ​​3ms đến 5s. Thời gian cần thiết dường như phụ thuộc vào vị trí của tệp bên trong TAR. Các tệp ở cuối TAR mất nhiều thời gian hơn để tìm kiếm; chỉ ra rằng "tìm kiếm" được mô phỏng và tất cả nội dung trong TAR trước khi tệp đang được đọc.

Việc nhận nội dung tệp có thể mất hơn gấp đôi thời gian vì việc cài đặt toàn bộ TAR là bất ngờ. Ít nhất, nó sẽ hoàn thành trong cùng một khoảng thời gian như gắn kết. Một lời giải thích là tập tin đang được mô phỏng tìm kiếm nhiều lần, thậm chí có thể ba lần.

Ratarmount dường như luôn mất cùng một lượng thời gian để có được một tệp vì nó hỗ trợ tìm kiếm thực sự. Đối với các TAR được nén bzip2, nó thậm chí còn tìm đến khối bzip2, có địa chỉ cũng được lưu trong tệp chỉ mục. Về mặt lý thuyết, phần duy nhất nên chia tỷ lệ với số lượng tệp là tra cứu trong chỉ mục và nên chia tỷ lệ với O (log (n)) vì nó được sắp xếp theo đường dẫn và tên tệp.

Mức chiếm dụng bộ nhớ

Nói chung, nếu bạn có hơn 20k tệp trong TAR, thì dung lượng bộ nhớ của ratarmount sẽ nhỏ hơn vì chỉ mục được ghi vào đĩa khi nó được tạo và do đó có dung lượng bộ nhớ không đổi khoảng 30MB trên hệ thống của tôi.

Một ngoại lệ nhỏ là phụ trợ bộ giải mã gzip, vì một số lý do đòi hỏi nhiều bộ nhớ hơn khi gzip trở nên lớn hơn. Chi phí bộ nhớ này có thể là chỉ số cần thiết để tìm kiếm bên trong TAR nhưng cần điều tra thêm vì tôi không viết phần phụ trợ đó.

Ngược lại, archivemount giữ toàn bộ chỉ mục, ví dụ: 4GB cho các tệp 2M, hoàn toàn trong bộ nhớ miễn là TAR được gắn.

Thời gian gắn kết

Tính năng yêu thích của tôi là ratarmount có thể gắn TAR mà không bị chậm trễ đáng kể trong bất kỳ lần thử tiếp theo nào. Điều này là do chỉ mục, ánh xạ tên tệp thành siêu dữ liệu và vị trí bên trong TAR, được ghi vào tệp chỉ mục được tạo bên cạnh tệp TAR.

Thời gian cần thiết để gắn kết hành xử hơi kỳ lạ trong archivemount. Bắt đầu từ khoảng 20k tệp, nó bắt đầu chia tỷ lệ bậc hai thay vì tuyến tính đối với số lượng tệp. Điều này có nghĩa là bắt đầu từ khoảng 4 triệu tệp, tỷ lệ bắt đầu nhanh hơn nhiều so với lưu trữ mặc dù đối với các tệp TAR nhỏ hơn, nó chậm hơn tới 10 lần! Sau đó, một lần nữa, đối với các tệp nhỏ hơn, không cần quan tâm nhiều đến việc phải mất 1 giây hay 0,1 giây để gắn tar (lần đầu tiên).

Thời gian gắn cho các tệp nén bz2 là tương đương nhất mọi lúc. Điều này rất có thể bởi vì nó bị ràng buộc bởi tốc độ của bộ giải mã bz2. Ratarmount chậm hơn khoảng 2 lần ở đây. Tôi hy vọng sẽ làm cho người chiến thắng trở thành người chiến thắng rõ ràng bằng cách song song bộ giải mã bz2 trong tương lai gần, điều mà ngay cả đối với hệ thống 8 tuổi của tôi có thể mang lại tốc độ tăng gấp 4 lần.

Thời gian để có được siêu dữ liệu

Khi chỉ liệt kê tất cả các tệp có findbên trong TAR (dường như cũng gọi stat cho mỗi tệp!?), Ratarmount chậm hơn 10 lần so với lưu trữ cho tất cả các trường hợp được thử nghiệm. Tôi hy vọng sẽ cải thiện điều này trong tương lai. Nhưng hiện tại, nó trông giống như một vấn đề thiết kế vì sử dụng Python và SQLite thay vì chương trình C thuần túy.

Vấn đề ở đây là với định dạng, định dạng TAR (Băng ARchive) được thiết kế để truy cập tuần tự, không phải truy cập ngẫu nhiên. Và gzip là một bổ sung tốt cho tar, vì nó là định dạng nén dựa trên luồng, cũng không dành cho truy cập ngẫu nhiên.

Vì vậy, một công cụ cấp cao không tương tác trực tiếp với các khối được nén, sẽ phải phân tích toàn bộ tệp mỗi khi nó cần đọc bất cứ thứ gì, trước tiên để lấy cho bạn danh sách các tệp, sau đó có lẽ bộ đệm sẽ vô hiệu hóa và nó sẽ đọc lại và sau đó cho mỗi tệp bạn sao chép nó có thể đọc lại nó. Bạn có thể tạo một công cụ ghi nhớ vị trí của mỗi tệp và những gì nó cần giải nén để có được nó, nhưng có vẻ như rất ít người bận tâm với điều đó.

Nếu bạn muốn việc này diễn ra nhanh hơn, hãy thực hiện tar tzf file.tar.gz > filelist, mở danh sách tệp đó trong vim , gedit hoặc bất cứ điều gì, xóa các dòng tệp bạn không cần, lưu và sau đó giải nén chúng tar xzf file.tar.gz -T filelist -C extracted/.

Để có quyền truy cập ngẫu nhiên vào một tệp nén, bạn nên sử dụng zip có thể với các phần mở rộng posix, rar hoặc như dru8274 đã đề xuất, squashfs hoặc thậm chí ZFS với tính năng nén được bật hoặc btrfs nếu btrfs đã nén để hoạt động tại thời điểm đọc.

Điều này sẽ không bao gồm tất cả các trường hợp sử dụng vì nó hạn chế sử dụng đối với trình soạn thảo văn bản. Nhưng, nếu bạn chỉ quan tâm đến việc truy cập đọc, bạn có thể thấy điều này hữu ích cho một số tình huống. vim, khi chạy trên tarball sẽ hiển thị cho bạn cấu trúc phân cấp nội dung của kho lưu trữ (tương tự như cách nó sẽ hiển thị phân cấp tệp nếu chạy trên một thư mục). Bằng cách chọn một trong các tệp trong danh sách, nó sẽ mở tệp đã chọn trong bộ đệm chỉ đọc.

Một lần nữa, điều này không nhất thiết cung cấp quyền truy cập vào hình ảnh hoặc phương tiện khác, nhưng nếu tất cả những gì bạn cần là chỉ xem nội dung hoặc chỉ truy cập các tệp dựa trên văn bản, thì điều này sẽ hữu ích.

Lưu ý : điều này sẽ không hoạt động trên tất cả các định dạng lưu trữ.

Cách tiếp cận của tôi. Nếu bạn có đủ dung lượng đĩa trống trên ổ USB ngoài hoặc ổ cứng gắn ngoài / thứ cấp có đủ dung lượng, thì hãy xem xét việc giải nén tệp .tar.gz của bạn. Nghĩ rằng bạn có thể không muốn 3 triệu tệp trên đĩa hệ thống chính của mình, vì điều đó có thể làm mọi thứ chậm lại. Tôi khuyên rằng đĩa bên ngoài trong trường hợp này có một hệ thống tệp xử lý một số lượng lớn tệp dễ dàng: nghĩ ReiserFS, ext4 (với tùy chọn dir_index), XFS, có thể là BtrFS. Có thể mất 1-2 giờ để trích xuất, nhưng bạn có thể đi ăn trưa trong thời gian đó hoặc để nó chạy qua đêm; Khi bạn quay lại, việc truy cập các tệp được giải nén sẽ được thực hiện.