處理 "df" and "du" 不一致的結果

原贴：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 所用，請先檢查應用程式。