Solaris中的logging功能的應用 在Solaris7及其以後版本的系統中有一種稱為logging的功能。它不但易於安裝和使用，並且對於數據安全非常有用。 UFS是存在於Sun工作站的幾乎所有硬盤分區（swap等個別分區除外）上的一種標准的文件系統類型。而logging功能是UFS文件系統的一個掛接選項，它可以被設置在包括/在內的各個硬盤分區上。 Solaris的UFS logging通過使用系統中的空白數據塊來工作。所有對文件系統數據（metadata，或稱為元數據）的修改都被寫在這些空白的區域。這些Metadata包括目錄和inode信息，不包括文件中的數據本身。比如創建文件時，目錄結構被修改並且系統為這個新文件分配一個新的inode。以上這些行為被寫入做logging的空間中。一旦數據的修改行為被寫入做logging的區域，系統就可以接著對文件系統做其它的操作了。在後台，存在於logging中的信息將被同步到文件系統中，並自動更新相應的目錄和I節點，最終完成文件系統的操作。數據也陸續被寫入硬盤。因此這種做logging並在後台寫入數據，比通過隨機的I/O訪問直接對分布在硬盤上的各種管理信息進行修改的方式速度要快得多。用來做logging的空間的大小取決於文件系統的大小。每1GB磁盤分區空間的logging空間為1MB，最多不超過64MB。這部分logging空間被循環使用：當log空間即將裝滿時，暫停新的metadata數據寫入，直至log空間被清空。當log中記錄的關於文件系統的修改都被應用於文件系統後，那部分空間又重新可以作為log空間來存放新的metadata數據了。 通常對於UFS來說，如果操作系統在任何文件系統操作中崩潰，整個文件系統都需要用fsck命令做一致性檢查。這個命令的執行可能需要幾分鐘的時間，因為它需要檢測所有的metadata和文件的數據以確認文件系統的完整性：包括當前已經用的空間、未用的、inode的數量等，修復其中不一致的地方。出現比較大的問題時還需要人工干預。在做檢查的過程中有可能會丟失文件，甚至目錄。這決定於crash發生時，該操作進行到了哪種程度。如果采用logging功能，情況就完全不同。因為metadata的修改首先被寫在log空間而不是文件系統中。如果系統崩潰，對文件系統一致性的檢測可以僅僅限於log中記錄的那部分，這樣會更簡單、更有效。系統檢查logging的數據，以決定在上一次的文件系統中，哪種修改已經做過了，哪種修改即將做，哪種修改正在做， 做過的和即將做但還沒有做的操作被系統從log中刪掉， 而那些做了一部分的會被接著做完或完全取消掉。如果在log中記錄了足夠的數據來完成這一操作，該操作會被繼續完成。否則，這種改變會被取消。熟悉數據庫操作的用戶會發現這和數據庫軟件中的事務處理過程非常相似。最終的結果是：文件系統能夠最大限度地保持一致，不需要進行徹底的文件系統檢測，整個文件系統檢測過程只需要花幾秒鐘時間。從Solaris 7開始, mount命令和/etc/vfstab文件中也有了一個新的logging選項。 為了驗證logging選項對系統性能的貢獻，我們做一個腳本文件，它要創建1000個目錄。這種操作將對系統中的metadata的處理帶來非常大的壓力。實驗在一台運行Solaris7的Ultra 5機器上進行： # more logging-test #!/bin/ksh # Test ufs logging performance # Get to the right place and make a test Directory cd /big mkdir test # Create 1000 directories integer i=0 while ((i < 1000)) do mkdir test/test${i} i=i+1 done # chmod a+x logging-test 給文件加上執行權限 第一次做實驗時不采用logging選項(Solaris 7和8的文件系統缺省狀態下都不采用這種選項)。 # time ./logging-test 用此命令測一下整個執行時間 real 27.7 user 2.0 sys 4.9 # time rm -rf /big/test real 8.0 user 0.0 sys 0.3 結果創建和刪除目錄共需要35.7秒時間。第二次采用logging選項，再做一次測試： # umount /big # mount -o logging /big # time ./logging-test real 13.2 user 1.7 sys 5.4 # time rm -rf /big/test real 0.8 user 0.0 sys 0.2 同樣的命令在采用UFS logging以後只需要14秒的時間，性能提高非常明顯。下一個測試更有趣。不采用logging，並在上面的腳本執行過程中關機，那麼下一次啟動時，系統要求進入單用戶狀態手工執行fsck來修復系統，在修復過程中也報了很多錯。修復了以後，系統可以引導起來。采用了logging功能後，同樣的實驗過程卻得到了令人鼓舞的結果：系統僅僅提示： /dev/c0t1d0s3: is logging 沒有其它的報錯信息給出。 但是UFS logging最初會有一些bug，在采用UFS logging之前，需要打最新的系統核心patch，並且最好在另一個非生產環境進行測試。 還有另一種比較新的而且很有用的mount選項：noatime。如果沒有noatime選項，每個文件每次被訪問，它的I節點中的訪問時間的值都會被更新。這樣，用ls –lu命令可以看出文件最近一次被“讀”的時間。但是有些情況下我們並不關心文件什麼時候被讀過，比如Web server 的內容，但是他們增加很多的IO負載，從而影響性能。使用noatime會減少訪問時間被更新的頻率，它使系統只有在該文件的其它I節點屬性同時修改時才更新文件的訪問時間。在我們不關心訪問時間的文件系統中，這不會對系統造成什麼損害。
