Azure挂载Azure Files时Subversion提交出现rep-cache数据库打开失败错误

Let’s break this down step by step—first, we’ll tackle whether your approach of using Azure Files via CIFS for Subversion repos is valid, then dive into diagnosing and fixing that frustrating "rep-cache database locked" error.

Is Using Azure Files via CIFS for Subversion Repos a Valid Approach? #

Short answer: It’s possible, but not ideal. Subversion is heavily optimized for local, POSIX-compliant file systems that support consistent file locking, immediate write synchronization, and reliable byte-range operations. Azure Files’ CIFS implementation works for basic file storage, but it has limitations with the low-level file system behaviors Subversion (and its underlying SQLite rep-cache) relies on. That said, with the right configuration tweaks, you can make it work—let’s get there.

Diagnosing the Error #

Your error logs pointing to SQLite database locks and zero-size files tell us two key things:

1. The CIFS mount isn’t handling file locking/synchronization correctly for SQLite’s needs.
2. Write operations are either being truncated or not fully committed to Azure Files, resulting in those empty files.

Here’s how to dig deeper:

• Check CIFS mount parameters: Default CIFS mounts often use client-side caching and async writes, which break Subversion’s consistency requirements.
• Validate rep-cache integrity: The rep-cache.db file in your repo’s db/ directory is likely corrupted or stuck in a locked state due to CIFS sync issues.
• Test basic file operations: Create, edit, and delete files in the mounted directory as the www-data user (Apache’s run user) to confirm permissions and write reliability—if you still get zero-size files, the mount config is the culprit.

Fixing the Issue #

Let’s walk through actionable fixes, starting with the most impactful:

1. Adjust CIFS Mount Parameters for Subversion Compatibility #

Edit your /etc/fstab entry for the Azure Files mount to add critical parameters that enforce consistency and disable problematic locking:

//your-storage-account.file.core.windows.net/your-share /mnt/svn-repos cifs credentials=/etc/smbcredentials,dir_mode=0775,file_mode=0775,nobrl,sync,actimeo=0 0 0

Let’s break down these parameters:

• nobrl: Disables byte-range locking (Azure Files CIFS has limited support for this, which SQLite relies on for rep-cache)
• sync: Forces all writes to be immediately synced to Azure Files instead of cached locally
• actimeo=0: Disables client-side file attribute caching to ensure real-time consistency
• dir_mode=0775/file_mode=0775: Ensures Apache’s www-data user has read/write access to the repo files

After updating fstab, remount the share to apply changes:

sudo umount /mnt/svn-repos && sudo mount /mnt/svn-repos

2. Repair or Reset the Rep-Cache Database #

The corrupted rep-cache.db is likely causing the lock errors. First, check its integrity with SQLite:

sqlite3 /path/to/your/repo/db/rep-cache.db "PRAGMA integrity_check;"

If the check returns errors, back up the file then delete it—Subversion will automatically rebuild a fresh rep-cache when the repo is accessed next:

sudo cp /path/to/your/repo/db/rep-cache.db /path/to/backup/rep-cache.db.bak
sudo rm /path/to/your/repo/db/rep-cache.db

Restart Apache to apply changes:

sudo systemctl restart apache2

3. Disable Rep-Cache (Temporary Workaround) #

If adjusting mount parameters doesn’t resolve the issue immediately, you can disable rep-cache entirely to bypass the SQLite lock problem. Edit your Apache mod_dav_svn.conf file and add the norepcache option to your repo configuration block:

<Location /svn>
    DAV svn
    SVNParentPath /mnt/svn-repos
    SVNReposOptions "norepcache"
    # ... your existing SSL/permission configs ...
</Location>

Restart Apache, then test commits again. Note: Disabling rep-cache will impact repo performance, so this should only be a temporary fix while you refine the mount configuration.

4. Verify Permissions and Mount Stability #

Double-check that the www-data user has full access to the mounted repo directory:

sudo chown -R www-data:www-data /mnt/svn-repos
sudo chmod -R 0775 /mnt/svn-repos

Test basic write operations as www-data to confirm no zero-size files are created:

sudo -u www-data touch /mnt/svn-repos/test-file.txt
sudo -u www-data echo "test content" > /mnt/svn-repos/test-file.txt
cat /mnt/svn-repos/test-file.txt

If the file has content and isn’t zero-sized, the mount is working correctly now.

Final Notes #

While Azure Files via CIFS can work for Subversion, it’s not the most performant or reliable long-term solution. For production use, consider:

• Hosting repos on an Azure VM’s local managed disk (far more consistent for Subversion’s needs)
• Using a managed Subversion service like Azure DevOps Repos
• Switching to a distributed version control system like Git, which is more tolerant of network file systems

内容的提问来源于stack exchange，提问作者Pete Burch