Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
James Youngman wrote: This version should be race-free: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums 21 I think that writing into a pipe should be OK, since pipes are non-seekable. However, with pipes in this situation you still have a problem if processes try to write more than PIPE_BUF bytes. You aren't using a pipe there. What you are doing is having the shell open the file, then the md5sum processes all inherit that fd so they all share the same offset. As long as they write() the entire line at once, the file pointer will be updated atomically for all processes and the lines from each process won't clobber each other. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-7.0 df test failures
Today Ondřej reported that this koji build detected two df failures:
http://koji.fedoraproject.org/koji/getfile?taskID=928155name=build.log
Both failed like this:
FAIL: df/total.log (exit: 1)
...
+ fail=0
+ umask 22
+ RE_TOTAL='^total( +(-?[0-9]+|-)){3} +-?[0-9]+%$'
+ df
+ /bin/grep -E '^total( +(-?[0-9]+|-)){3} +-?[0-9]+%$' tmp
df: cannot read table of mounted file systems
FAIL: df/total-awk.log (exit: 1)
...
+ df --total -P --block-size=512
+ tee space
df: cannot read table of mounted file systems
Here's a fix to avoid the failure and to cause the test to
be skipped, as intended:
diff --git a/tests/df/total-verify b/tests/df/total-verify
index 5b58565..caf6d1a 100755
--- a/tests/df/total-verify
+++ b/tests/df/total-verify
@@ -54,8 +54,10 @@ EOF
# Use --block-size=512 to keep df from printing rounded-to-kilobyte
# numbers which wouldn't necessarily add up to the displayed total.
-df --total -P --block-size=512 |tee space || framework_failure
-df --total -i -P |tee inode || framework_failure
+df --total -P --block-size=512 space || framework_failure
+cat space # this helps when debugging any test failure
+df --total -i -Pinode || framework_failure
+cat inode
fail=0
$PERL -f check-df space || fail=1
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
sobre RSS
Hola, buenos días: Necesito borrar vía SSH el archivo que se encuentra en $QMAIL_ROOT_D/qmail/control/ pero como soy novata no se como hacerlo, ¿me podrías decir que he de escribir en la linea de comandos ? o algún enlace en español que me indique como hacerlo?? Gracias y un saludo Susana Terradellas Webmaster de Idea Publicidad Tel.: 964 22 70 12 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Ondřej Vašík [EMAIL PROTECTED] wrote: as reported in https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron Toponce , chmod could display confusing messages when used for SGID/SUID/sticky bits without permissions to change them. e.g. with non-root sudoers user following scenario mkdir tmp;sudo chown .root tmp;ls -ld tmp;chmod -v 2755 tmp;ls -ld tmp; would lead to: drwxrwxr-x 2 Reset root 4096 24. říj 17.33 tmp mode of `tmp' changed to 2755 (rwxr-sr-x) drwxr-xr-x 2 Reset root 4096 24. říj 17.33 tmp So user is informed that sticky bit was set even if it was not. This is a good excuse to start the process. Note this TODO item: remove or adjust chown's --changes option, since it can't always do what it currently says it does. Almost from the beginning, I've wanted to remove support for --changes (-c) from chmod, chown and chgrp. Note that the original chcon implementation had that option, but I removed it as part of the big SELinux-support-adding changes. So, rather than trying to fix --changes, I'm leaning towards starting the process to remove it altogether. From chmod, chown, and chgrp. This may seem extreme, until you realize that the option is inherently inaccurate in some cases. And the only way it can be accurate is if PROG --changes ... were to stat each file after operating on it. I.e., the current implementations, even with your patch, can still produce misleading output. FYI, it's telling to see that when I ripped out all support for chmod's --verbose and --changes options (just to see), all tests still passed. Of course, I wouldn't do that for real. We'd have to first deprecate the targeted options, making any use provoke a warning, and then -- years later -- un-document and finally, remove them. And I probably wouldn't even deprecate --verbose. What do you think? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
[ CC ++ [EMAIL PROTECTED] ] On Tue, Nov 11, 2008 at 2:58 PM, Andrew McGill [EMAIL PROTECTED] wrote: What would you expect this to do --: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums Produce a race condition :)It generates 16 parallel processes, each writing to the md5sums file. Unfortunately sometimes the writes occur at the same offset in the output file. To illustrate: ~$ strace -f -e open,fork,execve sh -c echo hello foo execve(/bin/sh, [sh, -c, echo hello foo], [/* 39 vars */]) = 0 [...] open(foo, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 ~$ strace -f -e open,fork,execve sh -c echo hello foo execve(/bin/sh, [sh, -c, echo hello foo], [/* 39 vars */]) = 0 [...] open(foo, O_WRONLY|O_CREAT|O_APPEND, 0666) = 3 This version should be race-free: find -type f -print0 | xargs -0 -n 8 --max-procs=16 md5sum ~/md5sums 21 I think that writing into a pipe should be OK, since pipes are non-seekable. However, with pipes in this situation you still have a problem if processes try to write more than PIPE_BUF bytes. Is there a correct way to do md5sums in parallel without having a shared output buffer which eats output (I presume) -- or is losing output when haphazardly combining output streams actually strange and unusual? I hope the solution about solved your problem - and please follow up if so. This example is probably worthy of being mentioned in the xargs documentation, too. Thanks for your comment! James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
