Tại sao các tệp này trong một khối lượng ext4 bị phân mảnh?


19

Tôi có một ext4phân vùng 900GB trên ổ cứng (từ tính) không có khiếm khuyết và không có thành phần xấu. Phân vùng hoàn toàn trống ngoại trừ một lost+foundthư mục trống . Phân vùng được định dạng bằng các tham số mặc định ngoại trừ việc tôi đặt số khối hệ thống tệp dành riêng là 1%.

Tôi đã tải xuống tệp ~ 900 MB xubuntu-15.04-desktop-amd64.isovào thư mục điểm gắn kết của phân vùng bằng cách sử dụng wget. Khi quá trình tải xuống hoàn tất, tôi thấy rằng tệp được chia thành bốn mảnh:

filefrag -v /media/emma/red/xubuntu-15.04-desktop-amd64.iso
Filesystem type is: ef53
File size of /media/emma/red/xubuntu-15.04-desktop-amd64.iso is 1009778688 (246528 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  190463:     198656..    229375:  30720:            
   6:   190464..  223231:     231424..    264191:  32768:     229376:
   7:   223232..  246527:     264192..    287487:  23296:             eof
/media/emma/red/xubuntu-15.04-desktop-amd64.iso: 4 extents found

Nghĩ rằng điều này có thể được giải quyết wgetbằng cách nào đó, tôi đã xóa tệp ISO khỏi phân vùng, làm cho nó trống trở lại, sau đó tôi sao chép tệp ~ 700MB v1.mp4vào phân vùng bằng cách sử dụng cp. Tập tin này đã bị phân mảnh quá. Nó được chia thành ba mảnh:

filefrag -v /media/emma/red/v1.mp4
Filesystem type is: ef53
File size of /media/emma/red/v1.mp4 is 737904458 (180153 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..   32767:      34816..     67583:  32768:            
   1:    32768..   63487:      67584..     98303:  30720:            
   2:    63488..   96255:     100352..    133119:  32768:      98304:
   3:    96256..  126975:     133120..    163839:  30720:            
   4:   126976..  159743:     165888..    198655:  32768:     163840:
   5:   159744..  180152:     198656..    219064:  20409:             eof
/media/emma/red/v1.mp4: 3 extents found

Tại sao chuyện này đang xảy ra? Và có cách nào để ngăn chặn nó xảy ra? Tôi nghĩ rằng ext4nó có nghĩa là để chống lại sự phân mảnh. Thay vào đó tôi thấy rằng nó ngay lập tức phân đoạn một tập tin đơn độc khi tất cả phần còn lại của âm lượng không được sử dụng. Điều này dường như tồi tệ hơn cả FAT32NTFS.


4
Tôi đang cố gắng tưởng tượng trong hoàn cảnh nào điều này có thể có thể quan trọng, và tôi đang trở nên trống rỗng.
Greg Hewgill

4
@GregHewgill: Nó quan trọng vì tôi nghĩ đó là bất thường. Bây giờ tôi biết rằng đó là bình thường, nó không thành vấn đề.
EmmaV

Câu trả lời:


17

3 hoặc 4 đoạn trong một tệp 900mb rất tốt. Phân mảnh trở thành một vấn đề khi một tệp có kích thước đó có nhiều hơn 100 mảnh. Không có gì lạ khi chất béo hoặc ntfs phân chia một tệp như vậy thành hàng trăm mảnh.

Nhìn chung, bạn sẽ không thấy tốt hơn ít nhất là trên các hệ thống tệp ext4 cũ hơn vì kích thước tối đa của nhóm khối là 128 MB và do đó, cứ 128 MB, không gian liền kề bị phá vỡ bởi một vài khối cho bitmap phân bổ và bảng inode cho nhóm khối tiếp theo. Một tính năng ext4 gần đây được gọi là flex_bg cho phép đóng gói một số bảng (thường là 16) của các nhóm khối này với nhau, để lại các khối phân bổ dài hơn nhưng tùy thuộc vào phân phối của bạn và phiên bản e2fspross nào được sử dụng để định dạng nó, tùy chọn này có thể chưa được sử dụng

Bạn có thể sử dụng tune2fs -lđể kiểm tra các tính năng được bật khi hệ thống tệp của bạn được định dạng.


Rất thú vị. Tôi giả sử tất cả các bảng inode, vv là lúc bắt đầu âm lượng.
EmmaV

1
@EmmaV phân phối chúng trên đĩa, tương đối gần với dữ liệu họ đề cập đến, kết quả là tìm kiếm ngắn hơn và truy cập đĩa nhanh hơn :)
hobbs 18/05/2015

10

Tôi thực sự không thể trả lời nhưng tôi nghĩ điều này có thể giúp:

Lưu ý rằng mỗi mảnh có kích thước tối đa 32768 khối (sức mạnh bằng 2, sẽ giơ cờ rằng có gì đó đang diễn ra, đồng thời cung cấp cho bạn một gợi ý cho thứ gì đó cần tìm).

Cũng đáng chú ý, những độ lệch vật lý giữa các phạm vi khá gần nhau.

Từ: Bố cục đĩa Ext4

Một hệ thống tệp ext4 được chia thành một loạt các nhóm khối. Để giảm bớt khó khăn về hiệu suất do phân mảnh, bộ cấp phát khối cố gắng hết sức để giữ các khối của mỗi tệp trong cùng một nhóm, do đó giảm thời gian tìm kiếm. Kích thước của một nhóm khối được chỉ định trong sb.s_blocks_per_group blocks, mặc dù nó cũng có thể được tính là 8 * block_size_in_bytes. Với kích thước khối mặc định là 4KiB, mỗi nhóm sẽ chứa 32.768 khối, với chiều dài 128MiB

Và tiếp tục xuống:

Công cụ đầu tiên mà ext4 sử dụng để chống phân mảnh là bộ cấp phát đa khối. Khi một tệp được tạo lần đầu tiên, bộ cấp phát khối sẽ phân bổ một cách đặc biệt 8KiB dung lượng đĩa cho tệp [...] Một thủ thuật liên quan thứ hai mà ext4 sử dụng là cấp phát chậm. Theo sơ đồ này, khi một tệp cần nhiều khối hơn để hấp thụ ghi tệp, hệ thống tệp sẽ quyết định vị trí chính xác trên đĩa cho đến khi tất cả các bộ đệm bẩn được ghi ra đĩa. Bằng cách không cam kết với một vị trí cụ thể cho đến khi thật cần thiết (hết thời gian cam kết hoặc đồng bộ hóa () được gọi hoặc kernel hết bộ nhớ), hy vọng rằng hệ thống tệp có thể đưa ra quyết định vị trí tốt hơn.

Vì vậy, tôi muốn nói rằng người cấp phát chỉ quan tâm đến địa phương dữ liệu trong nhóm khối (các khối 32K đó), chứ không phải về các nhóm khối tiếp giáp nhau.


Câu nói đầu tiên bạn đã trả lời câu hỏi của tôi.
EmmaV

1
Mỗi phạm vi có tối đa 32k khối vì đó là độ dài tối đa mà một mô tả phạm vi có thể bao gồm. Phạm vi không phải là những mảnh vỡ. Nếu bạn nhận thấy một số khối vật lý của phạm vi ngay lập tức tuân theo các khối ở phạm vi trước đó và do đó không tạo thành một đoạn (6 phạm vi so với 3 đoạn).
psusi
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.