Dung lượng 32 bit trong phiển bản 3 là nguyên nhân làm giới hạn kich thước hệ thống tập tin 16 TB hiện hành. Để 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
59 trang |
Chia sẻ: lvcdongnoi | Lượt xem: 5981 | Lượt tải: 3
Bạn đang xem trước 20 trang tài liệu Tiểu luận Cấu trúc hệ thống file ext2,ext3, ext4 trong họ linux, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ổ sung giới hạn tên tập tin dài nhất là 255 ký tự, cho phép một byte được phục hồi.
inode
Giá trị 32 bit cho biết số inode của file-entry. Entry không được dùng thì giá trị này là 0.
rec_len
Giá trị 16 bit không dấu cho biết sự thay thế directory-entry kế tiếp bắt đầu từ directory-entry hiện hành.
name_len
Giá trị 8 bit không dấu cho biết tên chứa bao nhiêu ký tự.
file_type
Giá trị 8 bit không dấu dùng để xác định kiểu tập tin. Lưu ý, giá trị này có thể là 0 trong sự bổ sung trước đó. Giá trị được xác định hiện tại là:
Table 2-1. Bảng giá trị của EXT2_FT
EXT2_FT_UNKNOWN
0
Chưa dùng
EXT2_FT_REG_FILE
1
File bình thường
EXT2_FT_DIR
2
Thư mục
EXT2_FT_CHRDEV
3
Thiết bị ký tự
EXT2_FT_BLKDEV
4
Thiết bị khối
EXT2_FT_FIFO
5
Buffer
EXT2_FT_SOCK
6
Socker
EXT2_FT_SYMLINK
7
Liên kết
EXT2_FT_MAX
8
name
Tên của file-entry. Các ký tự cho phép thuộc ISO-Latin-1.
2.2.3.2 Ví dụ về Directory
Sau đây là một ví dụ về một thư mục của một user trên hệ thống của tôi.
$ ls -1a /home/eks
.
..
.bash_profile
.bashrc
mbox
public_html
tmp
Sự miêu tả dữ liệu sau có thể được tìm thấy trên thiết bị lưu trữ:
Figure 2-2. Sự bố trí dữ liệu trong thư mục ví dụ
offset size description
------- ------- -----------
0 4 inode number (783362)
4 2 record length (9)
6 1 name length (1)
7 1 file type (EXT2_FT_DIR)
8 1 name (.)
9 4 inode number (1109761)
13 2 record length (10)
15 1 name length (2)
16 1 file type (EXT2_FT_DIR)
17 2 name (..)
19 4 inode number (783364)
23 2 record length (21)
25 1 name length (13)
26 1 file type (EXT2_FT_REG_FILE)
27 13 name (.bash_profile)
40 4 inode number (783363)
44 2 record length (15)
46 1 name length (7)
47 1 file type (EXT2_FT_REG_FILE)
48 7 name (.bashrc)
55 4 inode number (783377)
59 2 record length (12)
61 1 name length (4)
62 1 file type (EXT2_FT_REG_FILE)
63 4 name (mbox)
67 4 inode number (783545)
71 2 record length (19)
73 1 name length (11)
74 1 file type (EXT2_FT_DIR)
75 11 name (public_html)
86 4 inode number (669354)
90 2 record length (11)
92 1 name length (3)
93 1 file type (EXT2_FT_DIR)
94 3 name (tmp)
97 4 inode number (0)
101 2 record length (3999)
103 1 name length (0)
104 1 file type (EXT2_FT_UNKNOWN)
105 0 name ()
Cần lưu ý rằng một vài sự bổ sung sẽ đệm thêm các directory-entry để có những hiệu quả tốt hơn trong việc xử lý chính, vì vậy rất quan trọng khi sử dụng record length và không sử dụng name length để tìm record tiếp theo.
2.2.3.4 Indexed Directory Format
Việc dùng chuẩn liên kết danh sách định dạng thư mục có thể trở nên chậm khi mà số lượng tập tin bắt đầu tăng. Để tăng hiệu quả cho một hệ thống như vậy, một mảng băm được tạo ra cho phép nhanh chóng định vị tập tin cụ thể được tìm kiếm.
Bit EXT2_INDEX_FL trong cờ hiệu điều khiển thao tác (behaviour control flags) được thiết lập nếu indexed directory format được sử dụng.
Cấu trúc Index
Gốc của cây Index nằm ở block 0 của tập tin. Khoảng trống được dữ trữ cho cấp độ 2 của cây index trong block 1 đến 511 (block hệ thống tập tin 4KB). Block thư mục lá đươc gắn vào bắt đầu tại block 512, vì vậy đoạn cuối của thư mục trông giống như một thư mục Ext2 thông thường và có thể được xử lý một cách trực tiếp bởi trường ext2_readdir. Đối với các thư mục ít hơn 90KB có lỗ chạy từ block 1 đến 511, vì vậy một thư mục rỗng có hai block trong nó, mặc dù kích thước của nó xuất hiện khoảng 2MB trong một danh sách thư mục. Một thư mục trông như sau:
0: Root index block
1: Index block/0
2: Index block/0
...
511: Index block/0
512: Dirent block
513: Dirent block
...
Mỗi index block bao gồm 512 index entry:
hash, block
trong đó hash là một hash 32 bit với một cờ hiệu xung đột trong bit có ý nghĩa ít nhất của nó, và block là số block luận lý của một index của block lá, phụ thuộc vào cấp độ của cây.
Giá trị hash của index entry 0 không cần thiết bởi vì cấp độ của cây sẽ tạo ra nó, do đó nó được dùng để ghi việc tính các index entry trong một index block.
Block index gốc có định dạng giống như các block index khác, với 8 byte đầu tiên của nó dữ trữ một tiêu đề nhỏ:
1 byte header length (default: 8)
1 byte index type (default: 0)
1 byte hash version (default:0)
1 byte tree depth (default: 1)
Cách xử lý của header khác với bản đắp vá kèm theo một cách không đáng kể. Nói riêng, chỉ một cấp độ đơn của cây index (root) được bổ sung ở đây. Điều này trở nên đủ để điều khiển nhiều hơn 90,000 entry, vì vậy hiện nay nó cũng đủ. Khi một cấp độ 2 được thêm vào cây, khả năng này sẽ tăng lên đến khoảng 50 triệu entry, và không có gì ngăn ngừa việc dùng cấp độ thứ n.
Thuật toán tìm kiếm (Lookup Algorithm)
- Tính toán một hash của tên
- Đọc index gốc
- Dùng tìm kiếm nhị phân để tìm index đầu tiên hoặc block lá có thể chứa hash đích (trong trật tự cây)
- Lập lại bước trên cho đến khi đạt được cấp độ thấp nhất của cây.
- Đọc block entry của thư mục lá và thực hiện tìm kiếm Ext2 thông thường trên nó.
- Nếu tên được tìm thấy, trả về buffer và directory-entry của nó.
- Ngược lại, nếu bit xung đột của directory-entry tiếp theo được thiết lập, tiếp tục tìm kiếm trên block đã thành công.
Thuật toán chèn (Insert Algorithm)
Chèn vào các entry mới vào trong thư mục phức tạp hơn là tìm kiếm, vì cần phải tách các block lá khi chúng đầy, và thỏa mãm điều kiện là cho phép những xung đột khóa hash được điều khiển một cách chắc chắn và có hiệu quả. Tôi xin tóm tắt như sau:
- Dò index như là tìm kiếm.
- Nếu block lá đích đầy, chia nhỏ nó và ghi nhớ block sẽ nhận entry mới.
- Chèn thêm entry mới trong block lá sử dụng mã chèn directiry-entry Ext2 thông thường.
Tách (Splitting)
Tóm lại, khi một nút lá đầy và chúng ta muốn đặt một entry mới vào đó thì lá sẽ bị tách ra, và một phần khoảng trống hash của nó được chia thành nhiều phần. Cách dễ nhất để làm được điều này là sắp xếp các entry theo giá trị hash và cắt ở phần giữa của danh sách đã được sắp xếp. Thao tác này là log(number_of_entries_in_leaf) và không mất nhiều chi phí với điều kiện sử dụng thuật toán sắp xếp có hiệu quả. Tôi dùng CombSort cho việc này, mặc dù QuickSort cũng tốt cho trường hợp này bởi vì sự thực thi trường hợp trung bình quan trọng hơn trường hợp tệ nhất.
Một phương pháp khác là dự đoán một giá trị trung bình cho khóa hash, và việc chia phần có thể được làm theo thời gian tuyến tình, nhưng kết quả việc phân chia kém hơn khoảng trống khóa hash có giá trị hơn thuận lợi ít ỏi của thuật toán phân chia tuyến tính. Trong trường hợp bất kỳ, số entry cần sắp xếp được giới hạn bởi số lượng vừa khít trong một lá.
Các xung đột khóa (Key Collisions)
Việc điều khiển những chuỗi xung đột khóa hash có một vài phức tạp. Thật là tuyệt nếu tránh việc tách các chuỗi như vậy giữa các block, vì vậy điểm cắt của một block được điều chỉnh với cái này. Nhưng khả năng vẫn còn nếu block lắp đầy bởi các entry được băm một cách xác định, chuỗi có thể vẫn phải bị tách. Tình huống này được đánh dấu bằng cách đặt một số 1 vào bit bên dưới của entry index trỏ vào block kế thừa, cái mà được làm sáng tỏ một cách tự nhiên bởi sự thăm dò index như là một giá trị trung gian mà không có bất kỳ sự mã hóa đặc biệt nào. Vì vậy, việc điều khiển vấn đề xung đột bắt buộc không có xử lý thực sự, chỉ có mã mở rộng và và sự giảm bớt không đáng kể khoảng trống của khóa băm. Khoảng trống của khóa băm vẫn còn đủ cho số directory-entry có thể tưởng tượng được, lên đến hàng tỷ.
Hàm băm (Hash Function)
Các đặc tính chính xác của hàm Hash rất ảnh hưởng đến việc thực thi chiến lược index này. Một hàm hash dở sẽ dẫn đến nhiều sự xung đột hoặc sự phân chia khoảng trống hash dở. Để minh họa tại sao cái sau lại là một vấn đề, xét xem cái gì sẽ xảy ra khi một block được tách ra để mà nó bao phủ một vài giá trị hash nhất định. Xác suất các entry index sau đó cũng được băm tương tự, khoảng cách càng nhỏ thì giá trị này càng nhỏ. Thực tế, khi một block được tách ra, nếu khoảng trống hash của nó quá nhỏ đến nỗi chỉ luôn đầy có một nửa, đó là một kết quả mà tôi quan sát ở thực tế.
Sau một số thử nghiệm, tôi đã có một hàm Hash cho ra một sự phân tán hợp lý các khóa hash dọc theo toàn bộ khoảng trống khóa 31 bit. Điều này làm tăng sự đầy trung bình của các block lá, đạt gần tới giá trị trung bình theo lý thuyết là đầy ¾.
Nhưng hàm hash hiện tại chỉ để dùng tạm, chờ một phiên bản tốt hơn dựa trên lý thuyết chắc chắn.
Sự thực thi (Performance)
Tóm lại, sự cải tiến khả năng thực thi trên Ext2 thông thường đã gây một sự bất ngờ. Với việc thực thi các thư mục rất nhỏ giống với Ext2 chuẩn, nhưng vì kích thước thư mục tăng theo Ext2 chuẩn một cách nhanh chóng làm xuất hiện bậc hai, trong khi htree-enhanced Ext2 tiếp tục lấy tỉ lệ một cách tuyến tính.
Uli Luckas chạy điểm chuẩn cho việc tạo tập tin theo các kích thước khác nhau của thư mục nằm trong dãy từ 10,000 đến 90,000 tập tin. Kết quả này rất hài lòng: toàn bộ thời gian tạo file gần như tuyến tính, chống lại việc tăng bậc hai của Ext2 thường.
Thời gian được tạo như sau:
Figure 2-3. Việc thực thi Indexed Directories
Indexed Normal
======= ======
10000 Files: 0m1.350s 0m23.670s
20000 Files: 0m2.720s 1m20.470s
30000 Files: 0m4.330s 3m9.320s
40000 Files: 0m5.890s 5m48.750s
50000 Files: 0m7.040s 9m31.270s
60000 Files: 0m8.610s 13m52.250s
70000 Files: 0m9.980s 19m24.070s
80000 Files: 0m12.060s 25m36.730s
90000 Files: 0m13.400s 33m18.550s
Các thư mục dễ dàng vừa khít bộ nhớ đệm, và thừa số giới hạn trong trường hợp Ext2 chuẩn là việc tìm các block directory trong bộ nhớ đệm buffer, và việc quét cấp độ thấp các entry directory. Trong trường hợp lập chỉ mục htree, thì số chi phí cần được xem xét, tất cả chúng hầu như được giới hạn. Có một vài cách tối ưu cần phải thực hiện:
- Dùng tìm kiếm bằng nhị phân thay vì tìm kiếm tuyến tính trong các nút chỉ thị ở phía trong.
- Nếu chỉ có một block lá trong một thư mục, thì bỏ qua việc dò chỉ mục, đi thẳng đến block luôn.
- Ánh xạ thư mục vào trang cache thay vì vào cache bộ nhớ đệm trung gian.
Mỗi sự tối ưu này sẽ tạo ra một hiệu quả được cải thiện, nhưng không có gì giống như bước nhảy lớn từ N*2 đến Log512(N), ~=N. Trong lúc những tối ưu đó được áp dụng và chúng ta có thể tìm thấy một hiệu quả gấp đôi khác hay tương tự như vậy.
Đó là một hiệu quả không đáng kể khi mà thư mục đủ lớn để cần một level cấp 2 vì bộ lưu trữ sẽ rất nhỏ. Việc đi ngang qua các block dữ liệu của thư mục sẽ là một chi phí rất lớn, và một lần nữa, giá trị này có thể tăng lên bởi việc di chuyển các block vào trang cache.
Điển hình chúng ta sẽ đi qua 3 block để đọc hay viết một entry thư mục, và số đó tăng đến khoảng 4-5 với những thư mục lớn. Nhưng thực sự thì không có gì so sánh với Ext2 thông thường cái mà đi qua vài trăm block trong tình huống tương tự.
2.2.4 Inodes, File Identifiers
Mỗi tập tin, thư mục, tập tin liên kết, thiết bị, hoặc bất cứ cái gì khác đều được lưu trữ trong hệ thống tập tin Ext2, được xác định bởi một inode. Nếu bạn biết số inode của tập tin bạn muốn đọc, thậm chí là không biết đường dẫn đến file đó hay tên file đó, bạn vẫn có thể xác định vị trí file đó trên đĩa và đọc nó.
2.2.4.1 Inode Number
Số inode (inode number) là một chỉ mục trong bảng inode (inode table) đến một cấu trúc inode (inode structure). Kích thước của inode table cố định trong thời gian định dạng, nó được tạo ra để giữ số entry lớn nhất. Vì dự trữ khối lượng đủ lớn các entry, bảng inode khá lớn và do đó, nó bị tách theo tỉ lệ bằng nhau giữa tất cả các block group.
2.4.2 Định vị cấu trúc của Inode
Trường s_inodes_per_group trong cấu trúc superblock cho chúng ta biết có bao nhiêu inode trên một block broup. Inode 1 là inode đầu tiên xác định trong bảng inodek, có thể dùng những công thức sau:
group = (inode - 1) / s_inodes_per_group
để định vị block group nào nắm giữ một phần bảng inode chứa entry inode được tìm kiếm, và:
index = (inode - 1) % s_inodes_per_group
để có được chỉ mục của một phần bảng inode này với entry inode được tìm kiếm. Sau đây là hai ví dụ được dùng để kiểm tra sự thực thi của bạn:
Figure 3-1. Ví dụ về sự tính toán inode
s_inodes_per_group = 1712
inode number computation
------------ -----------
1 group = (1 - 1) / 1712 = 0
index = (1 - 1) % 1712 = 0
2 group = (2 - 1) / 1712 = 0
index = (2 - 1) % 1712 = 1
963 group = (963 - 1) / 1712 = 0
index = (963 - 1) % 1712 = 962
1712 group = (1712 - 1) / 1712 = 0
index = (1712 - 1) % 1712 = 1711
1713 group = (1713 - 1) / 1712 = 1
index = (1713 - 1) % 1712 = 0
3424 group = (3424 - 1) / 1712 = 1
index = (3424 - 1) % 1712 = 1711
3425 group = (3425 - 1) / 1712 = 2
index = (3425 - 1) % 1712 = 0
Chỉ mục 0 (index = 0) là entry đầu tiên. Kết quả hơn 1 là cái có thể dễ dàng được tăng lên nhiều lần bởi kích thước của cấu trúc để tìm kiếm offset cuối cùng trong đường dẫn của nó trong bộ nhớ hoặc trên đĩa.
2.2.4.3 Định vị Inode Table
Như được giới thiệu trong phần 3.1, bảng inode được tách bằng nhau giữa tất cả block group. Nếu một hệ thống tập tin được tạo cho phép một ngàn inode, cắt giữa 5 group, có 200 inode trên một phần của bảng inode. Figure 3-1 minh họa sự phân phối tương tự như thế.
Mỗi phần của bảng inode có thể được định vị bằng việc dùng trường bg_inode_table của cấu trúc group_descriptor của các block group tương ứng.\
2.2.5 Các Thuộc Tính Của File
Hầu hết các thuộc tính của file (cũng như directory, symbol link, thiết bị…) được định vị trong inode tương thích với tập tin. Một vài thuộc tính khác chỉ có ở các thuộc tính mở rộng.
2.2.5.1 Các thuộc tính chuẩn
SUID, SGID và -rwxrwxrwx
Chúng được định vị với các bit SGID và SUID trong ext2_inode.i_mode.
Kích thước File
Kích thước của file có thể được xác định tại trường ext2_inode.i_size.
Owner và Group
Dưới hầu hết sự bổ sung, owner và group là các giá trị 16 bit, nhưng trong một vài sự bổ sung của Linux và Hurd gần đây thì id của owner và group là 32 bit. Khi sử dụng các giá trị 16 bit, chỉ có những phần “thấp” (low) được dùng hợp lệ, trong khi sử dụng giá trị 32 bit, cả hai phần cao và thấp đều được dùng, phần cao được đẩy sang trái tới 16 khoảng cách sau đó thêm vào phần thấp.
Chỉ phần thấp của owner và group được định vị tương ứng trong ext2_inode.i_uid và ext2_inode.i_gid.
Phần thấp của owner và group được định vị trong ext2_inode.osd.hurd.h_i_gid_high và ext2_inode.osd2.hurd.h_i_uid_high một cách tương ứng đối với Hurd, và định vị tương ứng trong các trường ext2_inode.osd2.linux.l_i_uid_high và ext2.osd2.linux.l_gid_high đối với Linux.
2.2.5.2 Các thuộc tính mở rộng
Các thuộc tính mở rộng cặp name:valua kết hợp cố định giữa các file và directory, tương tự như chuỗi môi trường kết hợp với một tiến trình (process). Một thuộc tính có thể được xác định hoặc không xác định. Nếu được xác định, giá trị của nó có thể rỗng hoặc không rỗng.
Các thuộc tính mở rộng là sự mở rộng các thuộc tính thông thường cái mà được kết hợp tất cả các inode trong hệ thống. Chúng thường được dùng để cung cấp thêm các chức năng vào một hệ thống – chẳng hạn như thêm vào các đặc tính bảo mật như là Access Control Lists (ACLs) có thể được bổ sung bằng cách dùng các thuộc tính mở rộng.
Các thuộc tính mở rộng được truy xuất như các đối tượng nguyên tử. Việc đọc gọi ra tất cả giá trị của một thuộc tính và lưu trữ nó trong bộ nhớ trung gian. Việc ghi thay đổi giá trị phía trước bất kỳ bằng giá trị mới.
Trong mỗi inode ext2, chúng ta có trường i_file_acl, dành cho Access Control Lists. Trường này được dùng để lưu trữ số block thay vì lưu trữ các thuộc tính mở rộng của một inode.
Các thuộc tính mở rộng lưu trữ trên block đĩa “trống” (plain) không có phần bất kỳ file nào. Sự bố trí block trên đĩa giống như việc bố trí dành cho các thư mục. Sau header của thuộc tính block là header của entry. Kích thước của các header entry khác với chiều dài của tên thuộc tính.
Các giá trị thuộc tính trên block giống như thuộc tính entry descriptor của chúng, sắp thẳng hàng đến cuối thuộc block thuộc tính. Điều này cho phép việc thêm vào các thuộc tính được dễ dàng hơn.
Danh sách tên thuộc tính gắn với một file có thể được gọi ra. Bộ điều khiển hệ thống tập tin trả về một chuỗi tên cách nhau bởi các ký tự null, kết thúc bằng hai ký tự null tại phần cuối của danh sách.
2.2.6 Quản trị hệ thống file EXT2
Filesystem caching : Nhằm tăng hiệu suất của toàn hệ thống file ext2, cache được dùng để lưu giữ các dữ liệu được dùng thường xuyên. Thông tin của filesystem được cache trong bộ nhớ, đôi khi được tham khảo tới như là một bộ đệm đĩa, bởi vì việc truy cập vào bộ nhớ thì nhanh hơn nhiều so với các đĩa vật lý. Cả hai quá trình đọc và ghi đều được cache dữ liệu trên RAM. Hệ thống buffers đĩa càng lớn thì filesystem đáp ứng càng nhanh cho các thao tác đọc ghi. Do RAM là bộ nhớ tạm thời, buffer sẽ được ghi vào đĩa khi máy hoạt động, hay khi filesystem được unmount.
Lệnh sync có thể dùng để ép kernel ghi tất cả các buffers vào các file trên đĩa. Lệnh này có thể sử dụng không cần tham số.
Ví dụ: Với lý do này có thể giải thích vì sao khi chép file vào đĩa mềm ta thấy hệ thống chạy rất nhanh tuy nhiên lúc này thực sự file chưa được ghi vào đĩa mềm. nếu để ý thì bạn sẽ thấy khoảng 5 giây sau đèn ổ mềm mới bắt đầu sáng. Nếu trước đó ta cứ tưởng là đã chép xong file mà rút đĩa mềm ra thì sẽ không có file nào được ghi vào đĩa cả.
Sự phân mảnh của hệ thống file
Hệ thống ext2 được thiết kế nhằm hạn chế tối thiểu sự phân mảnh nên ta không cần phải defragment hệ thống file ext2.
Nguyên nhân gây ra sự phân mảnh của file system là việc ghi file nhiều lần trên ổ đĩa. Trong đó các file làm bộ nhớ mở rộng của hệ thống trên đĩa là có nguy cơ bị phân mảnh nhiều nhất.
Đối với các hệ điều hành và MS Windows, hệ thống bộ nhớ mở rộng này nằm trên cùng một partition chính của hệ thống thông qua file pagefile.sys còn trong Linux thì hệ thống bộ nhớ mở rộng này được cho ra một partition riêng nên hạn chế rất nhiều sự phân mảnh.
2.3 Hệ thống File EXT3
Được xây dựng dựa trên cơ sở của hệ thống file chuẩn ext2 mà Linux đang sử dụng, ext3 đưa vào thêm chức năng mới vô cùng quan trọng, journaling file system, giúp thao tác dữ liệu an toàn hơn.
Khi hệ điều hành bị tắt bất thình lình (mất điện, lỗi phần mềm, v.v..), trong hệ thống file xuất hiện lỗi do file đang ghi dở, địa chỉ chưa được cập nhật,… Nếu hệ thống file đang dùng không thuộc loại hệ thống file nhật ký (ext2,…), khi khởi động lại, hệ điều hành sẽ phát hiện được lần tắt bị lỗi (unclean shutdown) trước đó và tự động dùng phần mềm fsck (file system check) để soát và sửa lỗi. Nếu ổ cứng lớn, quá trình chạy fsck sẽ khá lâu và nếu lỗi nặng fsck không sửa được nó sẽ báo cho hệ điều hành khởi động vào chế độ single user mode để người dùng sửa.
Hệ thống file nhật ký tránh việc hỏng hệ thống file bằng cách ghi một nhật ký. Nhật ký là một file riêng ghi lại mọi thay đổi của hệ thống file vào một vùng đệm (thay vì ghi thẳng vào hệ thống file trên ổ cứng). Sau từng khoảng thời gian định trước, những thay đổi đó được thực hiện chính thức vào hệ thống file. Nếu giữa khoảng thời gian đó, hệ thống bị tắt đột ngột, file nhật ký sẽ được dùng để khôi phục lại các thông tin chưa lưu và tránh làm hỏng metadata của hệ thống file.
[Metadata của hệ thống gồm các thông tin về cấu trúc dữ liệu trên ổ cứng: ngày giờ tạo, xoá file và thư mục, tăng giảm dung lượng file, chủ nhân của file, ...]
Tóm lại, hệ thống file nhật ký là một hệ thống file tự chữa lỗi bằng cách dùng một file nhật ký lưu lại mọi thay đổi trước khi thay đổi đó được thực hiện thật sự vào hệ thống file.
Sơ đồ một hệ thống file nhật ký.
Ext3 còn sử dụng cơ chế JBD (Journaling Block Device) để bảo vệ thông tin thao tác trên dữ liệu, được đánh giá là tin cậy hơn so với các hệ thống chỉ thực hiện journaling trên chỉ mục dữ liệu (journaling of meta-data only) như Reiserfs, XFS hay JFS. Với cách bảo vệ hai lần như vậy thì hiệu suất ghi dữ liệu có phần nào chậm hơn ext2; nhưng trong một vài trường hợp, nhờ thông tin trong journal log mà đầu từ ổ cứng di chuyển hợp lý hơn, nên tốc độ thao tác dữ liệu nhanh hơn.
Đối với những ứng dụng ưu tiên cho độ tin cậy của dữ liệu hơn là tốc độ ghi đơn thuần thì ext3 là lựa chọn thích hợp. Ngoài ra, ext3 còn cho phép cải thiện tốc độ thao tác trên dữ liệu bằng cách thiết lập thông số cho hệ thống chỉ thực hiện journaling đối với thao tác trên dữ liệu (mode: data=writeback và data = ordered).
Với mode data=writeback, quá trình khởi động nhanh, dữ liệu được ghi vào đĩa ngay sau khi đã ghi xong thông tin trong journal log (write back), với mode này đôi khi cũng xảy ra tình trạng hư dữ liệu nếu sự cố xảy ra ngay sau khi ghi journal log mà chưa kịp ghi vào đĩa, nhưng bù lại tốc độ thao tác file nhanh hơn trong một vài trường hợp.
Với mode data=ordered, dữ liệu được ghi lên đĩa trước rồi mới đến journal log, cho phép luôn luôn bảo đảm tính toàn vẹn của dữ liệu trong mọi tình huống và đây cũng chính là mode mặc định của ext3. Với mode data=journal thì việc bảo vệ được thực hiện trên cả hai: dữ liệu và journal log; thông tin được ghi chi tiết và nhiều hơn giúp cải thiện tốc độ truy cập dữ liệu nhờ tối ưu việc di chuyển của đầu từ, hoạt động rất tốt đối với kiểu dữ liệu là database hoặc dữ liệu dùng chung trên mạng (NFS), tuy nhiên do phải đọc lại nhiều loại thông tin trên journal log nên thời gian khởi động lại máy hơi chậm hơn so với hai mode trên một chút.
Vì bản chất cấu trúc của ext3 được xây dựng hoàn toàn dựa trên cơ sở của ext2 nên ta có thể chuyển đổi dễ dàng các dữ liệu đang tồn tại trên các hệ thống ext2 sang ext3 mà dữ liệu không hề bị ảnh hưởng và thực hiện tương đối dễ dàng, đơn giản. Với kernel Linux từ 2.4.15 trở lên thì ext3 đã có sẵn mà không cần phải đưa thêm vào (patch) như các version cũ. Hiện tại hãng Linux RedHat đã đưa sẵn module ext3 vào kernel 2.4.7-10 trong bản RedHat 7.2.
Từ phiên bản Red Hat 7.2, hệ thống tập tin mặc định là ext3.
Block size
Kích thước file lớn nhất
Kích thước Hệ Thống file lớn nhất
1 KiB
16 GiB
2 TiB
2 KiB
256 GiB
8 TiB
4 KiB
2 TiB
16 TiB
8 KiB[limits 1]
2 TiB
32 TiB
Hệ thống file ext3 thực chất là phiên bản nâng cao của ext2. Ext3 có những ưu điểm sau:
Tính khả dụng:
Khi bộ nguồn bị hỏng hay hệ thống đổ vỡ bất chợt, mỗi phân vùng định dạng theo ext2 trên máy tính phải được kiểm tra việc đồng nhất của chúng bằng chương trình e2fsck. Việc này cần khoảng thời gian để tiến hành làm thời gian khởi động hệ thống bị trễ đáng kể, đặc biệt là với phân vùng lớn.Trong suốt thời gian này dữ liệu trên phân vùng không được dùng đến.
Ext3 được đưa ra để không cần phải thực hiện việc kiểm tra đó khi hệ thống máy tính bị tắt đột ngột, việc kiểm tra chỉ xảy ra khi phần cứng bị hư hỏng, chẳng hạn như ổ đĩa cứng bị hư. Thời gian kiểm tra không phụ thuộc vào dung lượng hay số lượng file của phân vùng.
Tính toàn vẹn của dữ liệu.
Hệ thống tập tin ext3 cung cấp việc bảo toàn dữ liệu trong việc hệ thống tắt đột ngột, và cho phép ta chọn loại và mức độ bảo vệ dữ liệu. Mặc định là mức bảo vệ cao nhất (high level)
Tốc độ
Bất chấp việc ghi dữ liệu nhiều lần hay một lần, ext3 có số lượng dữ liệu đưa vào quá trình ghi nhiều hơn hẳn so với ext2 bởi ext3 đã tối ưu hóa đầu đọc chuyển động của ở đĩa cứng. Ta có thể chọn một trong ba mức để tối ưu tốc độ nhưng điều này có thể làm giảm tính toàn vẹn của dữ liệu.
Dễ dàng chuyển đổi
Thật dễ dàng để ta chuyển đổi từ ext2 lên ext3 và đạt được những lợi ích của một hệ thống tập tin mạnh mà không cần phải định dạng lại.
Để chuyển đổi từ ext2 sang ext3, đăng nhập bằng root và gõ lệnh:
/sbin/tune2fs –j /dev/hdbx
/dev/hdb : thay bằng tên thiết bị và x là số thứ tự của phân vùng cần chuyển đổi.
2.4 Hệ thống File EXT4
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 ổ 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 file 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 file hệ thống chẳng 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 hơn 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 kernel 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. Kernel 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 hơn. 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. Để 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 đổi 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 tương ứng. Siêu dữ liệu tồn tại trong siêu khối, mô tả nhóm, và journal. 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_free_blocks_count, s_blocks_count, và s_r_blocks_count.
Kể từ khi địa chỉ 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 để 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 META_BG, 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 đĩa duy nhất. Đối với ext4 hệ thống tập tin với kích thước khối 4 KB, một khối siêu phân vùng duy nhất nhóm bao gồm 64 nhóm khối, hoặc 8 GB không gian đĩa. Điều này làm tăng các nhóm tối đa 221 khối hạn chế giới hạn cứng 232, cho phép hỗ trợ cho hệ thống tập tin đầy đủ, 1 EB.
2.4.2.3 Lưu file theo nhóm block (Extents)
Hệ thống tập tin ext3 sử dụng một chương trình lập bản đồ khối gián tiếp cung cấp ánh xạ một một từ khối logic đến đĩa. Chương trình này rất hiệu quả cho các tập tin thưa thớt hoặc nhỏ, nhưng có chi phí cao cho các tập tin lớn hơn, hoạt động kém hơn, đặc biệt là trong việc xóa và cắt ngắn file lớn.
Như đã đề cập trước đó, extent mapping được bao gồm trong ext4. Cách tiếp cận này ánh xạ hợp lý đến khối vật lý cho các tập tin lớn kế tiếp một cách hiệu quả. Một extent là 1 mô tả duy nhất cho một loạt các khối tiếp giáp vật lý.
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 trưng 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 để lưu trữ ánh xạ của 1 file.
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ể lưu trữ, độ sâu của cây, và một số magic. Các số magic có thể đượ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 Chống 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ý (journaling) 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. Nếu 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 Đếm số inode (index-node) chưa dùng và việc làm lệnh e2fsck nhanh hơn
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 inode 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 điể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. Kết quả là, e2fsck có thể 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. Để đả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 phép tất cả các dữ liệu (fields) 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 (kernel) 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.
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 kể đế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.7 Kiể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 thổng 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 lưu 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. Nếu 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. Nếu 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 nhiều khối siêu dữ liệu đã không được ghi vào đĩa cứng hoặc bị đứt khi trao đổi dữ liệu. Sau đó quá trình trao đổi dữ liệu (cả những quá trình sau đó) bị hủy bỏ và máy tính bị treo, cũng như khối chứa dữ liệu không được ghi ra nữa.
Kể từ khi quá trình kiểm tra tổng thể trong nhật ký cho phép nhận ra khối dữ liệu chưa được ghi vào nhật ký, thì nó không cần 2 quá trình lưu tập tin riêng rẽ như trước kia nữa. Khối chữa dữ liệu có thể được ghi đồng thời với tất cả các phần còn lại của tập tin cùng lúc trong quá trình trao đổi tập tin. Quá trình này thật sự làm tăng xử lý định dạng tập tin lên (khoảng 20%), thay vì làm quá tải hệ thống như trước kia.
Có thể thêm phần kiểm tra tổng thể vào phần đuôi mở rộng của tập tin, bản đồ cố định các bít, các inode, và cả đường dẫn tập tin nữa. Điều này có thể làm được nhờ vào việc lưu nhật ký quá trình trao đổi tập tin. Thà mất thời gian tính toán kiểm tra tổng thể của định dạng tập tin mỗi khi nó thay đổi, chúng ta sẽ có thể ghi lại nhật ký thay đổi của tập tin và sửa chữa nó nếu bị lỗi vào lúc khôi phục. Các khối dữ liệu có thể chứa siêu dữ liệu cùng với dữ liệu kiểm tra được ghi lại cùng lúc vào tập tin.
2.4.2.8 Các đặc điểm mới
Các đặc điểm mới vẫn đang được tiếp tục thêm vào định dạng tập tin ext4. Hai đặc điểm đáng mong đợi ở định dạng tập tin ext4 là lưu dấu vết thời gian về tập tin đến từng nanô-giây và có thể lưu từng phiên bản của inode. Hai đặc điểm này đều nhằm quản lý khi nào tập tin bị thay đổi và những sự thay đổi của tập tin.
Ext3 chỉ lưu dấu vết thời gian cho từng tập tin đến giới hạn giây. Nhưng với chip tốc độ cao ngày nay thì nó có thể thay đổi nhiều tập tin chỉ trong một giây. Trong định dạng ext4, kể từ khi sử dụng inode lớn hơn, đã có thể lưu lại dấu vết thời gian chính xác đến nanô-giây. Với độ rộng 32 bít cho các trường atime, mtime và ctime, có thêm một trường mới là crtime được tạo ra khi tập tin được tạo mới, và được thêm vào inode của định dạng ext4. 30 bít đầu được dùng để lưu dữ liệu của nanô-giây, 2 bít còn lại được sử dụng để mở rộng thời gian, tính theo kỷ nguyên đến 272 năm tiếp theo.
Các phiên bản NFSv4 ở máy khách cần các cập nhật của tập tin từ máy chủ, theo thứ tự để dữ liệu ở máy khách luôn là mới nhất. Ngay cả khi ctime được hỗ trợ đến nanô-giây, thì dấu vết thời gian của tập tin cũng không cần cập nhật đến mức nanô-giây. Các inode của định dạng ext4 được chia làm các phiên bản bằng cách cấp một bộ đếm chung 64-bít cho mỗi inode. Bộ đếm này tăng lên mỗi khi tập tin có thay đổi. Bộ đếm được khởi tạo khi tập tin bắt đầu đươc tạo ra. Việc tràn bộ đếm là gần như không thể xảy ra được, vì tổng số bộ đếm đã được tính toán và kiểm tra. Phiên bản thứ i của các trường inode được giới thiệu gồm 128 bít, trong đó 32 bít dùng cho inode thường và 32 bit dùng cho inode cỡ lớn.
Nâng cấp định dạng
Ext3 được phát triển để có thể tương thích ngược với định dạng tập tin kiểu ext2, phụ thuộc vào đặc trưng của người sử dụng. Trong khi ext4 nỗ lực để giữ lại khả năng tương thích với ext3 càng nhiều càng tốt, đôi khi vẫn không tương thích nếu cách sắp xếp dữ liệu trên đĩa cứng bị thay đổi.
Mặc dù vậy, người dùng vẫn có thể dễ dàng nâng cấp định dạng tập tin từ ext3 lên ext4, giống như có thể nâng cấp từ ext2 lên ext3. Có nhiều cách để người dùng có thể trực tiếp định dạng kiểu ext4 cho tập tin, hoặc nâng cấp định dạng lên ext4 mà không cần sao lưu và khôi phục lại tập tin đó.
Nâng cấp từ ext3 sang ext4
Rất đơn giản để nâng cấp định dạng cho người dùng ext3 bắt đầu sử dụng phân vùng bộ nhớ mở rộng (extents) và một vài đặc điểm của định dạng ext4, mà không cần phải sao lưu hoặc nâng cấp tập tin. Bằng cách dựng lên (mounting) một tập tin đã có định dạng ext3 thành ext4 (với phân vùng bộ nhớ được phép truy cập), tập tin mới tạo ra được sử dụng phân vùng bộ nhớ mở rộng, nhưng bản chất nó vẫn còn gián tiếp trỏ đến khối bản đồ bit ext3 và chỉ có bề ngoài được thể hiện là ext4. Một cái cờ (flag) bên trong bảng inode giúp phân biệt giữa 2 định dạng này, cho phép cả hai cùng tồn tại bên trong một định dạng tập tin. Tất cả các đặc điểm của ext4 cơ bản dựa vào phân vùng bộ nhớ mở rộng, ví dụ như xác định vị trí, gắn nhiều khối inode cố định, có thể sử dụng được ngay khi tập tin được gán phân vùng bộ nhớ mở rộng.
Một công cụ cũng được tạo ra để có thể nâng cấp định dạng tập tin hệ thống từ ext3 sang ext4. Công cụ nâng cấp này thực hiện hai chức năng chính: Nâng cấp ánh xạ từ con trỏ gián tiếp sang phân vùng bộ nhớ mở rộng, và mở rộng chiều dài inode lên 256 bytes.
Nâng cấp phân vùng bộ nhớ mở rộng: bước đầu tiền có thể thực hiện trực tuyến (online) và sử dụng công cụ chống phân mảnh. Trong suốt quá trình xử lý, tập tin sẽ từng bước được thay đổi ánh xạ sang phân vùng bộ nhớ mở rộng. Bằng cách này, tập tin sẽ được chuyển đổi sang phân vùng bộ nhớ mở rộng và chống phân mảnh cùng một lúc.
Nâng cấp inode: Mở rộng cấu trúc của inode thì phải được thực hiện thông qua ngoại tuyến (offline). Trong trường hợp này thì dữ liệu đã được sao lưu, toàn bộ định dạng tập tin hệ thống sẽ được quét và chuyển đổi sang phân vùng bộ nhớ mở rộng và mở rộng chiều dài inode.
Đối với những người chưa muốn chuyển sang dùng định dạng tập tin ext4 nhưng muốn sử dụng các đặc trưng của ext4, thì cũng có thể chuẩn bị tập tin ext3 của họ để nâng cấp ngoại tuyến sau đó. Nếu một tập tin ext3 được định dạng với cấu trúc có chiều dài inode lớn, 256 byte hoặc lớn hơn, thì đặc trưng về phân vùng bộ nhớ mở rộng của ext4 có thể dùng được ngay và luôn. Sau đó người dùng muốn nâng cấp hoàn chỉnh lên ext4, ví dụ nâng cấp các đặc điểm như chiều dài inode lớn, sử dụng bộ lưu vết thời gian chính xác đến nanô-giây, thì người sử dụng cần dùng bộ nâng cấp ngoại tuyến.
Chuyển định dạng xuống ext3 từ ext4
Không phức tạp như việc nâng cấp lên ext4 từ ext3, việc chuyển định dạng ngược trở lại ext3 khá dễ dàng. Người dùng chỉ việc dựng lại (remount) định dạng tập tin với tùy chọn noextents sau lệnh mount, sao chép tất cả các tập tin tạm và đổi tên nó trùng tên với tập tin cũ. Sau đó tất cả các tập tin sẽ được chuyển đổi ngược trở lại ánh xạ gián tiếp vào khối các bit, và cờ INCOM-PAT_EXTENTS phải được xóa đi bằng lệnh tune2fs, sau đó định dạng tập tin có thể dựng lên (mount) thành ext3.
Tốc độ thực thi
Chúng ta sẽ kiểm tra tốc độ thực thi của định dạng ext4, so sánh với định dạng ext3 và XFS, bằng 3 bài kiểm tra định dạng tập tin hệ thống. Định dạng ext4 được kiểm tra với phân vùng bộ nhớ mở rộng và cấp phát bộ nhớ trễ (delayed allocation) được phép truy cập. Bài chấm điểm sẽ phân tích và chọn ra những thay đổi đáng kể của ext4. 3 bài chấm điểm mà chúng ta chọn ở đây là: Flexible Filesystem Benchmark (FFSB), Postmark, và IOzone. FFSB được điều chỉnh để có thể chứa được một số lượng lớn các tập tin, dùng để kiểm tra đặc tính phân vùng mở rộng của định dạng ext4. Postmark được dùng để đánh giá hiệu năng (performance) của ext4 với một số lượng nhỏ tập tin. Cuối cùng, chúng ta dùng IOzone để tính toán khối lượng thực thi trung bình của định dạng tập tin ext4.
Các bài kiểm tra được chạy trên bộ nhân 2.6.21-rc4 với vùng cấp phát bộ nhớ trễ được bật. Cả 2 định dạng ext3 và ext4 đều được dựng ở chế độ ghi đè tập tin, và các chế độ vùng mở rộng bộ nhớ, cấp phát bộ nhớ trễ được đặt hợp lý. Còn định dạng XFS chúng ta đặt các tùy chọn mặc định khi dựng (mount) tập tin.
Hai bài kiểm tra FFSB và IOzone được chạy trên cùng một CPU 4 nhân tốc độ 2.8 Ghz của hãng Intel(R) Xeon(TM), Hệ thống gồm RAM 2 GB x, ổ đĩa cứng 68GB ultra320 SCSI (10000 vòng phút). Postmark cũng chạy trên một CPU 4 nhân tốc độ 700 MHz chíp Pentium(R) III với RAM 4 GB, ổ đĩa cứng 9 GB SCSI (7200 vòng phút). Kết quả của bài kiểm tra bao gồm cả tập tin dữ liệu định dạng raw được để tại trang chủ wiki của ext4.
Kiểm tra bằng FFSB
FFSB là một công cụ chấm điểm định dạng tập tin hệ thống rất mạnh, có thể giả lập nhiều hệ thống cân bằng tải khác nhau để kiểm tra tập tin. Chúng ta sẽ kiểm tra việc tạo ra một tập tin dung lượng khá lớn sử dung đa luồng. Kiểm tra được thực hiện với khoảng 4 luồng chạy đa nhiệm song song, kiểm tra đồng thời 24 tập tin, mỗi tập tin dung lượng tới 1GB. Cần kiểm tra tốc độ tạo ra tập tin và tốc độ ghi tập tin vào đĩa cứng.
Bài kiểm tra FFSB của các định dạng khác nhau.
Kết quả là, như ta thấy, tốc độ ghi tập tin của định dạng ext4 tăng lên từ 35% đến 40% so với định dạng ext3. Tốc độ thực thi ghi tập tin của xfs và ext4 là ngang nhau. Đúng như mong đợi, việc phân bố bộ nhớ mở rộng và cho phép cấp phát bộ nhớ trễ đã có hiệu quả làm tăng khả năng xử lý tập tin dung lượng lớn và rất lớn.
Kiểm tra bằng Postmark
Postmark được biết đến là một bài kiểm tra giả lập một hòm thư từ máy chủ phải xử lý rất nhiều thư gửi từ máy khách, theo các đường đơn-luồng (single-threaded) gửi đến và thường có dung lượng tập tin nhận được là nhỏ hoặc rất nhỏ.
Bài kiểm tra Postmark đọc ghi các định dạng khác nhau.
Biểu đồ ở trên cho thấy ext4 vượt trội hơn khoảng 30% so với 2 định dạng còn lại. Trong khi bộ điểu khiển trung tâm (CPU) vẫn hoạt động tương tự nhau, không bị quá tải hơn. Bởi vì các siêu dữ liệu của ext4 đã được nén lại trong phân vùng bộ nhớ mở rộng. Ta cũng thấy quá trình ghi nhanh hơn đọc vì tất cả được ghi vào trong bộ nhớ chính (memory).
Kết quả này đã cho thấy rằng, bên cạnh việc có thể xử lý tốt những tập tin có dung lượng lớn, định dạng ext4 còn có thể xử lý rất nuột những tập tin dung lượng nhỏ mà không ảnh hưởng đến tốc độ chung của hệ thống.
Kiểm tra bằng IOzone
Chuẩn bị cho bài kiểm tra bằng Iozone, hệ thống đã được khởi động với 64MB bộ nhớ sẵn sàng để đọc ghi dữ liệu. Bài kiểm tra được tiến hành với khoảng 8MB bản ghi bao gồm rất nhiều tập tin với nhiều kiểu dung lượng khác nhau. Các phép thử như ghi, ghi đè, đọc, đọc lại, ghi ngẫu nhiên, và đọc ngẫu nhiên được thực hiện kiểm tra kỹ.
Kết quả kiểm tra với Iozone: tốc độ trao đổi 512MB tập tin
Hình trên cho thấy kết quả của việc đọc ghi 512MB tập tin. Tổng kết lại ta thấy kết quả là đã có sự tăng tốc vượt trội của ext4 so với ext3, đặc biệt là với quá trình ghi đè, ghi ngẫu nhiên và đọc lại. Trong bài kiểm tra này, xfs vẫn có tốc độ đọc khá tốt còn ext4 cho tốc độ ghi khá tốt.
Như chúng ta đã trao đổi bên trên, định dạng tập tin kiểu mới ext4 đã mang lại nhiều đặc điểm nổi bật hơn ext3, làm cho ext4 trở thành định dạng phổ biến cho nền tảng cần xử lý các tập tin lớn. Đã có rất nhiều đặc điểm được hoàn thiện để ext4 trở nên phổ biến trong nền tảng Linux, mà điều cơ bản nhất đó là một định dạng tập tin đơn giản, tối ưu, với độ cân bằng tốt, đáng tin cậy, tốc độ thực thi nhanh và ổn định. Những người dùng định dạng ext3 sẽ sớm phải nhận ra rằng họ nên cập nhật lên định dạng ext4, một định dạng trong cùng gia đình ext nhưng mang trong mình rất nhiều đặc điểm vượt trội.
Kết luận
Như vậy ta có thể thấy từ khi ra đời đến này, tính đến thời điểm hiện tại, Linux đã có rất nhiều biến thể và phiên bản khác nhau, được xây dựng và phát triển riêng biệt bởi các công ty phần mềm và các cá nhân. Hiện nay, sau hơn 20 năm tồn tại và phát triển, Linux được sử dụng rộng rãi trên toàn thế giới, trên các máy tính cá nhân, các máy chủ, đến các thiết bị di động, máy nghe nhạc, máy tính bảng, các máy ATM và thậm chí trên cả các siêu máy tính… Ngày nay, Linux được xem là biểu tượng của sự chia sẻ cộng đồng, được phát triển bởi cộng đồng và được ủng hộ vì hoàn toàn miễn phí. Với những tính năng ngày càng tiên tiến, hệ thống File được nâng cấp, hoàn thiện đáp ứng nhu cầu của người sử dụng. Hệ điều hành Linux sẽ ngày càng phát triển trong tương lai.
TÀI LIỆU THAM KHẢO
Các cuốn sách tham khảo :
[1] Trần Thạch Tùng, Bảo mật và Tối ưu trong Red Hat Linux, 2003
[2] Tiêu Đông Nhơn, Giáo trình hệ điều hành Linux, NXB ĐH QG TP.HCM
[3] Tiêu Đông Nhơn, Giáo trình dịch vụ mạng Linux, NXB ĐH QG TP.HCM
[4] Huỳnh Thúc Cước, Giáo Trình HĐH Linux, Viện Công Nghệ Thông Tin
[5] Tham khảo File: Ext4-File-System 6/2007 IBM Linux Technology Center
Các địa chỉ Website tham khảo :
[1]
[2]
[3]
[4]
[5] Một số website liên quan khác.
Các file đính kèm theo tài liệu này:
- Cấu trúc hệ thống file ext2,ext3, ext4 trong họ linux.doc