2014-05-04 71 views
1

我們的OpenVMS 8.3 ODS-5機器,以影子集成員身份掛載的磁盤有時會突然沒有明顯原因地丟失空閒塊。將FREEBLOCKS和磁盤上所有文件的總大小加起來,總和要比磁盤上實際可用的總塊大得多。任何人都可以提出什麼可能導致此?OpenVMS ODS-5空閒塊

我發現清除文件通常會消除這個問題,但沒有解釋它,也找不到引起它的文件。

機器不在集羣中,ANALYZE/RMS告訴我和我諮詢的其他人,什麼也沒有。所有文件版本都被考慮過,但可能需要dir/size進一步限定。我不知道有任何臨時/臨時文件,但理想情況下,如果它們存在,我希望找到它們。 TOTALBLOCK-FREEBLOCKS與dir/siz/grand [000000...]輸出之間的差距約爲6000萬塊(約爲驅動器的一半)。

我不熟悉DFU。

+0

使用DIR/SIZE = ALLOCATION或DIR/SIZE = ALL。您只顯示的命令顯示'USED'塊',而不是預先分配的塊。預先分配可以由程序仔細考慮,或由於CLUSTERSIZE總結而不可避免。 Google:openvms dfu下載。如果你對文件和分配以及可用空間非常認真,那麼DFU就是必須的。 – Hein

回答

2
  • 別擔心。要開心。這肯定不是一個問題,只是缺乏理解。 (當然,人們可以認爲這本身就是一個更大的問題,而不是明顯的數字不匹配。:-)

  • 「更低」幾乎沒有意義。一切都是相對的。一些定量數字如何?

  • 這是一個集羣嗎?每個集羣成員都可以並且將擁有自己的擴展緩存,每個可能空間的可用空間的10%。你在點數前沖洗過那些東西嗎?

  • 被分配的塊是否被計數,應該如此,或者可能只是用塊?

  • 是所有文件的所有版本計算在內(因爲清洗可能改變結果)

  • 執行系統上的應用程序中使用未進入目錄的臨時文件,因此可能不計?

  • 您是否考慮啓用DISK QUOTA,只是爲了計數,而不是限制使用?

  • ANALYZE/DISK如何?

  • 如何用DFU撥動驅動器......強烈推薦!可能「快得多」:-),並且比任何基於目錄的「更準確」。

Regards, Hein。

+0

點#4。使用的命令是「dir/siz/grand」應該是「dir/siz = ALL/grand」,但真的應該是DFU REPORT xxx: – Hein