Stefan Krah added the comment:
I don't know whether this is worth reopening, but the ecryptfs
performance is still very poor on my Lenovo T400 (see #24831).
For most people an extra option for choosing the tmpdir
would not help, since they'd simply blame the hardware
or the test suite.
Barry A. Warsaw added the comment:
I'm going to close this issue as invalid; it hasn't affected me on ecryptfs
$HOME on Ubuntu in a long time, so let's chalk it up to better ecryptfs
implementations now.
If you disagree, feel free to re-open this and provide more information.
--
resol
Jason Gerard DeRose added the comment:
Oops, I think I don't understand the meaning of top CPU usage, as time tells a
different story.
Direct ext4:
real2m14.144s
user0m0.260s
sys 0m30.350s
ecryptfs over ext4:
real8m47.130s
user0m0.080s
sys 7m2.080s
--
___
Jason Gerard DeRose added the comment:
Barry,
I'm suspicious there might be more to the performance issue than just the
ecryptfs overhead. While experimenting with a read benchmark, I just happened
to notice that when reading from an ecryptfs filesystem, the CPU usage is
unusually high in t
Nick Coghlan added the comment:
To control where mkdtemp() puts files, you could just use the "dir" argument
(and you can use tempfile.gettempdir() beforehand if you want that location to
be inside the normal temp directory)
--
___
Python tracker
Nick Coghlan added the comment:
If support for a top level temporary directory is added, test.support should
acquire alternatives to the tempfile module tools to make it easy for tests
that create their own temporary files to respect that naming scheme. In
particular, test.script_helper.temp_
Barry A. Warsaw added the comment:
Antoine, -P is fine with me!
Also, since my idea is that --usetmp/-P would just use the mkdtemp() algorithm
(which looks for $TMPDIR, $TEMP or $TMP), getting the build into a
subdirectory, e.g. /tmp/test_python would be as easy as setting
TMP=/tmp/test_pyth
Antoine Pitrou added the comment:
> Makes sense. So, what do you think about adding a --usetmp/-p flag to
> regrtest to honor mkdtemp's defaults even in a build dir? I'd add an
> atexit handler to clean it up but of course if it crashes and you've
> used the flag, you should know enough to be
Barry A. Warsaw added the comment:
Makes sense. So, what do you think about adding a --usetmp/-p flag to regrtest
to honor mkdtemp's defaults even in a build dir? I'd add an atexit handler to
clean it up but of course if it crashes and you've used the flag, you should
know enough to be able
Antoine Pitrou added the comment:
One strong reason for having the test files in the build directory is ease of
cleanup, especially on the buildbots where crashes or hangs can lead to
progressive disk fillup (and some tests create very large files, e.g. 2GB).
See also 673a5afce4e0.
-
Ned Deily added the comment:
(Addressing your aside: one case where the tests are not run in a build
directory is with binary installers. For instance, the Mac OS X installers we
provide include all of the test modules and it is normal to run them after
installation, quite possibly on a syst
New submission from Barry A. Warsaw :
When your home directory is on a Linux (e.g. Ubuntu 10.10) ecryptfs, 'make
test' and company can be horrendously slow. Of course, some performance hit
should be expected, but depending on which combinations of tests I've run, I
can see up to 25000x (!) sl
12 matches
Mail list logo
