Hệ thống File Ext3 tùng được sử dụng rộng rãi nhất trong HĐH Linux trong nhiều năm. Trước sự gia tăng dung lượng của 0 cứng và đòi hỏi mang tính chất nghệ thuật, thế hệ tiếp sau hệ thống tập tin phiên bản 3 (Ext3), hệ thống tập tin
phiên bản 4 (Ext4), được phát minh vào năm 2006. Hệ thống tập tin mới này kết họp với khả năng mớ rộng và nâng cao hiệu suất giúp cho hệ thống tập tin rộng lớn hơn, trong khi đó vẫn duy trì được độ tin cậy và tính ổn định. Phiên bản 4 sẽ phù họp với khối lượng công việc lớn hơn, đa dạng hơn và được mong đợi đê thay thế phiên bản 3.
EXT4 được phát triển dựa trên fíle hệ thống Ext3. Trong các lần cải tiến Ext4 được cải tiến hơn nhiều so với Ext3 (được cải tiến từ Ext2 lên, chủ yếu thêm vào sự cập nhật nhật ký), nhưng Ext4 lại thay đồi cấu trúc dừ liệu của fíle hệ thống chang hạn như việc lưu trữ tập tin dữ liệu. Đã tạo ra tập tin hệ thống với cải tiến thiết kế, hiệu suất tốt hơn, độ tin cậy cao và nhiều các tính năng tiên tiến.
2.4.1 Giói thiệu
Phiên bản 3 từng là hệ thống tập tin Linux rất phổ biến bởi độ tin cậy cao, giàu tính năng thiết lập, hiệu suất tương đối tốt, và khả năng tương thích mạnh mẽ giữa các phiên bản. Thiết kế cứng nhắc của phiên bản 3 đã tòng mang lại danh tiếng là sự ôn định và mạnh mẽ, nhưng cũng hạn chê khả năng mở rộng quy mô và hoạt động trên các cấu hình lớn.
Với áp lực đòi hỏi dung lượng ổ cúng mới ngày càng lón và sự hồ trợ thay đối kích thước trực tuyến ở phiên bản 3, yêu cầu về giải quyết khả năng mở rộng và hiệu suất của phiên bản 3 là cấp bách hon bao giờ hết. Hiện nay, một trong các giới hạn tồn đọng phải đối mặt với phiên bản 3 là kích cỡ tối đa của tập tin hệ thống 16
TB. vào 28/6/2006, Theidore Ts'o, nhà duy trì EXT3, đã thông báo kế hoạch mới cho việc phát triển EXT4.
Một phiên bản phát triển của ext4 đã xuất hiện trong phiên bản kemel Linux 2.6.19. Ngày 11/10/2008, các bản vá lồi đánh dấu ext4 như mã ổn định, kết thúc của giai đoạn phát triến và giới thiệu ext4. Kemel 2.6.28, có chứa hệ thống tập tin ext4, cuối cùng đã được phát hành vào ngày 25/12/2008. Ngày 15/1/2010, Google tuyên bố sẽ nâng cấp cơ sở hạ tầng lưu trữ của nó tù' ext2 sang ext4. Ngày 14/12/2010 họ cũng thông báo họ sẽ sử dụng ext4, thay vì YAFFS, trên Android 2.3.
2.4.2 Khả năng nâng cấp mỏ’ rộng
Mục tiêu đầu tiên của phiên bản 4 là có thể trở thành một hệ thống tệp tin lớn hon. Trong phần này chúng tôi sê thảo luận về tính năng mở rộng luôn có sẵn ở phiên bản 4.
2.4.2.1 Hệ Thống Tệp Tin Lớn
Dung lượng 32 bit trong phiên bản 3 là nguyên nhân làm giới hạn kích thước hệ thống tập tin 16 TB hiện hành. Đe mở rộng giới hạn của hệ thống tệp tin, phương pháp đơn giản là tăng dung lượng bit được sử dụng đế đại diện cho số lượng khối và sau đó sửa chừa tất cả các tham chiếu cho các dừ liệu và các khối siêu dữ liệu.
Trước đây, phiên bản 3 có bản báo lỗi cấp độ 3 với khả năng hỗ trợ số lượng khối vật lý lên tới 48 bit. Ớ phiên bản 4, thay vì mở rộng số lượng khối lên đến 64 bit, người phát triển phiên bản 4 quyết định mở rộng bản đồ với số khối 48 bit. Cả hai điều này nhằm nâng cao năng lực của hệ thống tập tin và cải thiện độ lớn tập tin một cách hiệu quả. Với số khối 48 bit, phiên bản 4 có thể hỗ trợ hệ thống tập tin với kích thước tối đa lên đến 2(48+12) = 260 bytes (1 EB) với kích cờ khối 4 KB.
Sau khi thay đoi số lượng khối dữ liệu 48 bit, bước tiếp theo là chỉnh sửa cho chính xác các tham chiếu đến các khối siêu dữ liệu tuông ứng. Siêu dữ liệu tồn tại trong siêu khối, mô tả nhóm, và joumal. Các trường mới đã được thêm vào ở phần cuối của cấu trúc siêu khối đê lưu trữ 32 bit quan trọng nhất cho các biến block- counter, s íree blocks count, s blocks count, và s_r_blocks_count.
Ke từ khi địa chi các khối thay đôi trong hệ thống tập tin được đăng trên tạp chí, khối lóp nhật ký (JBD) cũng được yêu cầu để hồ trợ các địa chỉ khối ít nhất là 48 bit. Vì thế, JBD phân nhánh thành JBD2 đe hỗ trợ số khối hơn 32 bit, cùng lúc đó thì phiên bản 4 cũng được chia hai. Mặc dù hiện tại chỉ có phiên bản 4 là sử dụng JBD2, nó có thể cung cấp hồ trợ ghi lại nhật ký chung của cả hai hệ thống tập tin 32 bit và 64 bit.
Một câu hỏi đặt ra rằng tại sao chúng ta lại chọn 48 bit thay vì được hồ trợ 64 bit. Ở tốc độ hiện tại, một hệ thống tập tin 1EB sễ phải mất 119 năm đế hoàn thành một e2fsck đầy đủ và 65536 lần so với hệ thống tập tin 264 khối (64 ZB).
2.4.2.2 Đặc điểm
Sau khi mở rộng giới hạn được tạo ra bởi số khối 32-bit, dung lượng hệ thống tập tin vẫn còn bị hạn chế bởi số lượng của các nhóm khối trong hệ thống tập tin. Với 128 MB mặc định (227 byte) kích thước nhóm khối, ext4 có thề có ít nhất 227/64 = 221 nhóm khối. Điều này giới hạn toàn bộ kích thước hệ thống tập tin 221 * 227 = 248 byte hoặc 256TB.
Các giải pháp cho vấn đề này là sử dụng tính năng nhóm siêu khối (META_BG), có trong ext3 cho tất cả các phiên bản 2.6. Với tính năng METABG, hệ thống tập tin ext4 được phân chia thành nhiều nhóm siêu khối. Mỗi nhóm siêu khối là một cụm của các nhóm khối có nhóm cấu trúc mô tả có thể được lưu trữ trong một khối
ext4_exte nt_he ade r ext4_extent_idx eh_magic ei_block eh_entries eỉ_leaf eh_max ei leaf hi eh_depth eh_generation ei_unused Cấu trúc extent.
Như chúng ta đã thảo luận trước đó, trường khối vật lý trong cấu trúc extent chiếm 48 bit.
Một extent đơn có thể tượng trung cho 215 khối tiếp giáp hoặc 128Mb với 4Kb kích thước khối.
Bốn extent có thể được lưu trữ trong cấu trúc inode của ext4 một cách trực tiếp. Điều này nói chung là đủ đế đại diện cho các tập tin nhỏ hoặc tiếp giáp. Đối với các
tập tin lớn có độ phân tán cao hoặc thưa thớt , cần nhiều extent hơn. Trong trường họp này, cây extent có độ sâu ko đôi được sử dụng đế lun trữ ánh xạ của 1 file.
Ieaf nodes
Cách bố trí của cây extent.
Gốc của cây này được lưu trữ trong cấu trúc inode ext4 và extent được lưu trừ trong các nút lá của cây. Mồi nút trong cây bắt đầu với một tiêu đề extent, trong đó có số lượng các mục hợp lệ trong nút, khả năng các mục của nút có thể lun trừ, độ sâu của cây, và một số magic. Các số magic có the được sử dụng để phân biệt giữa các phiên bản khác nhau của extent, là những cải tiến mới được thực hiện các tính năng, chẳng hạn như tăng số khối ( block ) 64-bit.
2.4.2.4 Chong phân mảnh trực tuyến
Mặc dù kỹ thuật ghi trễ làm giảm độ phân mảnh nhưng sau một thời gian một hệ thống file lớn vẫn bị phân mảnh. Một công cụ xoá phân mảnh Online (e4defrag) được xây dựng đế xử lý việc đó. Có thề dùng công cụ này đế xoá phân
mảnh một file riêng rẽ hoặc cả hệ thống file. Công cụ này có thế chổng phân mảnh các tập tin cá nhân hoặc toàn bộ hệ thống tập tin. Đối với mỗi tập tin, công cụ này tạo ra một inode tạm thời và phân bổ các mức độ tiếp giáp với inode tạm thời sử dụng nhiều khối phân bổ. Sau đó nó sao chép các tập tin dữ liệu gốc vào bộ nhớ cache trang và xóa các trang bẩn để khối inode tạm thời. Cuối cùng, nó di chuyển khối con trỏ từ inode tạm thời cho các inode gốc.
2.4.2.5 Cải tiến độ tin cậy
Độ tin cậy là rất quan trọng đối với ext3 và là một trong những lý do khiến nó rất phổ biến. Vì vậy, các nhà phát triển ext4 đang đặt nhiều nồ lực vào việc duy trì độ tin cậy của định dạng tập tin trên. Có thề dễ dàng thiết kế định dạng tập tin ở 64-bits nhưng nó sẽ không được nhiều người dùng, vì thế giới công nghệ chưa cần dùng nhiều dung lượng đến mức như vậy.
Mặc dù đã sử dụng kỹ thuật lưu nhật ký (ịoumaling) và RAID, vẫn có những định dạng tập tin lỗi xuất hiện bên trong đĩa cứng. Dòng đầu tiên của vùng bảo vệ sẽ phát hiện và chủ động tránh lỗi bàng sự kết hợp của thiết kế siêu dữ liệu, bên trong có các phần thừa (re-dundancy) được tổ chức theo nhiều cấp độ, sê kiểm tra tổng thể tính toàn vẹn của dừ liệu. Neu xảy ra lồi thì dùng lệnh kiểm tra tính toàn vẹn (fsck) đề phát hiện và sửa chữa lại tập tin hệ thống.
Một trong nhũng mối quan tâm chính đối với tất cả các định dạng tập tin là tốc độ xác nhận và sửa lỗi lại tập tin sau khi nó bị lồi (corruption). Với dung lượng lưu trữ RAID ở mức họp lý, một lệnh fsck đầy đủ của định dạng tập tin ext3 dung lượng 2TB có thể mất từ 2 đến 4 giờ đế tạo ra một tập tin mới được coi là "sạch sẽ". Quá trình fsck sẽ tăng lên thành nhiều ngày nếu có một lượng lớn các khối tập tin được chia sẻ, sẽ cần trải qua nhiều quá trình để sửa chữa nó.
Một sổ đặc điểm, ví dụ phần mở rộng của định dạng tập tin, được gắn thẳng vào vùng siêu dừ liệu của ext4 đã được định nghĩa sẵn. Rất nhiều nhũng thay đổi, đang được xử lý, hoặc đang được thiết kế đổ chắc chắn ext4 sẽ trở thành định dạng hoàn hảo.
4.4.2.6 Đem số inode (index-node) chưa dùng và việc làm lệnh e2fsck nhanh hơnTrong lệnh e2fsck, việc kiểm tra các inode chưa dùng là tốn thời gian nhất của Trong lệnh e2fsck, việc kiểm tra các inode chưa dùng là tốn thời gian nhất của quá trình xử lý. Nó yêu cầu phải đọc tất cả các inode lớn của bảng inodc từ đĩa cứng, quét xem cái nào tồn tại, cái nào không tồn tại, hoặc cái inode nào chưa được
sử dụng, sau đó xác minh và cập nhật thành một khối bản đồ các bit (bitmaps) cổ định. Các nhóm và bảng inode chưa được phân tích sè được đánh dâu đặc diêm đê cho phép quá trình quét sẽ bỏ qua nó một cách an toàn. Việc này có thê làm quá trình e2fsck giảm còn từ 2 đến 20 phút, phụ thuộc vào nhiều hay ít tập tin cần xử lý. Đặc điểm này cùng có thể được dùng trong lệnh mke2fs hoặc tune2fs thông qua tùy chọn “-O uninit_group” gõ vào từ dòng lệnh.
Với đặc điểm này, bộ nhân (kernel) lưu trữ một số lượng các inode chưa được sử dụng, cất vào cuối mồi khối bảng inode. Ket quả là, e2fsck có the bỏ qua cả 2 quá trình đọc và quét các khối này từ đĩa cứng. Nó sẽ được gắn mặc định là khối các inode chưa sử dụng. Đe đảm bảo rằng các số inode chưa dùng là an toàn để lệnh e2fsck có thể sử dụng, nhóm các inode được định danh bằng kiểu kiếm tra CRC16 thêm vào bên trong, cho phcp tất cả các dừ liệu (tields) bên trong có thể xác minh lại.
Kiểu định dạng tập tin ext3 cơ bản chỉ sử dụng từ 1% đến 10% các inode của chúng, và phần lớn các inode được giừ cổ định ở phần đầu của bảng inode, nó có thế hủy bó quá trình xử lý các inode cố định này và tăng tốc nhờ bỏ qua một bước xử lý. Bộ nhân trung tâm (kemel) sẽ không tăng số lượng inode chưa dùng lên, nếu tập tin đã bị xóa đi. Bộ đếm này chỉ được cập nhật mỗi khi lệnh e2fsck chạy. Trong trường họp có rất nhiều khối inode đã bị xóa, lệnh e2fsck sẽ sắp xếp lại ở lần chạy tiếp theo.
Thời gianísck và số Inode
Tông sô inode (triệu)
■ ext3: 0 files o ext3 lOOk files ▼ ext3 2.1M íiles ▲ ext-ị lOOkỉiles ► ext-ị 2.1M ũles
Tốc độ của lệnh e2fsck tăng lên ứng với sổ khối inode chưa được phân tích.
Hình trên cho thấy với định dạng ext3 thì lệnh e2fsck tăng lên tỉ lệ thuận với tông số inode của định dạng tập tin, không ke đến số lượng inode đã được sử dụng. Ớ định dạng ext3, e2fsck mất cùng số thời gian xử lý 0 tập tin và 2,1 triệu tập tin. Ớ định dạng ext4, với sổ inode được đánh dấu rất nhiều, lệnh e2fsck chỉ phụ thuộc vào số inode đã được sử dụng. Như hình trên cho thấy, chỉ số fsck (giây) của định dạng
tập tin ext4 khoảng 100.000 tập tin chỉ bằng một phần nhỏ của định dạng ext3 cũng với 100.000 tập tin.
Ngoài việc có thế đếm các inode chưa được sử dụng, lệnh mke2fs và lệnh e2fsck còn có thể đánh dấu các khối nhóm inode hoặc bản đồ bít inode chưa được phân tích, vì thế nhân (kernel) không cần đọc chúng từ đĩa cứng ra khi cố định các nhóm với nhau. Tương tự, lệnh e2fsck không cần đọc các bản đồ bit này từ đĩa cứng, mặc dù nó cũng không đóng vài trò quan trọng trong việc tăng tốc bộ nhớ. Điều quan trọng nhất là lệnh mke2fs không ghi ra bản đồ bít hoặc bảng inode theo định dạng thời gian nếu gõ lệnh “mke2fs -O lazy_bg” như trước kia. Ghi bảng các inode có thể mất một khoảng thời gian nhất định.Và sẽ gây ra vấn đề với định dạng tập tin lớn do số lượng các trang lỗi được tạo ra trong một thời gian ngắn .
2.4.2.7Kiểm tra tổng thể (checksum)
Việc thêm siêu dữ liệu kiếm tra tông quát vào định dạng ext4 sẽ cho phép định dạng này dễ dàng phát hiện ra lỗi sai sót, và sẽ tự tìm cách sửa lỗi thích họp thay vì tin tưởng vào dừ liệu lấy từ đĩa cứng. Các mô tả của nhóm dừ liệu được thêm phần kiểm tra tổng thể vào trước mỗi đoạn (section) của nhóm. Tiếp theo, việc kiểm tra tổng thể phải kiểm tra Nhật ký (journal), bởi vì nó chứa mật độ cao các siêu dữ liệu quan trọng, và nó luôn luôn được ghi ra liên tục. Do đó các thay đổi hoặc lỗi ngẫu nhiên sê được phát hiện từ đây.
Những kiểm tra thong thể thêm vào nhật ký của định dạng ext4 là tương đối hoàn thiện. Trong định dạng ext3 và ext4, mỗi quá trình trao đôi dữ liệu lưu trong nhật ký có cấu trúc gồm một khối mở đầu và một khối chứa dừ liệu. Trong suốt quá trình tiến hành ghi nhật ký, khối chứa dữ liệu sẽ không được gửi đến đĩa cứng cho đến khi khối mở đầu và cả khối siêu dữ liệu được mô tả đầy đủ, sau đó tất cả được ghi vào đĩa cứng. Quá trình trao đổi dừ liệu tiếp theo cần đợi cho đến khi khối dừ liệu trước đó được ghi vào hoàn toàn đĩa, và nó bắt đầu có thế dùng đê chỉnh sửa định dạng tập tin.
Với 2 quá trình lun tập tin riêng biệt, nếu khối chứa dừ liệu tập tin bị trùng sổ thứ tự với khối mở đầu tập tin, thì nó sẽ ra hiệu cho quá trình trao đổi dữ liệu làm lại vào lúc khôi phục tập tin. Neu như cả 2 không khớp nhau, quá trình khôi phục nhật ký kết thúc. Tập tin đã bị lỗi. Tuy nhiên thực tế có nhiều nguyên nhân dẫn đến tập tin bị lỗi định dạng. Với kiêu kiêm tra tông thê nhật ký, nhật ký tính toán dựa theo mã CRC32 trên tất cả các khối trong quá trình trao đôi dữ liệu (bao gồm cả khối mở đầu), và
việc kiểm tra tổng thể được ghi vào khối chứa dữ liệu của quá trình trao đối. Neu việc kiếm tra tông thê không khóp với nhật ký lưu tập tin, tức là có dầu hiệu của một hoặc