本文共 4344 字，大约阅读时间需要 14 分钟。

原贴：http://bbs.chinaunix.net/viewthread.php?tid=231434 如何在 Alpha UNIX 的 AdvFS 下， 處理 "df" and "du" 不一致的結果！      HP 諮詢中心技術經理 郭正時 文 身為系統管理的您，不幸地遭遇到 Alpha UNIX 的 AdvFS 檔案系統爆滿；且經過一番努力刪除過久不用或 過大的檔案後，卻發現檔案系統的 "df" and "du" 不一致，在情急之下該如何處置？讓系統正常地讀寫 運作！ (一) 用最簡單的方式來釐清：這是系統或是應用程式 (AP) 的問題？ 1 "umount" 有問題的檔案系統，(最乾脆徹底的是下達 "shutdown" 至 single user mode)，然後再 "mount" 它。 2 如果問題解決了，那是應用程式 (AP) 的 " rocess" 的問題。請您 自行研究處理，否則就是系統的問題了！在求助於 HP 解決之前，請 您先行測試 "quotacheck" 的指令。(下面有詳細的說明) 3 經過 "quotacheck" 的檢試，如果問題依然存在，您將有權利要求 HP 處理解決，嚴重的話，HP 將搜集下列資料，然後送交美國 UNIX Support team 尋求解答。(Open an IPMT outage case.)     (I) 執行 "vfile" 指令 in V4.* 或 "savemeta" in V5.*. 搜集有 問題的檔案系統資料。(下面有詳細的說明)   (II) 執行 "sys_check -escalate" 指令，搜集此部系統所有相關資料。 4 如果您急著使用這有問題的檔案系統，下列有兩種方法將可即時解決 空間不足讀寫的問題。        (I)執行 "addvol" 指令在有問題的檔案系統如下(需有多餘的Disk).        # addvol  AdvFS_domain     (II)備份 (vdump) 這有問題的檔案系統，然後重建一新 AdvFS         domain.再還原所有資料(vrestore)。由於有問題的檔案系統         因此毀掉消失，是故已無法再追究，也就是說不能尋求 IPMT         outage 來獲得答案。 (二) 複雜且詳細的分析說明：      1) 利用 "df"，"du" 和  "showfdmn" 來驗證 Disk 使用空間是否不同？    # df -k /usr    Filesystem     1024-blocks        Used   Available Capacity  Mounted on    usr_domain#usr     4710400     3732206      945136    80%    /usr    # du -sxk /usr    3522777 /usr    # showfdmn -k usr_domain           Id                      Date Created  LogPgs  Version  Domain Name    3bc4f4a8.000880f0  Thu Oct 11 09:23:52 2001     512        4  usr_domain           Vol    1K-Blks        Free  % Used  Cmode  Rblks  Wblks  Vol Name            1L    4710400      945136     80%     on    256    256  /dev/disk/dsk1g # =======>; 從 "df" 和 "du" 的比較，"/usr" 使用空間有 210 MB 的差異。       2) 利用 "vdf" 和 "showfsets" 檢查是否有多建的 filesets，而疏忽          它使用空間的計算，因為它是在 "umount" 的狀況下。 # df -k /usr Filesystem     1024-blocks        Used   Available Capacity  Mounted on usr_domain#usr     4710400     3732206      945040    80%    /usr # /sbin/advfs/vdf -k usr_domain Domain            1024-blocks    Metadata        Used   Available Capacity usr_domain            4710400       32258     3732222      945040      80% # showfsets usr_domain usr         Id           : 3bc4f4a8.000880f0.1.8001         Files        :    64108,  SLim=        0,  HLim=        0         Blocks (512) :  7464412,  SLim=        0,  HLim=        0         Quota Status : user=off group=off         Object Safety: off         Fragging     : on         DMAPI        : off test         Id           : 3bc4f4a8.000880f0.2.8001         Files        :        2,  SLim=        0,  HLim=        0         Blocks (512) :       32,  SLim=        0,  HLim=        0         Quota Status : user=off group=off         Object Safety: off         Fragging     : on         DMAPI        : off # =======>; 的確 the "/usr" 使用空間有 210 MB 的差異。      3) 利用 "fuser" 和 "lsof" (list open file is a public tools) 指令 檢查是不是某一個 process 造成的。如果可以的話，利用 "kill" 即 可解決。(如果是資料庫管理或應用程式的 processes，請由 AP 處理， 不建議直接使用 "kill" 的指令)。下面範例可以簡單說明： # tar cf /usr/large_tar_file /var & # rm /usr/large_tar_file =======>; "/usr" 利用"df" and "du"指令顯示它的使用空間將有所差異，而自動 解決這不一致的情況，將等到上面指令 "tar" 的結束。或者 # fuser -uv /usr         -- or --     # lsof /usr # kill -9       =======>; 可疑的 Process # df -k /usr Filesystem     1024-blocks        Used   Available Capacity  Mounted on usr_domain#usr     4710400     3494438     1182904    75%    /usr # du -sxk /usr 3522777 /usr # =======>; Bin-Go, "/usr" 利用"df" and "du"指令顯示它的使用空間一致了。 4) 如果不幸無法找出可疑的 Process，只好試著 re-mount (umount 後再 mount)。果 re-mount 後，利用"df" and "du"指令顯示檔案系統的使用 空間仍有所差異。請先使用 "quotacheck" 的指令檢測這有問題的檔案 系統，因為 AdvFS 有某些參考 QUOTA 來掌控檔案系統的使用空間(不 過系統已是最新的作業系統或 OS Patch Kits，應較無此問題)。在執行 "quotacheck" 之前，有些設定不同於 Tru64 4.* and 5.*.         In Tru64 4.* you have to add userquota,groupquota to fstab without         actually running quotas.          Example：         I)    add userquota,groupquota to /etc/fstab for each advfs               filesystem         II)   start quota on filesystem ( quotaon -a )         III)  run quotacheck on desired filesystem         IV)   verify that vdf -k is more or less equal to du -sk         V)    quotaoff -a         VI)   return the original /etc/fstab file.         vdf is the recommended method and should be accurate with         quotacheck run.         However in 5.* you should only need to to run quotacheck and         verify the output again.         # quotacheck -v /mount_dir   -- or --                                           # quotacheck -v DOMAIN#FILESET         # df -k /mount_dir         # du -sxk /mount_dir 5)        放棄 escalate an IPMT outage 而立即修復，也就是立即備份和復原    有問題的檔案資料。         # vdump 0uf /dev/rmt0h /mount_dir         # umount /mount_dir         # rmfdmn         # mkfdmn  AdvFS_domain         # mkfset AdvFS_domain         # mount /mount_dir         # cd /mount_dir         # vrestore xf /dev/rmt0h 6)        搜集下列資料，Open an IPMT outage 送交美國 UNIX Support team    尋求解答。        (I)執行 "sys_check -escalate" 指令，搜集此部系統所有相關資           料，產生於 "/var/tmp/escalate.tar"。        (II)搜集有問題的檔案系統資料。在 Tru64 4.* and 5.* 上執行有            些不同。                In V4.*:                # vfile 0 0 /dev/rrzXXX  >; bmt.log                # vfile 0 1 /dev/rrzXXX  >; sbm.log                # vfile 0 2 /dev/rrzXXX  >; tag.log                # vfile 0 3 /dev/rrzXXX  >; trans.log                In V5.*                # /sbin/advfs/savemeta  /save_dir 附註：根據我們的經驗，檔案系統使用空間不一致的情況，大多是因為 Process 不正常，造成檔案系統 LOCK 的問題。所以如果這有問 題的檔案系統多為您的 AP 所用，請先檢查應用程式。

转载地址：http://vxtob.baihongyu.com/