約 9K のディレクトリを含むディレクトリの Subversion 更新を行っています。これが保存されているファイルシステムには、4K をわずかに超える空き inode があります。svnclient が作成する .lock ファイルの inode が不足しているため、svn update の実行で問題が発生しています。
user@host [cwd]$ svn update
svn: Can't open file 'baddir/.svn/lock': No space left on device
user@host [cwd]$ ls -1 | wc -l
8934
user@host [cwd]$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg00-lvol5
2.9G 958M 1.8G 35% /opt
user@host [cwd]$ df -hi .
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vg00-lvol5
186K 182K 4.3K 98% /opt
user@host [cwd]$ ls -1 | grep -n . | grep baddir
2714:baddir
はい、消毒済みです。:) どうやら svn が大量の .lock ファイルを作成しているようです。問題は、リンク解除が十分に速く行われていないことだと思います.strace（strace -o /tmp/deleteme svn update）で操作を遅くすると、別のディレクトリで更新が失敗するためです。スローダウンした strace がなければ、毎回まったく同じディレクトリで発生します。
今すぐこのファイルシステムのサイズを変更するのは不便です (当分の間、ext3 とこのサイズにする必要があります)。svn で作成する .lock ファイルを少なくする方法、または余分なファイルを作成する必要のない OS 提供の実際のファイル ロック機能を使用する方法はありますか? flock が NFS3 などで動作しないことは知っていますが、NFS ではチェックアウトしません。または、リンク解除を高速化するために使用できる ext3 チューナブルはありますか?
巧妙な回避策はありますか？「svn update ./*」を実行すると機能しますが、それには永遠に時間がかかります。というか、数十分。9K SSL 接続の作成については、作成よりも遅いと思います。:)