> Are you running Linux or Windows? Is the disk local or networked?
Server is Debian 9.3. Disk is mounted through fstab with options noatime,nodiratime,data=ordered,nofail.
> Do you have some other process running that mointors the filesystem or
> the repository? Does it actively delete files?
I am quite sure there is nothing of that kind. Server is a minimal Debian install. Only Apache processes run as www-data. There is only a post-commit hook for Trac (which was disabled during at least one try. Also, post-commit shouldn't be called until commit finishes.) Furthermore, that mount is only given access to dav_svn in apache2 config.
On 20 February 2018 at 19:14, Philip Martin <philip_at_codematters.co.uk<mailto:philip_at_codematters.co.uk>> wrote:
Davor Josipovic <davorj_at_live.com<mailto:davorj_at_live.com>> writes:
>> Do you see the DELETE in the log after the failed MERGE? Was there an
>> error?
>
> The apache2 log I posted is the whole log for that day as far as I
> recall. There was nothing else. You see the DELETE error before the
> MERGE error. I think that is due to a timing issue. In my previous
> tries (there were transaction 463-e1 up to 463-e9...) the MERGE would
> sometimes show before the DELETE in the error log. That is what let me
> believe that MERGE error was primary, then the DELETE error (even
> though it seems the other way around in the apache2 log).
Sorry, missed that. The DELETE error is interesting:
[Sat Feb 10 03:25:16.265923 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0' [500, #2]
[Sat Feb 10 03:25:16.265940 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove file '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0': No such file or directory [500, #2]
DELETE uses low-level IO rather than parsing the transaction files.
Subversion simply does readdir() to get a list of children and then
loops deleting them. If readdir() returns a name that does not exist
then either the disk/filesystem is corrupt or some other process has
deleted the file between the readdir() and the delete attempt.
Corruption seems unlikely since you say you have moved filesystems. We
are left with some other process deleting files while apache is
attempting to access them.
Do you have some other process running that mointors the filesystem or
the repository? Does it actively delete files?
>> What sort of filesystem hosts the repository?
>
> The filesystem for the reported transaction 463-e8 is EXT4 (noatime,
> nodiratime, data=ordered). Prior to that, the repository was on a NTFS
> formatted drive. The error was the same, but since I thought NTFS was
> the culprit, I moved to EXT4.
Are you running Linux or Windows? Is the disk local or networked?
--
Philip
Received on 2018-02-20 19:38:20 CET