NFS経由でマウントされたVMにファイルシステムがあります。この問題は VM 自体で複製されるため、NFS とは関係がないと考えられます。
ファイルシステムの形式は次のとおりです。
/
dir_a
file_a
file_b
...
special.csv
dir_b
file_a
file_b
...
special.csv
各ディレクトリの下にあるこれらのファイルは、ほぼ同時に最後に記録されますspecial.csv
。special.csv
次のように書かれています。
import pandas as pd
import os
df = pd.Dataframe()
# populate small dataframe (~30 rows of 5 columns of ints/doubles and 1 column of 60char str)
hidden_path = os.path.join(base_dir, '.special.csv')
actual_path = os.path.join(base_dir, 'special.csv')
df.to_csv(hidden_path, index=False)
os.replace(hidden_path, actual_path)
実行中にrm -rf dir_a
予想以上に時間がかかることがわかりました(約30個のファイルがあり、合計サイズが約5GBのディレクトリの場合は数分かかります)。さらなる調査は、このspecial.csv
ファイルを除いて、ディレクトリ内の他のすべてのファイルがすぐに削除されたことを示しました。
実行時にシステムコールが完了していることstrace -T rm -Rf special.csv
がわかりました。unlinkat
~89s
このファイルがディレクトリ内の他のファイルとは異なる動作をする理由がわかりませんspecial.csv
。これは、ディレクトリ内の他のファイルが同様の方法os.replace
で生成されたためです(約)。私が考えることができる唯一の違いは、書く前に別のファイルに触れてpyarrow
。
special.csv
あらゆる種類の編集や削除に時間がかかるようですtouch special.csv
。たとえば、1分以上かかることがあります。touch special.csv
しかし、そうであれば時間rm special.csv
がtouch special.csv
かかりますが、これはrm special.csv
瞬間的です。これがディスクキャッシュに関連しているかどうかはわかりません。
編集する: 記憶媒体は、NASではなくLinuxファイルシステムとしてマウントされます。根本的な原因は明らかにされていませんが、記憶媒体を再起動すると問題が解決したようです。
答え1
NFS を使用して接続する NAS の詳細を確認することをお勧めします。 「ジャンク」機能はありますか?点灯していますか?
NFSマウントは実際にファイルを削除しませんが、代わりにリモートシステムにファイルの削除を要求します。 NASは、必要に応じて後で復元できるように、これらの大容量ファイルをごみ箱に移動する可能性があります。リモートシステムはファイルが削除されたことをNFSに報告しますが、実際には削除されています。