Question

我正在对包含大约9K目录的目录进行Subversion更新。存储它的文件系统只有超过4K的免费inode。我发现运行svn更新时遇到问题，因为系统用完了svnclient创建的.lock文件的inode：

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和这个大小，暂时），并且由于ext3s的不足，我无法添加inode。有没有办法让svn创建更少的.lock文件，或者使用操作系统提供的实际文件锁定功能，而不是需要来创建额外的文件？我知道flock在NFS3等上不起作用 - 但是我没有查看NFS。或者，是否有一些可以用来加速取消链接的ext3可调参数？

有任何聪明的解决方法吗？它可以运行“svn update ./*”，但这需要永远。好像，几十分钟。有一些关于创建9K SSL连接的东西，我猜想比创建一个慢。：）

减少svn co创建的.lock文件的数量？

0 个答案: