Re: deref-args test and nfs
Kevin Mudrick [EMAIL PROTECTED] wrote: The make check deref-args test seems to fail on an nfs-mounted directory where attribute-caching is turned on, due to the block size including some extra information besides the file. Using du -bkD slink-to-64k instead, to rely on the file size rather than number of blocks, seems to work fine though. Thanks for the report! I've made this change: 2005-06-21 Jim Meyering [EMAIL PROTECTED] * tests/du/deref-args: Use --apparent-size to avoid the vagaries of counting blocks. Kevin Mudrick reported that this test would fail on an nfs-mounted directory where attribute-caching is turned on. Index: tests/du/deref-args === RCS file: /fetish/cu/tests/du/deref-args,v retrieving revision 1.6 retrieving revision 1.7 diff -u -p -u -r1.6 -r1.7 --- tests/du/deref-args 30 Jun 2004 22:51:11 - 1.6 +++ tests/du/deref-args 21 Jun 2005 08:45:19 - 1.7 @@ -34,10 +34,10 @@ du -D slink | sed 's/^[0-9][0-9]* //' du -D slink/ | sed 's/^[0-9][0-9]* //' out # Ensure that -D makes du dereference even symlinks to non-directories. -# The sed command maps the 68 I get on an ext3 file system to the 64 I expected. -# On tmpfs, I get 64. Similarly, on SELinux-enabled systems, file security -# context labels take up file system space, making du print 72 here. -du -kD slink-to-64k | sed 's/^[67][0-9]/64/' out +# Be sure to use --apparent-size. Otherwise, we'd get varying block counts +# depending on file system type (e.g. 68 on ext3 vs. 64 on tmpfs and 72 +# on SELinux-enabled systems). +du --apparent-size --block-size=1K -D slink-to-64k out cat \EOF exp slink/a slink ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: digest algorithm performance
[EMAIL PROTECTED] wrote: ... OK, I'll have a look. FreeBSD seems to be faster again, (don't compare these results to the previous mail): [I've just noticed you used `sha1' below. Is that a shell alias or function? The program from coreutils is called sha1sum. ] $time sha1 15MBfile 51e673b839d5bee3293fa2f1dd58c69face9770a ... $time openssl sha1 15MBfile 51e673b839d5bee3293fa2f1dd58c69face9770a ... FYI, here are a few more data points: On an AMD-64 system, using a 700MB file on a tmpfs file system (and enough RAM so that no actual disk reads are performed), GNU md5sum is slightly faster than `openssl md5', e.g.: 2.38s user 0.38s system 100% cpu 2.756 total (gnu md5sum) vs. 2.52s user 0.34s system 100% cpu 2.869 total However, `openssl sha1' is about 5% faster than GNU sha1sum: 3.32s user 0.33s system 99% cpu 3.653 total (openssl sha1) 3.45s user 0.39s system 99% cpu 3.843 total (gnu sha1sum) The above are using the debian-sid (amd_64 alioth) binaries from coreutils-5.2.1. When I compile the latest (coreutils-cvs) with gcc-4.0 -O3, I get slightly (2-3%) better sha1sum performance, and a ~7% *decrease* in performance for md5sum. I suspect that with the right compiler options you can do much better. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: digest algorithm performance
As ever I haven't had time to look at this yet. comments below... Jim Meyering wrote: [EMAIL PROTECTED] wrote: ... OK, I'll have a look. FreeBSD seems to be faster again, (don't compare these results to the previous mail): [I've just noticed you used `sha1' below. Is that a shell alias or function? The program from coreutils is called sha1sum. ] I was referring to the seperate FreeBSD sha1 utility. Note be careful when testing that as reading from stdin causes 16KiB reads while reading from file causes 1KiB reads (or whatever the block size of the filesystem is I guess?). FYI, here are a few more data points: On an AMD-64 system, using a 700MB file on a tmpfs file system (and enough RAM so that no actual disk reads are performed), GNU md5sum is slightly faster than `openssl md5', e.g.: 2.38s user 0.38s system 100% cpu 2.756 total (gnu md5sum) vs. 2.52s user 0.34s system 100% cpu 2.869 total However, `openssl sha1' is about 5% faster than GNU sha1sum: 3.32s user 0.33s system 99% cpu 3.653 total (openssl sha1) 3.45s user 0.39s system 99% cpu 3.843 total (gnu sha1sum) The above are using the debian-sid (amd_64 alioth) binaries from coreutils-5.2.1. When I compile the latest (coreutils-cvs) with gcc-4.0 -O3, I get slightly (2-3%) better sha1sum performance, and a ~7% *decrease* in performance for md5sum. I suspect that with the right compiler options you can do much better. have a look at http://www.pixelbeat.org/scripts/gcccpuopt Note the openssl sha1 performance is highly dependent on CPU. The following is a comment in openssl 0.9.7: It was noted that Intel IA-32 C compiler generates code which performs ~30% *faster* on P4 CPU than original *hand-coded* SHA1 assembler implementation. To address this problem (and prove that humans are still better than machines:-), the original code was overhauled, which resulted in following performance changes: compared with original compared with Intel cc assembler impl. generated code Pentium -16%+48% PIII/AMD +8% +16% P4+85%(!) +45% I did a little testing of various sha1 implementations on my fedora core 3 1.6GHz P4 laptop and got: openssl-0.9.7a-40 = 0.220s sha1sum = 0.350s SteveReid (-march=pentium4 -O3) = 0.334s gladman (-march=pentium4 -O3) = 0.310s Next to compare is the BSD sha1 code... -- Pádraig Brady - http://www.pixelbeat.org -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Maybe a bug
nosair wrote: scp -r [EMAIL PROTECTED]:~/* ~/ECEJUNE2006 | tee transfer_june_2006.txt I get the prompt for password. After that, the downloading of files and folders begins as normal. However, the file transfer information does not show on screen, and transfer_june_2006.txt remains empty during the downloading. This is not a bug. scp will not print any progress output if the standard output is not a tty. Even if it did, you would probably not like the result since it prints a line to the screen every second, prefixed with a \r so that each successive line overwrites the next. If you redirected that to a file you would get a bunch of nonsense when you tried to view it later. You can actually do this with the 'script' utility, which simulates a tty to the command with a pseudoterminal: script transfer_june_2006.txt scp -r [EMAIL PROTECTED]:~/* ~/whatever However, when you view the .txt file with 'less' it will likely be fairly unintelligible, certainly not a plain text log. Though if you 'cat' it to a terminal you will recreate the scp output in fast-forward mode. Brian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp-parents test and ACLs
The cp-parents test fails when local filesystem ACLs override umask. However, chmod still works fine. Since the test seems to be checking whether the permissions are maintained when using cp -a, chmod seems to be an alternate approach. --- coreutils-5.2.1/tests/cp/cp-parents 2002-10-08 05:20:06.0 -0400 +++ coreutils-5.2.1-patched/tests/cp/cp-parents 2005-06-21 11:14:58.701351000 -0400 @@ -31,6 +31,10 @@ mkdir foo bar || framework_failure=1 mkdir -p a/b/c d e || framework_failure=1 +# umask can fail to set correctly on systems with ACLs +# chmod, on the other hand, works +chmod 755 a a/b a/b/c d e + if test $framework_failure = 1; then echo 'failure in testing framework' exit 1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
