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.
--
Jason Gerard DeRose jder...@novacut.com 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
Jason Gerard DeRose jder...@novacut.com 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
Barry A. Warsaw ba...@python.org 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
Nick Coghlan ncogh...@gmail.com 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,
Nick Coghlan ncogh...@gmail.com 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)
--
___
Antoine Pitrou pit...@free.fr 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
Barry A. Warsaw ba...@python.org 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
Antoine Pitrou pit...@free.fr 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
New submission from Barry A. Warsaw ba...@python.org:
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
Ned Deily n...@acm.org 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
12 matches
Mail list logo
