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 <philip_at_codematters.co.uk>
wrote:
> Paul Hammant <paul_at_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
>
Received on 2017-07-15 15:09:21 CEST