Hey Philip, starting from scratch, I can reproduce "Can't find a temporary directory" errors in /var/log/apache2/error.log for PUT when the boot drive is pretty much full, and the repository's drive has 3 spare terabytes.
Can you tell me what to run concurrently that would help you be convinced too? Bear in mind I'm really a 22-year enterprise Java/JavaScript/Python developer who likes cosseted JetBrains edit/debug experiences, isn't at all savvy with the long list of tools gcc developers know well. Also, my machine is an Atom CPU with 4GB ram and a less than stellar perf 64GB SSD. - Paul On Fri, Jul 14, 2017 at 4:42 PM, Philip Martin <phi...@codematters.co.uk> wrote: > Paul Hammant <p...@hammant.org> writes: > > >> I don't believe Apache/mod_dav_svn uses TMPDIR when processing a PUT. > >> > > > > I can prove that either Apache or ModDavSvn (or the OS) uses TMPDIR > during > > a PUT of a very large resource. > > > > Test 1: leave 3GB free on system drive, try to PUT 15GB file thru DAV > into > > it's ultimate destination on a driver with 3TB of space. And observe an > > error (as I did before) > > > > Test 2: as #1 but with a TMPDIR export in /etc/apache2/envvars. No error > > during the PUT will be the observation. > > So what data gets written there? Which process writes it? When I use > curl to put a 15GB file into apache my /tmp stays at 92KB used. I don't > have TMPDIR set, I don't set TMPDIR for apache. > > I have also run > > strace -fetrace=open -p nnn > > on the apache process to see all the files opened by the apache process. > All the files opened are within the the repository itself except for > /dev/urandom. > > Incidentally, the 15GB upload takes 2min 4s. This is on a machine with > a core i5 4570 (circa 2013) processor and with the repository on a SATA > SSD. > > -- > Philip >
