Tăng trưởng đơn điệu của kích thước / khối lượng thư mục Linux

8

Trên Linux, (có lẽ là một chức năng của kích thước khối hệ thống tệp), khi tôi tạo một thư mục và statnó, nó trả về kích thước 4096. Tôi có thể tạo các tệp trong thư mục này, lên đến một điểm, mà không làm tăng kích thước nhận biết của thư mục (như báo cáo của stat).

Tại một số điểm, khi thư mục chứa đầy các tệp, bong bóng kích thước thư mục (Tôi không nói về nội dung của thư mục, tôi đang nói về các khối được sử dụng để đại diện cho chính thư mục). Nếu các tập tin bị xóa, kích thước thư mục vẫn giữ nguyên.

Đây là một ví dụ nhanh:

[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400

Sau đó chạm vào một loạt các tập tin:

[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400

Sau đó xóa các tập tin:

[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
  File: `test'
  Size: 155648          Blocks: 312        IO Block: 4096   directory
Device: fd00h/64768d    Inode: 1396685     Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400

Câu hỏi của tôi là:

Tại sao số lượng kích thước / khối của một thư mục tăng đơn điệu?
Đây có phải là một chức năng của hệ thống tập tin cơ bản hoặc Linux VFS?
Có thể giảm kích thước thư mục mà không cần xóa và tạo lại thư mục?
Điểm thưởng: Chỉ cho tôi mã nguồn hạt nhân nơi thực hiện hành vi này.

linux inode vfs

— vòng lặp
nguồn

Không thực sự chắc chắn tại sao điều này được bỏ phiếu. Đây là những câu hỏi hợp pháp, được thể hiện rõ ràng với các lệnh được đưa ra để tái tạo kịch bản. Các câu trả lời cho những câu hỏi này sẽ đáp ứng kiến thức cộng đồng và sẽ hữu ích khi được ghi lại ở đâu đó.

— loopForver

9

Dưới đây là câu trả lời đúng cho ext2 / ext3 / ext4. Nếu chúng đúng với các hệ thống tập tin khác phụ thuộc vào việc thực hiện chúng.

user48838 đã trả lời đúng. Nhiều tệp tiêu thụ nhiều dữ liệu meta hơn. Chúng được phân bổ theo khối 4k hoặc ở bất kỳ kích thước nào khác được xác định tại thời điểm tạo hệ thống tệp
Có, đó là một tính năng / vấn đề của hệ thống tập tin thực
Trong một hệ thống tập tin ext3, điều này là không thể. Chỉ bằng cách tạo lại thư mục (trống)
Mã nguồn ở quanh đây và trong các tập tin liên quan

Nhưng bạn có may mắn. Khi bạn tạo lại cùng số lượng tệp bạn đã xóa, kích thước thư mục sẽ giữ nguyên. Chỉ khi bạn thêm nhiều tập tin, nó sẽ tăng lên.

— mailq
nguồn

1

Một điều: "e2fsck -fD" nên thu gọn mọi thư mục trong hệ thống tập tin ext2 / 3. Điều này có thể làm những gì OP mong muốn, mặc dù tôi nghi ngờ nó chậm và hệ thống tập tin phải ngoại tuyến. Điều này có thể mất nhiều thời gian hơn so với việc liên kết mọi tệp trong một thư mục mới và xóa những cái cũ.

— akramer

4

Sự gia tăng khối mà bạn đang thấy là do cách hệ thống tệp quản lý lưu trữ tệp và thông tin quản lý tệp có liên quan. Trong tình huống được mô tả của bạn, điều đó sẽ xuất hiện theo mức tăng của 4K, vì vậy mỗi mục nhập "mới" / "duy nhất" vào hệ thống tệp sẽ dự trữ 4K, cho dù kích thước dữ liệu thực tế có lấp đầy toàn bộ 4K hay không. Nếu dữ liệu liên quan chiếm toàn bộ 4K, thì một khối 4K khác được bảo lưu và điền vào khi cần để lưu trữ toàn bộ luồng / chuỗi dữ liệu liên quan.

Tùy thuộc vào việc xóa "cứng" so với "mềm" do hệ thống tệp quản lý, việc xóa có thể không (thường không phải là chức năng "không phục hồi") ngay lập tức giải phóng (các) khối được bảo lưu. Một số hệ thống tệp có thể phân biệt các loại "xóa" khác nhau và cung cấp khả năng quản lý khối lưu trữ tương ứng.

Cách quản lý lưu trữ được tiếp cận và triển khai khác nhau như thế nào bởi các hệ thống tệp, do đó, trong các HĐH hỗ trợ nhiều hệ thống tệp / mô-đun, HĐH thường sẽ chỉ cung cấp "móc" cho hệ thống tệp để tích hợp vào.

— người dùng48838
nguồn

1

Thêm một số bình luận lan man vào câu trả lời hay của user48838:

Tất cả mọi thứ là một tập tin, bao gồm các thư mục. Để lưu trữ tất cả thông tin tập tin đó, bạn cần không gian.

Nó cũng có giá trị để hiển thị, '64B đã sử dụng' cho một thư mục nhỏ và thực sự hiển thị dung lượng được sử dụng, nhưng chúng tôi sẽ sử dụng nhiều 4K trên đĩa, vì vậy, đó là quyết định thiết kế chỉ hiển thị lượng không gian sử dụng.

Từ quan điểm thiết kế của FS, tại sao bạn lại phải trải qua những rắc rối khi tính toán những gì đã được sử dụng? Không cần thiết. Và sau đó bạn sẽ phải di chuyển các mục để tránh để lại lỗ hổng ick.

Khi xóa xảy ra và kích thước thư mục giảm xuống để bạn có thể giải phóng một khối, tất cả sự quản lý đó sẽ cần phải xảy ra trước khi bạn thực sự có thể làm như vậy. Tại sao phải tiết kiệm một vài KB? Những điều lạ lùng là bạn sẽ phải mở rộng nó sau này.

Còn lại như một bài tập cho người đọc: Hãy suy nghĩ về lý do tại sao thư mục / mất + tìm thấy của bạn được tạo trống nhưng chiếm 16K (ít nhất là trên ext3).

— MikeyB
nguồn