Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
The following reply was made to PR bin/144411; it has been noted by GNATS. From: Garrett Cooper To: bug-follo...@freebsd.org, gcoo...@freebsd.org Cc: Subject: Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X Date: Tue, 30 Mar 2010 01:21:58 -0700 Hi, I'm not 100% satisfied with this patch now. Looking back it fails the following case: -PDo not follow symbolic links in the file hierarchy, instead con- sider the symbolic link itself in any comparisons. This is the default. I need to add a check for this option to the patch, use stat if the `follow links' state is true, otherwise use lstat. Thanks, -Garrett ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/145194: Changed output of sockstat for AF_INET6
>Number: 145194
>Category: bin
>Synopsis: Changed output of sockstat for AF_INET6
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 30 08:50:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Fedor Dikarev
>Release:6.x, 7.x and 8.x
>Organization:
Rambler
>Environment:
FreeBSD net.park.rambler.ru 7.2-STABLE FreeBSD 7.2-STABLE #1: Tue Jun 2
10:49:29 MSD 2009 r...@net.park.rambler.ru:/usr/obj/usr/src/sys/MNGMT amd64
>Description:
It's very hard to distinguish where local address and port ends and foreign
address and port starts from sockstat output when using IPv6 addressess.
One space between is enough as I think.
>How-To-Repeat:
root:net{R}[125] sockstat$ sockstat -6
www nginx 58211 9 tcp6
2a02:6b0:1:0:21a:92ff:fe80:f032:802a02:6b0:16:0:10cb:d0b0:7274:4cde:1145
.. and more such lines
>Fix:
Just add one space after local address and port. And get output like this:
root:net{R}[135] sockstat$ sockstat -6
www nginx 58211 12 tcp6 2a02:6b0:1:0:21a:92ff:fe80:f032:80
2a02:6b0:16:0:10cb:d0b0:7274:4cde:1170
Patch attached with submission follows:
--- sockstat.c 2010-03-30 12:37:25.0 +0400
+++ sockstat.c.orig 2010-03-30 12:22:06.0 +0400
@@ -609,7 +609,6 @@
case AF_INET:
case AF_INET6:
pos += printaddr(s->family, &s->laddr);
- if((AF_INET6 == s->family) && (pos>=58)) { xprintf("
"); }
while (pos < 58)
pos += xprintf(" ");
pos += printaddr(s->family, &s->faddr);
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/145194: Changed output of sockstat for AF_INET6
The following reply was made to PR bin/145194; it has been noted by GNATS.
From: Maxim Konovalov
To: Fedor Dikarev
Cc: bug-follo...@freebsd.org
Subject: Re: bin/145194: Changed output of sockstat for AF_INET6
Date: Tue, 30 Mar 2010 13:33:48 +0400 (MSD)
This one looks more correct, doesn't it?
Index: sockstat.c
===
--- sockstat.c (revision 205577)
+++ sockstat.c (working copy)
@@ -621,6 +621,8 @@
case AF_INET:
case AF_INET6:
pos += printaddr(s->family, &s->laddr);
+ if ((AF_INET6 == s->family) && (pos >= 58))
+ pos += xprintf(" ");
while (pos < 58)
pos += xprintf(" ");
pos += printaddr(s->family, &s->faddr);
%%%
--
Maxim Konovalov
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/145194: Changed output of sockstat for AF_INET6
Synopsis: Changed output of sockstat for AF_INET6 State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Tue Mar 30 09:58:35 UTC 2010 State-Changed-Why: Committed to HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=145194 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/145194: commit references a PR
The following reply was made to PR bin/145194; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/145194: commit references a PR
Date: Tue, 30 Mar 2010 09:58:35 + (UTC)
Author: maxim
Date: Tue Mar 30 09:58:21 2010
New Revision: 205874
URL: http://svn.freebsd.org/changeset/base/205874
Log:
o Make sockstat -6 output more readable for long ipv6
addresses (most of them apart from ::1): put a whitespace
between local and remote address:port pairs.
PR: bin/145194
Submitted by:Fedor Dikarev
MFC after: 2 weeks
Modified:
head/usr.bin/sockstat/sockstat.c
Modified: head/usr.bin/sockstat/sockstat.c
==
--- head/usr.bin/sockstat/sockstat.c Tue Mar 30 09:22:33 2010
(r205873)
+++ head/usr.bin/sockstat/sockstat.c Tue Mar 30 09:58:21 2010
(r205874)
@@ -621,6 +621,8 @@ display(void)
case AF_INET:
case AF_INET6:
pos += printaddr(s->family, &s->laddr);
+ if (s->family == AF_INET6 && pos >= 58)
+ pos += xprintf(" ");
while (pos < 58)
pos += xprintf(" ");
pos += printaddr(s->family, &s->faddr);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/145194: Changed output of sockstat for AF_INET6
The following reply was made to PR bin/145194; it has been noted by GNATS.
From: Fedor Dikarev
To: Maxim Konovalov
Cc: bug-follo...@freebsd.org
Subject: Re: bin/145194: Changed output of sockstat for AF_INET6
Date: Tue, 30 Mar 2010 13:38:51 +0400
30.03.2010 13:33, Maxim Konovalov пиÑеÑ:
> This one looks more correct, doesn't it?
>
> Index: sockstat.c
> ===
> --- sockstat.c (revision 205577)
> +++ sockstat.c (working copy)
> @@ -621,6 +621,8 @@
> case AF_INET:
> case AF_INET6:
> pos += printaddr(s->family, &s->laddr);
> +if ((AF_INET6 == s->family) && (pos >= 58))
> +pos += xprintf(" ");
> while (pos < 58)
> pos += xprintf(" ");
> pos += printaddr(s->family, &s->faddr);
>
> %%%
>
Yes, it'll be better -- I just hurry and made mistake through lack of
attention.
--
Fedor Dikarev
Rambler Internet Holding
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144644: [patch] Fix *alloc cornercases with config(1)
The following reply was made to PR bin/144644; it has been noted by GNATS. From: Ruslan Ermilov To: Garrett Cooper Cc: bug-follo...@freebsd.org Subject: Re: bin/144644: [patch] Fix *alloc cornercases with config(1) Date: Tue, 30 Mar 2010 14:34:26 +0400 On Sun, Mar 21, 2010 at 04:58:18AM -0700, Garrett Cooper wrote: > On Sat, Mar 13, 2010 at 12:36 AM, Garrett Cooper wrote: > > On Fri, Mar 12, 2010 at 11:28 PM, Garrett Cooper > > wrote: > >> The attached patch addresses the non-style(9) conformity with my > >> previous patch as pointed out by several folks on curr...@. > > > > Sorry -- missed a spot... > > The following patch incorporates a logical change from errx(3) to > err(3) made by ru@ in an informal review. I also picked up a few other > logical messages that were originally errx(EXIT_ERR, ...) and > converted them to err(EXIT_ERR, ...) in a similar fashion. Part of the changes are invalid (shouldn't have been converted from errx() to err()). : Index: main.c : === : --- main.c (revision 205872) : +++ main.c (working copy) : @@ -120,7 +120,7 @@ : if (*destdir == '\0') : strlcpy(destdir, optarg, sizeof(destdir)); : else : -errx(2, "directory already set"); : +err(EXIT_FAILURE, "directory already set"); : break; : case 'g': : debugging++; : @@ -175,7 +175,7 @@ : if (mkdir(p, 0777)) : err(2, "%s", p); : } else if (!S_ISDIR(buf.st_mode)) : -errx(2, "%s isn't a directory", p); : +err(EXIT_FAILURE, "%s isn't a directory", p); : : SLIST_INIT(&cputype); : SLIST_INIT(&mkopt); : @@ -519,7 +519,7 @@ : */ : p = strstr(kernconfstr, KERNCONFTAG); : if (p == NULL) : -errx(EXIT_FAILURE, "Something went terribly wrong!"); : +err(EXIT_FAILURE, "Something went terribly wrong!"); : *p = '\0'; : fprintf(fo, "%s", kernconfstr); : fprintf(fo, "%s", sbuf_data(sb)); : @@ -671,19 +673,19 @@ : [...] : if (S_ISDIR(st.st_mode)) : -errx(EXIT_FAILURE, "'%s' is a directory", file); : +err(EXIT_FAILURE, "'%s' is a directory", file); : fp = fdopen(r, "r"); : [...] : pp = popen(cmd, "r"); : if (pp == NULL) : -errx(EXIT_FAILURE, "popen() failed"); : +err(EXIT_FAILURE, "popen() failed"); This is questionable; see the popen(3) manpage for details, section ERRORS. : Index: lang.l : === : --- lang.l (revision 205872) : +++ lang.l (working copy) : @@ -31,6 +31,7 @@ : * $FreeBSD$ : */ : : +#include Misplaced include. : #include : #include : #include Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144644: [patch] Fix *alloc cornercases with config(1)
The following reply was made to PR bin/144644; it has been noted by GNATS. From: Garrett Cooper To: Ruslan Ermilov Cc: bug-follo...@freebsd.org Subject: Re: bin/144644: [patch] Fix *alloc cornercases with config(1) Date: Tue, 30 Mar 2010 04:46:28 -0700 --0016363105b72177dc0483032ec9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2010 at 3:34 AM, Ruslan Ermilov wrote: > On Sun, Mar 21, 2010 at 04:58:18AM -0700, Garrett Cooper wrote: >> On Sat, Mar 13, 2010 at 12:36 AM, Garrett Cooper w= rote: >> > On Fri, Mar 12, 2010 at 11:28 PM, Garrett Cooper = wrote: >> >> =A0 =A0The attached patch addresses the non-style(9) conformity with = my >> >> previous patch as pointed out by several folks on curr...@. >> > >> > Sorry -- missed a spot... >> >> =A0 =A0 The following patch incorporates a logical change from errx(3) t= o >> err(3) made by ru@ in an informal review. I also picked up a few other >> logical messages that were originally errx(EXIT_ERR, ...) and >> converted them to err(EXIT_ERR, ...) in a similar fashion. > > Part of the changes are invalid (shouldn't have been converted from > errx() to err()). > > : Index: main.c > : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > : --- main.c =A0 =A0(revision 205872) > : +++ main.c =A0 =A0(working copy) > : @@ -120,7 +120,7 @@ > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (*destdir =3D=3D '\0') > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strlcpy(des= tdir, optarg, sizeof(destdir)); > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > : - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errx(2, "dire= ctory already set"); > : + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(EXIT_FAIL= URE, "directory already set"); > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 case 'g': > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 debugging++; > : @@ -175,7 +175,7 @@ > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (mkdir(p, 0777)) > : =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(2, "%s", p); > : =A0 =A0 =A0 } else if (!S_ISDIR(buf.st_mode)) > : - =A0 =A0 =A0 =A0 =A0 =A0 errx(2, "%s isn't a directory", p); > : + =A0 =A0 =A0 =A0 =A0 =A0 err(EXIT_FAILURE, "%s isn't a directory", p); > : > : =A0 =A0 =A0 SLIST_INIT(&cputype); > : =A0 =A0 =A0 SLIST_INIT(&mkopt); > : @@ -519,7 +519,7 @@ > : =A0 =A0 =A0 =A0*/ > : =A0 =A0 =A0 p =3D strstr(kernconfstr, KERNCONFTAG); > : =A0 =A0 =A0 if (p =3D=3D NULL) > : - =A0 =A0 =A0 =A0 =A0 =A0 errx(EXIT_FAILURE, "Something went terribly w= rong!"); > : + =A0 =A0 =A0 =A0 =A0 =A0 err(EXIT_FAILURE, "Something went terribly wr= ong!"); > : =A0 =A0 =A0 *p =3D '\0'; > : =A0 =A0 =A0 fprintf(fo, "%s", kernconfstr); > : =A0 =A0 =A0 fprintf(fo, "%s", sbuf_data(sb)); > : @@ -671,19 +673,19 @@ > : [...] > : =A0 =A0 =A0 if (S_ISDIR(st.st_mode)) > : - =A0 =A0 =A0 =A0 =A0 =A0 errx(EXIT_FAILURE, "'%s' is a directory", fil= e); > : + =A0 =A0 =A0 =A0 =A0 =A0 err(EXIT_FAILURE, "'%s' is a directory", file= ); > : =A0 =A0 =A0 fp =3D fdopen(r, "r"); > : [...] > : =A0 =A0 =A0 pp =3D popen(cmd, "r"); > : =A0 =A0 =A0 if (pp =3D=3D NULL) > : - =A0 =A0 =A0 =A0 =A0 =A0 errx(EXIT_FAILURE, "popen() failed"); > : + =A0 =A0 =A0 =A0 =A0 =A0 err(EXIT_FAILURE, "popen() failed"); > > This is questionable; see the popen(3) manpage for details, > section ERRORS. > > : Index: lang.l > : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > : --- lang.l =A0 =A0(revision 205872) > : +++ lang.l =A0 =A0(working copy) > : @@ -31,6 +31,7 @@ > : =A0 * $FreeBSD$ > : =A0 */ > : > : +#include > > Misplaced include. > > : =A0#include > : =A0#include > : =A0#include Hi Ruslan! Thanks for the review! This should resolve all of the issues you spotted before, as well as fixes a typo in a comment near one of the changes that I spotted before. Cheers, -Garrett --0016363105b72177dc0483032ec9 Content-Type: text/plain; charset=US-ASCII; name="config-failure-corner-cases.diff.txt" Content-Disposition: attachment; filename="config-failure-corner-cases.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g7en65jh0 SW5kZXg6IG1rb3B0aW9ucy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG1rb3B0aW9ucy5jCShyZXZpc2lvbiAy MDU4NzEpCisrKyBta29wdGlvbnMuYwkod29ya2luZyBjb3B5KQpAQCAtNzAsNiArNzAsOCBAQAog CS8qIEZha2UgdGhlIGNwdSB0eXBlcyBhcyBvcHRpb25zLiAqLwogCVNMSVNUX0ZPUkVBQ0goY3As ICZjcHV0eXBlLCBjcHVfbmV4dCkgewogCQlvcCA9IChzdHJ1Y3Qgb3B0ICopY2FsbG9jKDEsIHNp emVvZigqb3ApKTsKKwkJaWYgKG9wI
Re: bin/144644: [patch] Fix *alloc cornercases with config(1)
Synopsis: [patch] Fix *alloc cornercases with config(1) State-Changed-From-To: open->closed State-Changed-By: ru State-Changed-When: Tue Mar 30 13:47:55 UTC 2010 State-Changed-Why: Patch committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=144644 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144644: commit references a PR
The following reply was made to PR bin/144644; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/144644: commit references a PR
Date: Tue, 30 Mar 2010 13:46:51 + (UTC)
Author: ru
Date: Tue Mar 30 13:46:40 2010
New Revision: 205880
URL: http://svn.freebsd.org/changeset/base/205880
Log:
- Handle calloc() allocation failures.
- Fixed a comment.
- 2 -> EXIT_FAILURE in some places.
- errx() -> err() where appropriate.
PR: 144644
Submitted by:Garrett Cooper
Modified:
head/usr.sbin/config/config.y
head/usr.sbin/config/lang.l
head/usr.sbin/config/main.c
head/usr.sbin/config/mkmakefile.c
head/usr.sbin/config/mkoptions.c
Modified: head/usr.sbin/config/config.y
==
--- head/usr.sbin/config/config.y Tue Mar 30 12:08:00 2010
(r205879)
+++ head/usr.sbin/config/config.y Tue Mar 30 13:46:40 2010
(r205880)
@@ -166,6 +166,8 @@ Config_spec:
CPU Save_id {
struct cputype *cp =
(struct cputype *)calloc(1, sizeof (struct cputype));
+ if (cp == NULL)
+ err(EXIT_FAILURE, "calloc");
cp->cpu_name = $2;
SLIST_INSERT_HEAD(&cputype, cp, cpu_next);
} |
@@ -197,6 +199,8 @@ Config_spec:
struct hint *hint;
hint = (struct hint *)calloc(1, sizeof (struct hint));
+ if (hint == NULL)
+ err(EXIT_FAILURE, "calloc");
hint->hint_name = $2;
STAILQ_INSERT_TAIL(&hints, hint, hint_next);
hintmode = 1;
@@ -331,6 +335,8 @@ newfile(char *name)
struct files_name *nl;
nl = (struct files_name *) calloc(1, sizeof *nl);
+ if (nl == NULL)
+ err(EXIT_FAILURE, "calloc");
nl->f_name = name;
STAILQ_INSERT_TAIL(&fntab, nl, f_next);
}
@@ -364,6 +370,8 @@ newdev(char *name)
}
np = (struct device *) calloc(1, sizeof *np);
+ if (np == NULL)
+ err(EXIT_FAILURE, "calloc");
np->d_name = name;
STAILQ_INSERT_TAIL(&dtab, np, d_next);
}
@@ -422,6 +430,8 @@ newopt(struct opt_head *list, char *name
}
op = (struct opt *)calloc(1, sizeof (struct opt));
+ if (op == NULL)
+ err(EXIT_FAILURE, "calloc");
op->op_name = name;
op->op_ownfile = 0;
op->op_value = value;
Modified: head/usr.sbin/config/lang.l
==
--- head/usr.sbin/config/lang.lTue Mar 30 12:08:00 2010
(r205879)
+++ head/usr.sbin/config/lang.lTue Mar 30 13:46:40 2010
(r205880)
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
#include "y.tab.h"
#include "config.h"
@@ -220,6 +221,8 @@ cfgfile_add(const char *fname)
struct cfgfile *cf;
cf = calloc(1, sizeof(*cf));
+ if (cf == NULL)
+ err(EXIT_FAILURE, "calloc");
assert(cf != NULL);
asprintf(&cf->cfg_path, "%s", fname);
STAILQ_INSERT_TAIL(&cfgfiles, cf, cfg_next);
Modified: head/usr.sbin/config/main.c
==
--- head/usr.sbin/config/main.cTue Mar 30 12:08:00 2010
(r205879)
+++ head/usr.sbin/config/main.cTue Mar 30 13:46:40 2010
(r205880)
@@ -120,7 +120,7 @@ main(int argc, char **argv)
if (*destdir == '\0')
strlcpy(destdir, optarg, sizeof(destdir));
else
- errx(2, "directory already set");
+ errx(EXIT_FAILURE, "directory already set");
break;
case 'g':
debugging++;
@@ -175,7 +175,7 @@ main(int argc, char **argv)
if (mkdir(p, 0777))
err(2, "%s", p);
} else if (!S_ISDIR(buf.st_mode))
- errx(2, "%s isn't a directory", p);
+ errx(EXIT_FAILURE, "%s isn't a directory", p);
SLIST_INIT(&cputype);
SLIST_INIT(&mkopt);
@@ -256,7 +256,7 @@ get_srcdir(void)
int i;
if (realpath("../..", srcdir) == NULL)
- errx(2, "Unable to find root of source tree");
+ err(EXIT_FAILURE, "Unable to find root of source tree");
if ((pwd = getenv("PWD")) != NULL && *pwd == '/' &&
(pwd = strdup(pwd)) != NULL) {
/* Remove the last two path components. */
@@ -513,7 +513,7 @@ configfile(void)
}
sbuf_finish(sb);
/*
- * We print first part of the tamplate, replace our tag with
+ * We print first part of the template, repl
Re: bin/145063: [patch] powerd(8): Add -m and -M (minimum and maximum frequency) options to powerd
Synopsis: [patch] powerd(8): Add -m and -M (minimum and maximum frequency) options to powerd Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 30 13:52:32 UTC 2010 Responsible-Changed-Why: Submitter has requested review from acpi group. http://www.freebsd.org/cgi/query-pr.cgi?pr=145063 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/145205: UFOAI fails to compile due to jpeg error
>Number: 145205 >Category: misc >Synopsis: UFOAI fails to compile due to jpeg error >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 30 14:10:05 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Rusty Nejdl >Release:8-STABLE AMD64 >Organization: >Environment: FreeBSD tethys.ringofsaturn.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Mar 12 10:39:31 CST 2010 r...@tethys.ringofsaturn.com:/usr/obj/usr/src/sys/SATURN amd64 >Description: UFOAI fails to compile with the following error: src/renderer/r_image.c:283: warning: 'width' is deprecated (declared at /usr/local/include/png.h:633) src/renderer/r_image.c:283: warning: 'height' is deprecated (declared at /usr/local/include/png.h:634) src/renderer/r_image.c:284: warning: 'height' is deprecated (declared at /usr/local/include/png.h:634) src/renderer/r_image.c:285: warning: 'rowbytes' is deprecated (declared at /usr/local/include/png.h:637) src/renderer/r_image.c:285: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) src/renderer/r_image.c:286: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) src/renderer/r_image.c:293: warning: 'width' is deprecated (declared at /usr/local/include/png.h:633) src/renderer/r_image.c:295: warning: 'height' is deprecated (declared at /usr/local/include/png.h:634) src/renderer/r_image.c:296: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) src/renderer/r_image.c: At top level: src/renderer/r_image.c:655: error: conflicting types for 'jpeg_mem_src' /usr/local/include/jpeglib.h:959: error: previous declaration of 'jpeg_mem_src' was here gmake: *** [release-freebsd-unknown/client/renderer/r_image.o] Error 1 *** Error code 1 Stop in /usr/ports/games/ufoai. *** Error code 1 Stop in /usr/ports/games/ufoai. Exit 1 >How-To-Repeat: Try to compile ufoai. >Fix: Some work has been started for netbsd: http://mail-index.netbsd.org/pkgsrc-bugs/2010/01/30/msg035807.html But that is not the complete fix. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/145205: games/ufoai fails to compile due to jpeg error
Old Synopsis: UFOAI fails to compile due to jpeg error New Synopsis: games/ufoai fails to compile due to jpeg error Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 30 14:42:11 UTC 2010 Responsible-Changed-Why: fix category and synopsis. http://www.freebsd.org/cgi/query-pr.cgi?pr=145205 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/145211: Memory modified after free
>Number: 145211 >Category: kern >Synopsis: Memory modified after free >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 30 15:50:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Nathaniel Filardo >Release:9.0-CURRENT >Organization: >Environment: FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #19: Mon Mar 29 18:21:58 EDT 2010 r...@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN sparc64 >Description: Kernel panic. No dump to disk is made. Moreover, despite having KDB turned on, the system did not drop to a db> prompt. login: Memory modified after free 0xf80019f97000(2048) val=dead0003 @ 0xf80019f97000 Memory modified after free 0xf8000569f000(2048) val=dead0003 @ 0xf8000569f000 Memory modified after free 0xf80005686800(2048) val=dead0003 @ 0xf80005686800 Memory modified after free 0xf800056dd800(2048) val=dead0003 @ 0xf800056dd800 Memory modified after free 0xf800054ba800(2048) val=dead0003 @ 0xf800054ba800 Memory modified after free 0xf8000565b000(2048) val=dead0003 @ 0xf8000565b000 Memory modified after free 0xf80005609800(2048) val=dead0003 @ 0xf80005609800 Memory modified after free 0xf80005608000(2048) val=dead0003 @ 0xf80005608000 Memory modified after free 0xf80005695800(2048) val=dead0003 @ 0xf80005695800 Memory modified after free 0xf8000563e800(2048) val=dead0003 @ 0xf8000563e800 Memory modified after free 0xf800055c2000(2048) val=dead0003 @ 0xf800055c2000 Memory modified after free 0xf80019f77800(2048) val=dead0003 @ 0xf80019f77800 Memory modified after free 0xf8001920b000(2048) val=dead0003 @ 0xf8001920b000 Memory modified after free 0xf80019fae000(2048) val=dead0003 @ 0xf80019fae000 Memory modified after free 0xf800055a6800(2048) val=dead0003 @ 0xf800055a6800 Memory modified after free 0xf8000565e000(2048) val=dead0003 @ 0xf8000565e000 Memory modified after free 0xf80005641800(2048) val=dead0003 @ 0xf80005641800 Memory modified after free 0xf80005675000(2048) val=dead0003 @ 0xf80005675000 Memory modified after free 0xf8000564c800(2048) val=dead0003 @ 0xf8000564c800 panic: pcib: PCI bus B error AFAR 0 AFSR 0 PCI CSR 0x10730b2aff IOMMU 0x3060003 STATUS 0x2a0 cpuid = 1 On pcib bus B I seem to have the following devices: pcib0: mem 0x4000ff0-0x4000ff0afff,0x4000fc1-0x4000fc1701f,0x7f6-0x7f600ff,0x4000ff8-0x4000ff8 irq 2035,2032,2033,2036,2019 on nexus0 pcib0: Tomatillo, version 4, IGN 0x1f, bus B, 66MHz pcib0: DVMA map: 0xc000 to 0xdfff 65536 entries pci0: on pcib0 pci0: on pcib0 bge0: mem 0x20-0x20,0x11-0x11 at device 2.0 on pci0 bge1: mem 0x40-0x40,0x12-0x12 at device 2.1 on pci0 atapci0: port 0x900-0x907,0x918-0x91b,0x910-0x917,0x908-0x90b,0x920-0x92f at device 13.0 on pci1 atapci0: [ITHREAD] atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance There's only a DVD drive attached to atapci0, and the driver for that is not loaded. pcib3: mem 0x4000ef0-0x4000ef0afff,0x4000ec1-0x4000ec1701f,0x7c6-0x7c600ff,0x4000ef8-0x4000ef8 irq 1907,1904,1905,1908,1893 on nexus0 pcib3: Tomatillo, version 4, IGN 0x1d, bus B, 66MHz pcib3: DVMA map: 0xc000 to 0xdfff 65536 entries pci3: on pcib3 bge2: mem 0x20-0x20,0x11-0x11 at device 2.0 on pci3 bge3: mem 0x40-0x40,0x12-0x12 at device 2.1 on pci3 atapci1: port 0x300-0x3ff mem 0x60-0x6f,0x80-0xbf at device 1.0 on pci3 ata8: on atapci1 ata9: on atapci1 ata10: on atapci1 ata11: on atapci1 ad0: 715404MB at ata8-master UDMA100 SATA 3Gb/s ad1: 715404MB at ata9-master UDMA100 SATA 3Gb/s ad2: 715404MB at ata10-master UDMA100 SATA 3Gb/s ad3: 715404MB at ata11-master UDMA100 SATA 3Gb/s These four disks form a RAIDZ. Kernel configuration options that seem relevant: options SMP options KDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN device ata device atadisk nodeviceatapicd nodeviceatapifd nodeviceatapist device atamarvell What more would be useful to know? >How-To-Repeat: Unknown; the crash has happened twice so far, once with a kernel from January after weeks of uptime and once with a kernel from yesterday after only a few hours. The system routinely survives multiple zfs scrubs of the four disks hanging off of pci3, so
Re: misc/145189: nfsd performs abysmally under load
On Tue, 30 Mar 2010, Rich Ercolani wrote: Description: nfsd performs abysmally on this machine under conditions in which Solaris's NFS implementation is reasonably fast, and while local IO to the same filesystems is still zippy. Please don't format lines for 200+ column terminals. Does it work better when limited to 1 thread (nfsd -n 1)? In at least some versions of it (or maybe in nfsiod), multiple threads fight each other under load. For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with the following flags [rw,nosuid,hard,intr,nofsc,tcp,vers=3,rsize=8192,wsize=8192,sloppy,addr=X.X.X.X](Linux client, the above is the server), I achieve 2 MB/s, fluctuating between 1 and 3. (pv reports 2.23 MB/s avg) Locally, on the server, I achieve 110-140 MB/s (at the end of pv, it reports 123 MB/s avg). I'd assume network latency, but nc with no flags other than port achieves 30-50 MB/s between server and client. Latency is also abysmal - ls on a randomly chosen homedir full of files, according to time, takes: real0m15.634s user0m0.012s sys 0m0.097s while on the local machine: real0m0.266s user0m0.007s sys 0m0.000s It probably is latency. nfs is very latency-sensitive when there are lots of small files. Transfers of large files shouldn't be affected so much. The server in question is a 3GHz Core 2 Duo, running FreeBSD RELENG_8. The kernel conf, DTRACE_POLL, is just the stock AMD64 kernel with all of the DTRACE-related options turned on, as well as the option to enable polling in the NIC drivers, since we were wondering if that would improve our performance. Enabling polling is a good way to destroy latency. A ping latency of more that about 50uS causes noticable loss of performance for nfs, but LAN latency is usually a few times higher than that, and polling without increasing the clock interrupt frequency to an excessively high value gives a latency of at least 20 times higher than that. Also, -current with debugging options is so bloated that even localhost has a ping latency of about 50uS on a Core2 (up from 2uS for FreeBSD-4 on an AthlonXP). Anyway try nfs on localhost to see if reducing the latency helps. We tested this with a UFS directory as well, because we were curious if this was an NFS/ZFS interaction - we still got 1-2 MB/s read speed and horrible latency while achieving fast throughput and latency local to the server, so we're reasonably certain it's not "just" ZFS, if there is indeed any interaction there. After various tuning and bug fixing (now partly committed by others) I get improvements like the following on low-end systems with ffs (I don't use zfs): - very low end with 100Mbps ethernet: little change; bulk transfers always went at near wire speed (about 10 MB/S) - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local ffs 50MB/S). buildworld over nfs of 5.2 world down from 1200 seconds to 800 seconds (this one is very latency-sensitive. Takes about 750 seconds on local ffs). Read speed of a randomly generated 6500 MB file on UFS over NFSv3 with the same flags as above: 1-3 MB/s, averaging 2.11 MB/s Read speed of the same file, local to the server: consistently between 40-60 MB/s, averaging 61.8 MB/s [it got faster over time - presumably UFS was aggressively caching the file, or something?] You should use a file size larger than the size of main memory to prevent caching, especially for reads. That is 1GB on my low-end systems. Read speed of the same file over NFS again, after the local test: Amusingly, worse (768 KB/s-2.2 MB/s, with random stalls - average reported 270 KB/s(!)). The random stalls are typical of the problem with the nfsd's getting in each other's way, and/or of related problems. The stalls that I saw were very easy to see in real time using "netstat -I 1" -- they happened every few seconds and lasted a second or 2. But they were never long enough to reduce the throughput by more than a factor of 3, so I always got over 19 MB/S. The throughput was reduced by approximately the ratio of stalled time to non-stalled time. How-To-Repeat: 1) Mount multiple NFS filesystems from the server 2) Watch as your operations latency and throughput rapidly sink to near-zero Multiple active nfs mounts are probably a different problem. You certainly need more than 1 nfsd and/or nfsiod to handle them, and the stalls might be a result of not having enough daemons. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
The following reply was made to PR misc/145189; it has been noted by GNATS. From: Bruce Evans To: Rich Ercolani Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: misc/145189: nfsd performs abysmally under load Date: Wed, 31 Mar 2010 02:50:16 +1100 (EST) On Tue, 30 Mar 2010, Rich Ercolani wrote: >> Description: > nfsd performs abysmally on this machine under conditions in which Solaris's > NFS implementation is reasonably fast, and while local IO to the same > filesystems is still zippy. Please don't format lines for 200+ column terminals. Does it work better when limited to 1 thread (nfsd -n 1)? In at least some versions of it (or maybe in nfsiod), multiple threads fight each other under load. > For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with the > following flags > [rw,nosuid,hard,intr,nofsc,tcp,vers=3,rsize=8192,wsize=8192,sloppy,addr=X.X.X.X](Linux > client, the above is the server), I achieve 2 MB/s, fluctuating between 1 > and 3. (pv reports 2.23 MB/s avg) > > Locally, on the server, I achieve 110-140 MB/s (at the end of pv, it reports > 123 MB/s avg). > > I'd assume network latency, but nc with no flags other than port achieves > 30-50 MB/s between server and client. > > Latency is also abysmal - ls on a randomly chosen homedir full of files, > according to time, takes: > real0m15.634s > user0m0.012s > sys 0m0.097s > while on the local machine: > real 0m0.266s > user 0m0.007s > sys 0m0.000s It probably is latency. nfs is very latency-sensitive when there are lots of small files. Transfers of large files shouldn't be affected so much. > The server in question is a 3GHz Core 2 Duo, running FreeBSD RELENG_8. The > kernel conf, DTRACE_POLL, is just the stock AMD64 kernel with all of the > DTRACE-related options turned on, as well as the option to enable polling in > the NIC drivers, since we were wondering if that would improve our > performance. Enabling polling is a good way to destroy latency. A ping latency of more that about 50uS causes noticable loss of performance for nfs, but LAN latency is usually a few times higher than that, and polling without increasing the clock interrupt frequency to an excessively high value gives a latency of at least 20 times higher than that. Also, -current with debugging options is so bloated that even localhost has a ping latency of about 50uS on a Core2 (up from 2uS for FreeBSD-4 on an AthlonXP). Anyway try nfs on localhost to see if reducing the latency helps. > We tested this with a UFS directory as well, because we were curious if this > was an NFS/ZFS interaction - we still got 1-2 MB/s read speed and horrible > latency while achieving fast throughput and latency local to the server, so > we're reasonably certain it's not "just" ZFS, if there is indeed any > interaction there. After various tuning and bug fixing (now partly committed by others) I get improvements like the following on low-end systems with ffs (I don't use zfs): - very low end with 100Mbps ethernet: little change; bulk transfers always went at near wire speed (about 10 MB/S) - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local ffs 50MB/S). buildworld over nfs of 5.2 world down from 1200 seconds to 800 seconds (this one is very latency-sensitive. Takes about 750 seconds on local ffs). > Read speed of a randomly generated 6500 MB file on UFS over NFSv3 with the > same flags as above: 1-3 MB/s, averaging 2.11 MB/s > Read speed of the same file, local to the server: consistently between 40-60 > MB/s, averaging 61.8 MB/s [it got faster over time - presumably UFS was > aggressively caching the file, or something?] You should use a file size larger than the size of main memory to prevent caching, especially for reads. That is 1GB on my low-end systems. > Read speed of the same file over NFS again, after the local test: > Amusingly, worse (768 KB/s-2.2 MB/s, with random stalls - average reported > 270 KB/s(!)). The random stalls are typical of the problem with the nfsd's getting in each other's way, and/or of related problems. The stalls that I saw were very easy to see in real time using "netstat -I 1" -- they happened every few seconds and lasted a second or 2. But they were never long enough to reduce the throughput by more than a factor of 3, so I always got over 19 MB/S. The throughput was reduced by approximately the ratio of stalled time to non-stalled time. >> How-To-Repeat: > 1) Mount multiple NFS filesystems from the server > 2) Watch as your operations latency and throughput rapidly sink to near-zero Multiple active nfs mounts are probably a different problem. You certainly need more than 1 nfsd and/or nfsiod to handle them, and the stalls might be a result of not having enough daemons. Bruce ___ freebsd-bu
misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages
>Number: 145212
>Category: misc
>Synopsis: Feature Request: Be able to build FreeBSD with man utilities
>but not with man pages
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 30 16:10:08 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Alexander Sack
>Release:7.2-amd64, CURRENT
>Organization:
Niksun
>Environment:
>Description:
Currently the WITHOUT_MAN option to the FreeBSD world build will stub out BOTH
man binaries (gnu/usr.bin/man ad manpath, usr.bin/catman, etc.) as well as
creation of the man pages.
I would like to build able to build FreeBSD with the man utilities but not the
man pages since we want to conserve space BUT be able to read third-party or
custom application generated man pages.
I propose a MK_MAN_UTILS option that allows the following:
WITHOUT_MAN=1 WITH_MAN_UTILS=1 make buildworld
Will build the entire world sans man pages but with binaries
WITHOUT_MAN=1 make buildworld
Will build the entire world without man pages OR man binaries (existing
behavior)
WITHOUT_MAN_UTILS=1 make buildworld
Will build the entire world without man pages or man binaries (if you have no
binaries how are you going to read man pages!) - in other words:
WITH_MAN=1 && WITHOUT_MAN_UTILS=1 is illegal
Patches attached against CURRENT.
New file should also be included as well (I forgot it):
$ cat tools/build/options/WITHOUT_MAN_UTILS
.\" $FreeBSD$
Set to not build any man related utilities such as man, manpath, and catman.
>How-To-Repeat:
Build FreeBSD using src.conf option WITHOUT_MAN=1 and no man utilities will be
included in your runtime.
>Fix:
Patch attached with submission follows:
Index: etc/Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.381
diff -u -r1.381 Makefile
--- etc/Makefile19 Mar 2010 15:53:02 - 1.381
+++ etc/Makefile30 Mar 2010 14:38:03 -
@@ -64,7 +64,7 @@
BIN1+= ${.CURDIR}/../usr.bin/mail/misc/mail.rc
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_UTILS} != "no"
BIN1+= ${.CURDIR}/../gnu/usr.bin/man/manpath/manpath.config
.endif
Index: gnu/usr.bin/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/Makefile,v
retrieving revision 1.102
diff -u -r1.102 Makefile
--- gnu/usr.bin/Makefile26 Mar 2010 17:02:32 - 1.102
+++ gnu/usr.bin/Makefile30 Mar 2010 14:38:04 -
@@ -39,7 +39,7 @@
_texinfo= texinfo
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_UTILS} != "no"
_man= man
.endif
Index: share/mk/bsd.own.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.83
diff -u -r1.83 bsd.own.mk
--- share/mk/bsd.own.mk 26 Mar 2010 17:02:32 - 1.83
+++ share/mk/bsd.own.mk 30 Mar 2010 14:38:15 -
@@ -524,7 +524,8 @@
# MK_* options whose default value depends on another option.
#
.for vv in \
-GSSAPI/KERBEROS
+GSSAPI/KERBEROS \
+MAN_UTILS/MAN
.if defined(WITH_${vv:H}) && defined(WITHOUT_${vv:H})
.error WITH_${vv:H} and WITHOUT_${vv:H} can't both be set.
.endif
Index: usr.bin/Makefile
===
RCS file: /home/ncvs/src/usr.bin/Makefile,v
retrieving revision 1.332
diff -u -r1.332 Makefile
--- usr.bin/Makefile19 Feb 2010 23:54:12 - 1.332
+++ usr.bin/Makefile30 Mar 2010 14:38:29 -
@@ -253,7 +253,7 @@
_atm= atm
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_UTILS} != "no"
_catman= catman
.endif
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans wrote:
> Does it work better when limited to 1 thread (nfsd -n 1)? In at least
> some versions of it (or maybe in nfsiod), multiple threads fight each other
> under load.
It doesn't seem to - nfsd -n 1 still ranges between 1-3 MB/s for files
> RAM on server or client (6 and 4 GB, respectively).
>> For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with the
>> following flags
>> [rw,nosuid,hard,intr,nofsc,tcp,vers=3,rsize=8192,wsize=8192,sloppy,addr=X.X.X.X](Linux
>> client, the above is the server), I achieve 2 MB/s, fluctuating between 1
>> and 3. (pv reports 2.23 MB/s avg)
>>
>> Locally, on the server, I achieve 110-140 MB/s (at the end of pv, it
>> reports 123 MB/s avg).
>>
>> I'd assume network latency, but nc with no flags other than port achieves
>> 30-50 MB/s between server and client.
>>
>> Latency is also abysmal - ls on a randomly chosen homedir full of files,
>> according to time, takes:
>> real 0m15.634s
>> user 0m0.012s
>> sys 0m0.097s
>> while on the local machine:
>> real 0m0.266s
>> user 0m0.007s
>> sys 0m0.000s
>
> It probably is latency. nfs is very latency-sensitive when there are lots
> of small files. Transfers of large files shouldn't be affected so much.
Sure, and next on my TODO is to look into whether 9.0-CURRENT makes
certain ZFS high-latency things perform better.
>> The server in question is a 3GHz Core 2 Duo, running FreeBSD RELENG_8. The
>> kernel conf, DTRACE_POLL, is just the stock AMD64 kernel with all of the
>> DTRACE-related options turned on, as well as the option to enable polling in
>> the NIC drivers, since we were wondering if that would improve our
>> performance.
>
> Enabling polling is a good way to destroy latency. A ping latency of
> more that about 50uS causes noticable loss of performance for nfs, but
> LAN latency is usually a few times higher than that, and polling without
> increasing the clock interrupt frequency to an excessively high value
> gives a latency of at least 20 times higher than that. Also, -current
> with debugging options is so bloated that even localhost has a ping
> latency of about 50uS on a Core2 (up from 2uS for FreeBSD-4 on an
> AthlonXP). Anyway try nfs on localhost to see if reducing the latency
> helps.
Actually, we noticed that throughput appeared to get marginally better while
causing occasional bursts of crushing latency, but yes, we have it on in the
kernel without using it in any actual NICs at present. :)
But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
with no additional mount flags. {r,w}size=8192 on localhost goes up to
80-100 MB/s, with occasional sinks to 60 (average after copying
another, separate 6.5 GB file: 77.3 MB/s).
Also:
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from [actual IP]: icmp_seq=0 ttl=64 time=0.019 ms
64 bytes from [actual IP]: icmp_seq=1 ttl=64 time=0.015 ms
>> We tested this with a UFS directory as well, because we were curious if
>> this was an NFS/ZFS interaction - we still got 1-2 MB/s read speed and
>> horrible latency while achieving fast throughput and latency local to the
>> server, so we're reasonably certain it's not "just" ZFS, if there is indeed
>> any interaction there.
>
> After various tuning and bug fixing (now partly committed by others) I get
> improvements like the following on low-end systems with ffs (I don't use
> zfs):
> - very low end with 100Mbps ethernet: little change; bulk transfers always
> went at near wire speed (about 10 MB/S)
> - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local ffs
> 50MB/S). buildworld over nfs of 5.2 world down from 1200 seconds to 800
> seconds (this one is very latency-sensitive. Takes about 750 seconds on
> local ffs).
Is this on 9.0-CURRENT, or RELENG_8, or something else?
>> Read speed of a randomly generated 6500 MB file on UFS over NFSv3 with the
>> same flags as above: 1-3 MB/s, averaging 2.11 MB/s
>> Read speed of the same file, local to the server: consistently between
>> 40-60 MB/s, averaging 61.8 MB/s [it got faster over time - presumably UFS
>> was aggressively caching the file, or something?]
>
> You should use a file size larger than the size of main memory to prevent
> caching, especially for reads. That is 1GB on my low-end systems.
I didn't mention the server's RAM, explicitly, but it has 6 GB of real
RAM, and the files used were 6.5-7 GB each in that case (I did use a
4GB file earlier - I've avoided doing that again here).
>> Read speed of the same file over NFS again, after the local test:
>> Amusingly, worse (768 KB/s-2.2 MB/s, with random stalls - average reported
>> 270 KB/s(!)).
>
> The random stalls are typical of the problem with the nfsd's getting
> in each other's way, and/or
Re: misc/145189: nfsd performs abysmally under load
The following reply was made to PR misc/145189; it has been noted by GNATS.
From: Rich
To: Bruce Evans
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: misc/145189: nfsd performs abysmally under load
Date: Tue, 30 Mar 2010 12:29:37 -0400
On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans wrote:
> Does it work better when limited to 1 thread (nfsd -n 1)? =A0In at least
> some versions of it (or maybe in nfsiod), multiple threads fight each oth=
er
> under load.
It doesn't seem to - nfsd -n 1 still ranges between 1-3 MB/s for files
> RAM on server or client (6 and 4 GB, respectively).
>> For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with t=
he
>> following flags
>> [rw,nosuid,hard,intr,nofsc,tcp,vers=3D3,rsize=3D8192,wsize=3D8192,sloppy=
,addr=3DX.X.X.X](Linux
>> client, the above is the server), I achieve 2 MB/s, fluctuating between =
1
>> and 3. (pv reports 2.23 MB/s avg)
>>
>> Locally, on the server, I achieve 110-140 MB/s (at the end of pv, it
>> reports 123 MB/s avg).
>>
>> I'd assume network latency, but nc with no flags other than port achieve=
s
>> 30-50 MB/s between server and client.
>>
>> Latency is also abysmal - ls on a randomly chosen homedir full of files,
>> according to time, takes:
>> real =A0 =A00m15.634s
>> user =A0 =A00m0.012s
>> sys =A0 =A0 0m0.097s
>> while on the local machine:
>> real =A0 =A00m0.266s
>> user =A0 =A00m0.007s
>> sys =A0 =A0 0m0.000s
>
> It probably is latency. =A0nfs is very latency-sensitive when there are l=
ots
> of small files. =A0Transfers of large files shouldn't be affected so much=
.
Sure, and next on my TODO is to look into whether 9.0-CURRENT makes
certain ZFS high-latency things perform better.
>> The server in question is a 3GHz Core 2 Duo, running FreeBSD RELENG_8. T=
he
>> kernel conf, DTRACE_POLL, is just the stock AMD64 kernel with all of the
>> DTRACE-related options turned on, as well as the option to enable pollin=
g in
>> the NIC drivers, since we were wondering if that would improve our
>> performance.
>
> Enabling polling is a good way to destroy latency. =A0A ping latency of
> more that about 50uS causes noticable loss of performance for nfs, but
> LAN latency is usually a few times higher than that, and polling without
> increasing the clock interrupt frequency to an excessively high value
> gives a latency of at least 20 times higher than that. =A0Also, -current
> with debugging options is so bloated that even localhost has a ping
> latency of about 50uS on a Core2 (up from 2uS for FreeBSD-4 on an
> AthlonXP). =A0Anyway try nfs on localhost to see if reducing the latency
> helps.
Actually, we noticed that throughput appeared to get marginally better whil=
e
causing occasional bursts of crushing latency, but yes, we have it on in th=
e
kernel without using it in any actual NICs at present. :)
But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
with no additional mount flags. {r,w}size=3D8192 on localhost goes up to
80-100 MB/s, with occasional sinks to 60 (average after copying
another, separate 6.5 GB file: 77.3 MB/s).
Also:
64 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.015 ms
64 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.049 ms
64 bytes from 127.0.0.1: icmp_seq=3D2 ttl=3D64 time=3D0.012 ms
64 bytes from [actual IP]: icmp_seq=3D0 ttl=3D64 time=3D0.019 ms
64 bytes from [actual IP]: icmp_seq=3D1 ttl=3D64 time=3D0.015 ms
>> We tested this with a UFS directory as well, because we were curious if
>> this was an NFS/ZFS interaction - we still got 1-2 MB/s read speed and
>> horrible latency while achieving fast throughput and latency local to th=
e
>> server, so we're reasonably certain it's not "just" ZFS, if there is ind=
eed
>> any interaction there.
>
> After various tuning and bug fixing (now partly committed by others) I ge=
t
> improvements like the following on low-end systems with ffs (I don't use
> zfs):
> - very low end with 100Mbps ethernet: little change; bulk transfers alway=
s
> =A0went at near wire speed (about 10 MB/S)
> - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local ff=
s
> =A050MB/S). =A0buildworld over nfs of 5.2 world down from 1200 seconds to=
800
> =A0seconds (this one is very latency-sensitive. =A0Takes about 750 second=
s on
> =A0local ffs).
Is this on 9.0-CURRENT, or RELENG_8, or something else?
>> Read speed of a randomly generated 6500 MB file on UFS over NFSv3 with t=
he
>> same flags as above: 1-3 MB/s, averaging 2.11 MB/s
>> Read speed of the same file, local to the server: consistently between
>> 40-60 MB/s, averaging 61.8 MB/s [it got faster over time - presumably UF=
S
>> was aggressively caching the file, or something?]
>
> You should use a file size larger than the size of main memory to prevent
> caching, especially
Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages
The following reply was made to PR misc/145212; it has been noted by GNATS. From: Garrett Cooper To: Alexander Sack Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages Date: Tue, 30 Mar 2010 10:28:44 -0700 On Tue, Mar 30, 2010 at 9:01 AM, Alexander Sack wrote: > >>Number: =A0 =A0 =A0 =A0 145212 >>Category: =A0 =A0 =A0 misc >>Synopsis: =A0 =A0 =A0 Feature Request: Be able to build FreeBSD with man = utilities but not with man pages >>Confidential: =A0 no >>Severity: =A0 =A0 =A0 non-critical >>Priority: =A0 =A0 =A0 low >>Responsible: =A0 =A0freebsd-bugs >>State: =A0 =A0 =A0 =A0 =A0open >>Quarter: >>Keywords: >>Date-Required: >>Class: =A0 =A0 =A0 =A0 =A0sw-bug >>Submitter-Id: =A0 current-users >>Arrival-Date: =A0 Tue Mar 30 16:10:08 UTC 2010 >>Closed-Date: >>Last-Modified: >>Originator: =A0 =A0 Alexander Sack >>Release: =A0 =A0 =A0 =A07.2-amd64, CURRENT >>Organization: > Niksun Looks like a worthy patch, but I think you forgot one item: If MK_MAN_UTILS =3D=3D "no", then MK_MAN should also be "no". Thanks :), -Garrett ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages
The following reply was made to PR misc/145212; it has been noted by GNATS.
From: Alexander Sack
To: bug-follo...@freebsd.org, as...@niksun.com
Cc:
Subject: Re: misc/145212: Feature Request: Be able to build FreeBSD with man
utilities but not with man pages
Date: Tue, 30 Mar 2010 13:41:34 -0400
I'd like to mention also that manctl is not tuned by any of the MK_*
knobs so with the advent of MK_MAN_UTILS perhaps something like this
should also be part of the patch:
Index: usr.sbin/Makefile
===
RCS file: /home/ncvs/src/usr.sbin/Makefile,v
retrieving revision 1.421
diff -u -r1.421 Makefile
--- usr.sbin/Makefile4 Mar 2010 20:31:49 -1.421
+++ usr.sbin/Makefile30 Mar 2010 17:30:27 -
@@ -91,7 +91,7 @@
mailwrapper \
makefs \
${_makemap} \
-manctl \
+${_manctl} \
memcontrol \
mergemaster \
mfiutil \
@@ -322,6 +322,10 @@
_lpr=lpr
.endif
+.if ${MK_MAN_UTILS} != "no"
+_manctl=manctl
+.endif
+
.if ${MK_NETGRAPH} != "no"
_flowctl=flowctl
_lmcconfig=lmcconfig
Another thing my patch DOES NOT address is the mtree hierarchy which I
am indifferent about. I believe as its set up, we should leave the
mtree stuff alone (just not populate any man pages in them).
Thanks!
-aps
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages
The following reply was made to PR misc/145212; it has been noted by GNATS. From: Alexander Sack To: Garrett Cooper Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages Date: Tue, 30 Mar 2010 13:44:30 -0400 On 3/30/10 1:28 PM, Garrett Cooper wrote: > On Tue, Mar 30, 2010 at 9:01 AM, Alexander Sack wrote: > >> >>> Number: 145212 >>> Category: misc >>> Synopsis: Feature Request: Be able to build FreeBSD with man >>> utilities but not with man pages >>> Confidential: no >>> Severity: non-critical >>> Priority: low >>> Responsible:freebsd-bugs >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Tue Mar 30 16:10:08 UTC 2010 >>> Closed-Date: >>> Last-Modified: >>> Originator: Alexander Sack >>> Release:7.2-amd64, CURRENT >>> Organization: >>> >> Niksun >> > Looks like a worthy patch, but I think you forgot one item: > If MK_MAN_UTILS == "no", then MK_MAN should also be "no". > Thanks :), > -Garrett > > Ah damn did I do thatdamn it...its a small fix for that. I got a follow up Garrett to add manctl in the mix as well. -aps ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
On Tue, 30 Mar 2010, Garrett Cooper wrote: Hi, I'm not 100% satisfied with this patch now. Looking back it fails the following case: -PDo not follow symbolic links in the file hierarchy, instead con- sider the symbolic link itself in any comparisons. This is the default. -P should have the same semantics and description in all utilities. The description should not have grammar errors like the above (comma splice). In cp(1) the description is: %%% -PIf the -R option is specified, no symbolic links are followed. This is the default. ... Symbolic links are always followed unless the -R flag is set, in which case symbolic links are not followed, by default. The -H or -L flags (in conjunction with the -R flag) cause symbolic links to be followed as described above. The -H, -L and -P options are ignored unless the -R option is specified. In addition, these options override each other and the command's actions are determined by the last one specified. %%% I now see that the grammar error is from the original version of mtree(1), and is probably one of the things you don't like. mtree also has -L, but not -R or -P or -h. It is not clear how any utility that traverses trees can work without a full complement of -[HLPR] or how any utility that supports symlinks can work without -h. cp(1) doesn't support -h either, but I think mtree is more like chmod(1) here -- it supports setting attributes (without having an source file or symlink in the hierarchy to copy the attributes from like cp does), so it should have a way control whether the attributes are set on a symlink or on the symlink target. I need to add a check for this option to the patch, use stat if the `follow links' state is true, otherwise use lstat. In mtree, -P controls only the tree traversal. If symlinks are not followed in the traversal, then it can't be right to always follow them for the final path component like the current code always does. The current code never use, lstat(), lchmod(), lutimes(), etc., so it can't handle symlinks very well. You would need to change much more than stat() to lstat() to fix this. First, there are delicate combinations of the -[HLPR] flags to distinguish between following symbolic links on the command line and symbolic links in the file hierarchy. In cp, these are: -RH: follow on the command line but not in the hierarchy -RL: always follow -RP: never follow. mtree has -R as implicit and doesn't have -H. It claims that -P is the default. However, this cannot possibly work for leaf symlinks, since mtree never uses lstat(), lchmod(), etc., so it always follows leaf symlinks. Next, there is the -h flag to give control over following leaf symlinks. In cp, this isn't really needed since it makes no sense to use a different "follow" rule for the source and target; so with -R, -P actually gives "never follow", while without -R, -P has no effect and gives "always follow"; thus you can get the effect of -h using -RP for copying a single symlink, and the only difficult operation not getting the effect of -h for copying hierachies. In mtree, there is no -h flag, and no support for it either, and the claimed "never follow" for -P is just wrong for leaf symlinks. Oops, further grepping shows that the above is not quite right. mtree does use lchown() for creating symlinks. This might be because ownership is more important for security than other attributes. Also, the claim that -RP always follows symlinks seems to be wrong in all cases except in cp: in chflags, chmod and chown, it takes -h to follow leaf symlinks; cp doesn't have -h and -RP is required to preserve everything, so cp is more careful about this and uses lch*() on symlinks (even for cp, it took about 10 years for it to catch up with the kernel and actually use the newer lch*() syscalls). chmod(1) and chown(1) and their history are probably better refences than cp(1) for deciding what mtree should do. In 4.4BSD, chown and chmod had all of -HLPR, but not -h, and chmod(1) and chown(8) on a symlink were documented as having no effect; since chmod(2) and chown(2) do have an affect (they follow the symlink), this must have been implemented by not calling these syscalls on a symlink at all, but this seems to have been slightly broken (the call was not always avoided as documented). FreeBSD added -h and eventually the newer lch*() calls, but doesn't seem to have changed the avoidance of the call, so the mismatch between the documentation and the behaviour for chown(1) now is: % The chown utility changes the user ID and/or the group ID of the speci- % fied files. Symbolic links named by arguments are silently left % unchanged unless -h is used. Actually: Symbolic links named by arguments are followed unless -h (or certain other options) are used. % % The options are as follows: % % -H If the -R
Re: kern/144749: commit references a PR
The following reply was made to PR kern/144749; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/144749: commit references a PR
Date: Tue, 30 Mar 2010 19:08:20 + (UTC)
Author: jhb
Date: Tue Mar 30 19:07:41 2010
New Revision: 205900
URL: http://svn.freebsd.org/changeset/base/205900
Log:
Use panic() (which the environment is required to provide to libstand) to
implement assert() instead of relying on a non-required exit(). The exit()
invocation also did not match the semantics of the exit() routine that
current boot environments happen to require.
PR: kern/144749
Discussed with: bde
MFC after: 1 week
Modified:
head/lib/libstand/assert.c
Modified: head/lib/libstand/assert.c
==
--- head/lib/libstand/assert.c Tue Mar 30 19:06:54 2010(r205899)
+++ head/lib/libstand/assert.c Tue Mar 30 19:07:41 2010(r205900)
@@ -35,10 +35,10 @@ void
__assert(const char *func, const char *file, int line, const char *expression)
{
if (func == NULL)
- printf("Assertion failed: (%s), file %s, line %d.\n",
+ panic("Assertion failed: (%s), file %s, line %d.\n",
expression, file, line);
else
- printf("Assertion failed: (%s), function %s, file %s, line "
- "%d.\n", expression, func, file, line);
- exit();
+ panic(
+ "Assertion failed: (%s), function %s, file %s, line %d.\n",
+ expression, func, file, line);
}
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
On Wed, 31 Mar 2010, Bruce Evans wrote: On Tue, 30 Mar 2010, Garrett Cooper wrote: Hi, I'm not 100% satisfied with this patch now. Looking back it fails the following case: -PDo not follow symbolic links in the file hierarchy, instead con- sider the symbolic link itself in any comparisons. This is the default. -P should have the same semantics and description in all utilities. The description should not have grammar errors like the above (comma splice). ... I now see that the grammar error is from the original version of mtree(1), and is probably one of the things you don't like. mtree also has -L, but not -R or -P or -h. It is not clear how any utility that traverses trees can work without a full complement of -[HLPR] or how any utility that ... Looking at the actual patch, I now see that it is about a completely different problem. You would only need to understand the amount of brokenness of -P to see if you need to use lstat(). I think -P is so broken that mtree on symlinks doesn't work at all and not using lstat() would be safest. The patch has some style bugs. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144749: [libstand] [patch] make assert.c use abort(3) instead of exit(3)
Synopsis: [libstand] [patch] make assert.c use abort(3) instead of exit(3) State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Tue Mar 30 19:54:43 UTC 2010 State-Changed-Why: Fixed in HEAD. Responsible-Changed-From-To: freebsd-bugs->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Tue Mar 30 19:54:43 UTC 2010 Responsible-Changed-Why: Fixed in HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=144749 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
On Tue, 30 Mar 2010, Rich wrote:
On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans wrote:
For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with the
following flags
[rw,nosuid,hard,intr,nofsc,tcp,vers=3,rsize=8192,wsize=8192,sloppy,addr=X.X.X.X](Linux
client, the above is the server), I achieve 2 MB/s, fluctuating between 1
and 3. (pv reports 2.23 MB/s avg)
I also tried various nfs r/w sizes and tcp/udp. The best sizes are
probably the fs block size or twice that (normally 16K for ffs). Old
versions of FreeBSD had even more bugs in this area and gave surprising
performance differences depending on the nfs r/w sizes or application
i/o sizes. In some cases smaller sizes worked best, apparently because
they avoided the stalls.
...
Enabling polling is a good way to destroy latency. ?A ping latency of
...
Actually, we noticed that throughput appeared to get marginally better while
causing occasional bursts of crushing latency, but yes, we have it on in the
kernel without using it in any actual NICs at present. :)
But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
with no additional mount flags. {r,w}size=8192 on localhost goes up to
80-100 MB/s, with occasional sinks to 60 (average after copying
another, separate 6.5 GB file: 77.3 MB/s).
I thought you said you often got 1-3MB/S.
Also:
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms
Fairly normal slowness for -current.
64 bytes from [actual IP]: icmp_seq=0 ttl=64 time=0.019 ms
64 bytes from [actual IP]: icmp_seq=1 ttl=64 time=0.015 ms
Are these with external hardware NICs? Then 15 uS is excellent. Better
than I've ever seen. Very good hardware might be able to do this, but
I suspect it is for the local machine. BTW, I don't like the times
been reported in ms and sub-uS times not being supported. I sometimes
run Linux or cygwin ping and don't like it not supporting sub-mS times,
so that it always reports 0 for my average latency of 100 uS.
After various tuning and bug fixing (now partly committed by others) I get
improvements like the following on low-end systems with ffs (I don't use
zfs):
- very low end with 100Mbps ethernet: little change; bulk transfers always
?went at near wire speed (about 10 MB/S)
- low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local ffs
?50MB/S). ?buildworld over nfs of 5.2 world down from 1200 seconds to 800
?seconds (this one is very latency-sensitive. ?Takes about 750 seconds on
?local ffs).
Is this on 9.0-CURRENT, or RELENG_8, or something else?
Mostly with 7-CURRENT or 8-CURRENT a couple of years ago. Sometimes with
a ~5.2-SERVER. nfs didn't vary much with the server, except there were
surprising differences due to latency that I never tracked down.
I forgot to mention another thing you can try easily:
- negative name caching. Improves latency. I used this to reduce makeworld
times significantly, and it is now standard in -current but not
enabled by default.
Bruce___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
The following reply was made to PR misc/145189; it has been noted by GNATS.
From: Bruce Evans
To: Rich
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@freebsd.org
Subject: Re: misc/145189: nfsd performs abysmally under load
Date: Wed, 31 Mar 2010 07:11:32 +1100 (EST)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1912970806-1269979892=:2145
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Tue, 30 Mar 2010, Rich wrote:
> On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans wrot=
e:
>>> For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with =
the
>>> following flags
>>> [rw,nosuid,hard,intr,nofsc,tcp,vers=3D3,rsize=3D8192,wsize=3D8192,slopp=
y,addr=3DX.X.X.X](Linux
>>> client, the above is the server), I achieve 2 MB/s, fluctuating between=
1
>>> and 3. (pv reports 2.23 MB/s avg)
I also tried various nfs r/w sizes and tcp/udp. The best sizes are
probably the fs block size or twice that (normally 16K for ffs). Old
versions of FreeBSD had even more bugs in this area and gave surprising
performance differences depending on the nfs r/w sizes or application
i/o sizes. In some cases smaller sizes worked best, apparently because
they avoided the stalls.
>>> ...
>> Enabling polling is a good way to destroy latency. =A0A ping latency of
>> ...
> Actually, we noticed that throughput appeared to get marginally better wh=
ile
> causing occasional bursts of crushing latency, but yes, we have it on in =
the
> kernel without using it in any actual NICs at present. :)
>
> But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
> average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
> with no additional mount flags. {r,w}size=3D8192 on localhost goes up to
> 80-100 MB/s, with occasional sinks to 60 (average after copying
> another, separate 6.5 GB file: 77.3 MB/s).
I thought you said you often got 1-3MB/S.
> Also:
> 64 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.015 ms
> 64 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.049 ms
> 64 bytes from 127.0.0.1: icmp_seq=3D2 ttl=3D64 time=3D0.012 ms
Fairly normal slowness for -current.
> 64 bytes from [actual IP]: icmp_seq=3D0 ttl=3D64 time=3D0.019 ms
> 64 bytes from [actual IP]: icmp_seq=3D1 ttl=3D64 time=3D0.015 ms
Are these with external hardware NICs? Then 15 uS is excellent. Better
than I've ever seen. Very good hardware might be able to do this, but
I suspect it is for the local machine. BTW, I don't like the times
been reported in ms and sub-uS times not being supported. I sometimes
run Linux or cygwin ping and don't like it not supporting sub-mS times,
so that it always reports 0 for my average latency of 100 uS.
>> After various tuning and bug fixing (now partly committed by others) I g=
et
>> improvements like the following on low-end systems with ffs (I don't use
>> zfs):
>> - very low end with 100Mbps ethernet: little change; bulk transfers alwa=
ys
>> =A0went at near wire speed (about 10 MB/S)
>> - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local f=
fs
>> =A050MB/S). =A0buildworld over nfs of 5.2 world down from 1200 seconds t=
o 800
>> =A0seconds (this one is very latency-sensitive. =A0Takes about 750 secon=
ds on
>> =A0local ffs).
>
> Is this on 9.0-CURRENT, or RELENG_8, or something else?
Mostly with 7-CURRENT or 8-CURRENT a couple of years ago. Sometimes with
a ~5.2-SERVER. nfs didn't vary much with the server, except there were
surprising differences due to latency that I never tracked down.
I forgot to mention another thing you can try easily:
- negative name caching. Improves latency. I used this to reduce makeworl=
d
times significantly, and it is now standard in -current but not
enabled by default.
Bruce
--0-1912970806-1269979892=:2145--
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
On Tue, Mar 30, 2010 at 1:11 PM, Bruce Evans wrote:
> On Tue, 30 Mar 2010, Rich wrote:
>
>> On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans
>> wrote:
>
For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with
the
following flags
[rw,nosuid,hard,intr,nofsc,tcp,vers=3,rsize=8192,wsize=8192,sloppy,addr=X.X.X.X](Linux
client, the above is the server), I achieve 2 MB/s, fluctuating between
1
and 3. (pv reports 2.23 MB/s avg)
>
> I also tried various nfs r/w sizes and tcp/udp. The best sizes are
> probably the fs block size or twice that (normally 16K for ffs). Old
> versions of FreeBSD had even more bugs in this area and gave surprising
> performance differences depending on the nfs r/w sizes or application
> i/o sizes. In some cases smaller sizes worked best, apparently because
> they avoided the stalls.
>
...
>>>
>>> Enabling polling is a good way to destroy latency. A ping latency of
>>> ...
>
>> Actually, we noticed that throughput appeared to get marginally better
>> while
>> causing occasional bursts of crushing latency, but yes, we have it on in
>> the
>> kernel without using it in any actual NICs at present. :)
>>
>> But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
>> average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
>> with no additional mount flags. {r,w}size=8192 on localhost goes up to
>> 80-100 MB/s, with occasional sinks to 60 (average after copying
>> another, separate 6.5 GB file: 77.3 MB/s).
>
> I thought you said you often got 1-3MB/S.
>
>> Also:
>> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.015 ms
>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.049 ms
>> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms
>
> Fairly normal slowness for -current.
>
>> 64 bytes from [actual IP]: icmp_seq=0 ttl=64 time=0.019 ms
>> 64 bytes from [actual IP]: icmp_seq=1 ttl=64 time=0.015 ms
>
> Are these with external hardware NICs? Then 15 uS is excellent. Better
> than I've ever seen. Very good hardware might be able to do this, but
> I suspect it is for the local machine. BTW, I don't like the times
> been reported in ms and sub-uS times not being supported. I sometimes
> run Linux or cygwin ping and don't like it not supporting sub-mS times,
> so that it always reports 0 for my average latency of 100 uS.
>
>>> After various tuning and bug fixing (now partly committed by others) I
>>> get
>>> improvements like the following on low-end systems with ffs (I don't use
>>> zfs):
>>> - very low end with 100Mbps ethernet: little change; bulk transfers
>>> always
>>> went at near wire speed (about 10 MB/S)
>>> - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local
>>> ffs
>>> 50MB/S). buildworld over nfs of 5.2 world down from 1200 seconds to 800
>>> seconds (this one is very latency-sensitive. Takes about 750 seconds on
>>> local ffs).
>>
>> Is this on 9.0-CURRENT, or RELENG_8, or something else?
>
> Mostly with 7-CURRENT or 8-CURRENT a couple of years ago. Sometimes with
> a ~5.2-SERVER. nfs didn't vary much with the server, except there were
> surprising differences due to latency that I never tracked down.
>
> I forgot to mention another thing you can try easily:
>
> - negative name caching. Improves latency. I used this to reduce makeworld
> times significantly, and it is now standard in -current but not
> enabled by default.
Have you also tried tuning via sysctl (vfs.nfs* ?)
Thanks,
-Garrett
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145189: nfsd performs abysmally under load
The following reply was made to PR misc/145189; it has been noted by GNATS.
From: Garrett Cooper
To: Bruce Evans
Cc: Rich , freebsd-bugs@freebsd.org,
freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/145189: nfsd performs abysmally under load
Date: Tue, 30 Mar 2010 13:44:05 -0700
On Tue, Mar 30, 2010 at 1:11 PM, Bruce Evans wrote:
> On Tue, 30 Mar 2010, Rich wrote:
>
>> On Tue, Mar 30, 2010 at 11:50 AM, Bruce Evans
>> wrote:
>
For instance, copying a 4GB file over NFSv3 from a ZFS filesystem with
the
following flags
[rw,nosuid,hard,intr,nofsc,tcp,vers=3D3,rsize=3D8192,wsize=3D8192,slop=
py,addr=3DX.X.X.X](Linux
client, the above is the server), I achieve 2 MB/s, fluctuating betwee=
n
1
and 3. (pv reports 2.23 MB/s avg)
>
> I also tried various nfs r/w sizes and tcp/udp. =A0The best sizes are
> probably the fs block size or twice that (normally 16K for ffs). =A0Old
> versions of FreeBSD had even more bugs in this area and gave surprising
> performance differences depending on the nfs r/w sizes or application
> i/o sizes. =A0In some cases smaller sizes worked best, apparently because
> they avoided the stalls.
>
...
>>>
>>> Enabling polling is a good way to destroy latency. =A0A ping latency of
>>> ...
>
>> Actually, we noticed that throughput appeared to get marginally better
>> while
>> causing occasional bursts of crushing latency, but yes, we have it on in
>> the
>> kernel without using it in any actual NICs at present. :)
>>
>> But yes, I'm getting 40-90+ MB/s, occasionally slowing to 20-30 MB/s,
>> average after copying a 6.5 GB file of 52.7 MB/s, on localhost IPv4,
>> with no additional mount flags. {r,w}size=3D8192 on localhost goes up to
>> 80-100 MB/s, with occasional sinks to 60 (average after copying
>> another, separate 6.5 GB file: 77.3 MB/s).
>
> I thought you said you often got 1-3MB/S.
>
>> Also:
>> 64 bytes from 127.0.0.1: icmp_seq=3D0 ttl=3D64 time=3D0.015 ms
>> 64 bytes from 127.0.0.1: icmp_seq=3D1 ttl=3D64 time=3D0.049 ms
>> 64 bytes from 127.0.0.1: icmp_seq=3D2 ttl=3D64 time=3D0.012 ms
>
> Fairly normal slowness for -current.
>
>> 64 bytes from [actual IP]: icmp_seq=3D0 ttl=3D64 time=3D0.019 ms
>> 64 bytes from [actual IP]: icmp_seq=3D1 ttl=3D64 time=3D0.015 ms
>
> Are these with external hardware NICs? =A0Then 15 uS is excellent. =A0Bet=
ter
> than I've ever seen. =A0Very good hardware might be able to do this, but
> I suspect it is for the local machine. =A0BTW, I don't like the times
> been reported in ms and sub-uS times not being supported. =A0I sometimes
> run Linux or cygwin ping and don't like it not supporting sub-mS times,
> so that it always reports 0 for my average latency of 100 uS.
>
>>> After various tuning and bug fixing (now partly committed by others) I
>>> get
>>> improvements like the following on low-end systems with ffs (I don't us=
e
>>> zfs):
>>> - very low end with 100Mbps ethernet: little change; bulk transfers
>>> always
>>> =A0went at near wire speed (about 10 MB/S)
>>> - low end with 1Gbps/S: bulk transfers up from 20MB/S to 45MB/S (local
>>> ffs
>>> =A050MB/S). =A0buildworld over nfs of 5.2 world down from 1200 seconds =
to 800
>>> =A0seconds (this one is very latency-sensitive. =A0Takes about 750 seco=
nds on
>>> =A0local ffs).
>>
>> Is this on 9.0-CURRENT, or RELENG_8, or something else?
>
> Mostly with 7-CURRENT or 8-CURRENT a couple of years ago. =A0Sometimes wi=
th
> a ~5.2-SERVER. =A0nfs didn't vary much with the server, except there were
> surprising differences due to latency that I never tracked down.
>
> I forgot to mention another thing you can try easily:
>
> - negative name caching. =A0Improves latency. =A0I used this to reduce ma=
keworld
> =A0times significantly, and it is now standard in -current but not
> =A0enabled by default.
Have you also tried tuning via sysctl (vfs.nfs* ?)
Thanks,
-Garrett
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/145212: Feature Request: Be able to build FreeBSD with man utilities but not with man pages
The following reply was made to PR misc/145212; it has been noted by GNATS.
From: Alexander Sack
To: Garrett Cooper
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/145212: Feature Request: Be able to build FreeBSD with man
utilities but not with man pages
Date: Tue, 30 Mar 2010 17:28:47 -0400
This is a multi-part message in MIME format.
--07080808040104060505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 3/30/10 1:28 PM, Garrett Cooper wrote:
> On Tue, Mar 30, 2010 at 9:01 AM, Alexander Sack wrote:
>
>>
>>> Number: 145212
>>> Category: misc
>>> Synopsis: Feature Request: Be able to build FreeBSD with man
>>> utilities but not with man pages
>>> Confidential: no
>>> Severity: non-critical
>>> Priority: low
>>> Responsible:freebsd-bugs
>>> State: open
>>> Quarter:
>>> Keywords:
>>> Date-Required:
>>> Class: sw-bug
>>> Submitter-Id: current-users
>>> Arrival-Date: Tue Mar 30 16:10:08 UTC 2010
>>> Closed-Date:
>>> Last-Modified:
>>> Originator: Alexander Sack
>>> Release:7.2-amd64, CURRENT
>>> Organization:
>>>
>> Niksun
>>
> Looks like a worthy patch, but I think you forgot one item:
> If MK_MAN_UTILS == "no", then MK_MAN should also be "no".
> Thanks :),
> -Garrett
>
>
Garrett in an effort to achieve POLA, how about the patch attached
(against CURRENT). The idea is that:
MK_MAN="no"
No man pages
No man utiltiies
Same behavior as before.
But, now by default, MK_MAN="yes", which then allows you to achieve the
build granularity with MK_MAN_PAGES and MK_MAN_UTILS with the caveat
that if MK_MAN_UTILS="no" than you don't get any man pages since you
don't have the necessary tools to read them.
I didn't update a weekly Makefile since I am not sure what its used
for. Otherwise, this above knobs allow complete control over the man
stuff. I hope I caught all of them (I just grep'ed the tree for MK_MAN
and made the appropriate change).
Thanks!
-aps
--07080808040104060505
Content-Type: text/plain;
name="mk_man_utils.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="mk_man_utils.txt"
Index: etc/Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.381
diff -u -r1.381 Makefile
--- etc/Makefile 19 Mar 2010 15:53:02 - 1.381
+++ etc/Makefile 30 Mar 2010 21:19:51 -
@@ -64,7 +64,7 @@
BIN1+=${.CURDIR}/../usr.bin/mail/misc/mail.rc
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_UTILS} != "no"
BIN1+=${.CURDIR}/../gnu/usr.bin/man/manpath/manpath.config
.endif
Index: gnu/usr.bin/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/Makefile,v
retrieving revision 1.102
diff -u -r1.102 Makefile
--- gnu/usr.bin/Makefile 26 Mar 2010 17:02:32 - 1.102
+++ gnu/usr.bin/Makefile 30 Mar 2010 21:19:52 -
@@ -39,7 +39,7 @@
_texinfo= texinfo
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_UTILS} != "no"
_man= man
.endif
Index: share/Makefile
===
RCS file: /home/ncvs/src/share/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- share/Makefile 8 Oct 2008 13:20:02 - 1.40
+++ share/Makefile 30 Mar 2010 21:20:01 -
@@ -57,7 +57,7 @@
_mk= mk
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_PAGES} != "no"
_man= man
.endif
Index: share/mk/bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.187
diff -u -r1.187 bsd.lib.mk
--- share/mk/bsd.lib.mk22 Jan 2010 14:05:48 - 1.187
+++ share/mk/bsd.lib.mk30 Mar 2010 21:20:03 -
@@ -238,7 +238,7 @@
all: ${_LIBS}
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_PAGES} != "no"
all: _manpages
.endif
@@ -315,7 +315,7 @@
.include
.include
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_PAGES} != "no"
realinstall: _maninstall
.ORDER: beforeinstall _maninstall
.endif
@@ -327,7 +327,7 @@
${LINT} ${LINTFLAGS} ${CFLAGS:M-[DIU]*} ${.ALLSRC}
.endif
-.if ${MK_MAN} != "no"
+.if ${MK_MAN_PAGES} != "no"
.include
.endif
Index: share/mk/bsd.own.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.83
diff -u -r1.83 bsd.own.mk
--- share/mk/bsd.own.mk26 Mar 2010 17:02:32 - 1.83
+++ share/mk/bsd.own.mk30 Mar 2010 21:20:03 -
@@ -345,6 +345,8 @@
MAILWRAPPER \
MAKE \
MAN \
+MAN_PAGES \
+MAN_UTILS \
NCP \
Re: sparc64/145211: [panic] Memory modified after free
Old Synopsis: Memory modified after free New Synopsis: [panic] Memory modified after free Responsible-Changed-From-To: freebsd-bugs->freebsd-sparc64 Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 30 21:31:03 UTC 2010 Responsible-Changed-Why: Might be specific to sparc64. http://www.freebsd.org/cgi/query-pr.cgi?pr=145211 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/145190: ftp/curl: SSL hangs when running curl
Old Synopsis: SSL hangs when running curl New Synopsis: ftp/curl: SSL hangs when running curl Responsible-Changed-From-To: freebsd-bugs->roam Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 30 21:34:39 UTC 2010 Responsible-Changed-Why: Not sure whether this is a problem with src or ports. roam, can you take a look please? http://www.freebsd.org/cgi/query-pr.cgi?pr=145190 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
The following reply was made to PR bin/38256; it has been noted by GNATS.
From: Alexander Best
To:
Cc:
Subject: Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
Date: Wed, 31 Mar 2010 01:43:42 +0200 (CEST)
fix committed by delphij@ in r205940. please mark patched and assign to him
for mfc reminder.
thanks.
--
Alexander Best
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/38256: [patch] linking pax(1) to pax_{cpio|tar}
Synopsis: [patch] linking pax(1) to pax_{cpio|tar}
State-Changed-From-To: analyzed->patched
State-Changed-By: delphij
State-Changed-When: Tue Mar 30 23:52:51 UTC 2010
State-Changed-Why:
The Makefile has been changed and the references to cpio and tar
were removed now.
Responsible-Changed-From-To: freebsd-bugs->delphij
Responsible-Changed-By: delphij
Responsible-Changed-When: Tue Mar 30 23:52:51 UTC 2010
Responsible-Changed-Why:
Take.
http://www.freebsd.org/cgi/query-pr.cgi?pr=38256
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
On Tue, Mar 30, 2010 at 12:12 PM, Bruce Evans wrote: > On Wed, 31 Mar 2010, Bruce Evans wrote: > >> On Tue, 30 Mar 2010, Garrett Cooper wrote: >> >>> Hi, >>> I'm not 100% satisfied with this patch now. Looking back it fails >>> the following case: >>> >>> -P Do not follow symbolic links in the file hierarchy, instead >>> con- >>> sider the symbolic link itself in any comparisons. This is the >>> default. >> >> -P should have the same semantics and description in all utilities. The >> description should not have grammar errors like the above (comma splice). >> ... >> I now see that the grammar error is from the original version of mtree(1), >> and is probably one of the things you don't like. mtree also has -L, but >> not -R or -P or -h. It is not clear how any utility that traverses trees >> can work without a full complement of -[HLPR] or how any utility that >> ... > > Looking at the actual patch, I now see that it is about a completely > different problem. You would only need to understand the amount of > brokenness of -P to see if you need to use lstat(). I think -P is so > broken that mtree on symlinks doesn't work at all and not using lstat() > would be safest. Hmmm... so I take it that this is actually the first step in many to fixing this underlying problem? I suppose I should be opening bugs for all of the itemized issues that you see in mtree(8) so someone can submit patches to fix the utility? > The patch has some style bugs. Please expound on this -- I want to improve my style (without having to rewrite the entire program of course) -- so that it conforms more to the projects overall style rules; of course there are some cases where I can't readily do that (like pkg_install -- ugh), but I'll do my best to make sure that the rules are withheld. Thanks :), -Garrett ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: gnu/123921: [patch] cpio(1): cpio -oc bug with write_out_header()
Synopsis: [patch] cpio(1): cpio -oc bug with write_out_header() State-Changed-From-To: open->closed State-Changed-By: brd State-Changed-When: Wed Mar 31 02:35:33 UTC 2010 State-Changed-Why: Closed because GNU cpio has been replaced by libarchive(3). http://www.freebsd.org/cgi/query-pr.cgi?pr=123921 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
The following reply was made to PR bin/144411; it has been noted by GNATS. From: Garrett Cooper To: Garrett Cooper Cc: Bruce Evans , bug-followup Subject: Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X Date: Tue, 30 Mar 2010 23:46:20 -0700 On Tue, Mar 30, 2010 at 11:35 PM, Garrett Cooper wrot= e: > On Tue, Mar 30, 2010 at 5:40 PM, Garrett Cooper wro= te: >> On Tue, Mar 30, 2010 at 12:12 PM, Bruce Evans wro= te: >>> On Wed, 31 Mar 2010, Bruce Evans wrote: >>> On Tue, 30 Mar 2010, Garrett Cooper wrote: > Hi, > =A0 =A0I'm not 100% satisfied with this patch now. Looking back it fa= ils > the following case: > > =A0 =A0 -P =A0 =A0Do not follow symbolic links in the file hierarchy,= instead > con- > =A0 =A0 =A0 =A0 =A0 sider the symbolic link itself in any comparisons= . =A0This is the > =A0 =A0 =A0 =A0 =A0 default. -P should have the same semantics and description in all utilities. = =A0The description should not have grammar errors like the above (comma splic= e). ... I now see that the grammar error is from the original version of mtree= (1), and is probably one of the things you don't like. =A0mtree also has -L= , but not -R or -P or -h. =A0It is not clear how any utility that traverses = trees can work without a full complement of -[HLPR] or how any utility that ... >>> >>> Looking at the actual patch, I now see that it is about a completely >>> different problem. =A0You would only need to understand the amount of >>> brokenness of -P to see if you need to use lstat(). =A0I think -P is so >>> broken that mtree on symlinks doesn't work at all and not using lstat() >>> would be safest. >> >> Hmmm... so I take it that this is actually the first step in many to >> fixing this underlying problem? I suppose I should be opening bugs for >> all of the itemized issues that you see in mtree(8) so someone can >> submit patches to fix the utility? >> >>> The patch has some style bugs. >> >> Please expound on this -- I want to improve my style (without having >> to rewrite the entire program of course) -- so that it conforms more >> to the projects overall style rules; of course there are some cases >> where I can't readily do that (like pkg_install -- ugh), but I'll do >> my best to make sure that the rules are withheld. > > s/withheld/held/ > > I guess the problem was the fact that I didn't use 8-space tabs for > first-level tabs? Hard tabs are fine, correct? Ah, the braces for the single line conditional. Yes, I see what you mean now (fixed). Also, I see what you mean about -P being broken; mtree(8) uses chmod instead of lchmod, chown instead of lchown, etc. This definitely needs fixing and I'll assign separate PRs for it. Thanks, -Garrett ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X
The following reply was made to PR bin/144411; it has been noted by GNATS. From: Garrett Cooper To: Garrett Cooper Cc: Bruce Evans , bug-followup Subject: Re: bin/144411: [patch] mtree(8) doesn't reject non-regular files for -X Date: Tue, 30 Mar 2010 23:47:08 -0700 --005045016abd7713880483131dc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2010 at 11:46 PM, Garrett Cooper wrot= e: > On Tue, Mar 30, 2010 at 11:35 PM, Garrett Cooper wr= ote: >> On Tue, Mar 30, 2010 at 5:40 PM, Garrett Cooper wr= ote: >>> On Tue, Mar 30, 2010 at 12:12 PM, Bruce Evans wr= ote: On Wed, 31 Mar 2010, Bruce Evans wrote: > On Tue, 30 Mar 2010, Garrett Cooper wrote: > >> Hi, >> =A0 =A0I'm not 100% satisfied with this patch now. Looking back it f= ails >> the following case: >> >> =A0 =A0 -P =A0 =A0Do not follow symbolic links in the file hierarchy= , instead >> con- >> =A0 =A0 =A0 =A0 =A0 sider the symbolic link itself in any comparison= s. =A0This is the >> =A0 =A0 =A0 =A0 =A0 default. > > -P should have the same semantics and description in all utilities. = =A0The > description should not have grammar errors like the above (comma spli= ce). > ... > I now see that the grammar error is from the original version of mtre= e(1), > and is probably one of the things you don't like. =A0mtree also has -= L, but > not -R or -P or -h. =A0It is not clear how any utility that traverses= trees > can work without a full complement of -[HLPR] or how any utility that > ... Looking at the actual patch, I now see that it is about a completely different problem. =A0You would only need to understand the amount of brokenness of -P to see if you need to use lstat(). =A0I think -P is s= o broken that mtree on symlinks doesn't work at all and not using lstat(= ) would be safest. >>> >>> Hmmm... so I take it that this is actually the first step in many to >>> fixing this underlying problem? I suppose I should be opening bugs for >>> all of the itemized issues that you see in mtree(8) so someone can >>> submit patches to fix the utility? >>> The patch has some style bugs. >>> >>> Please expound on this -- I want to improve my style (without having >>> to rewrite the entire program of course) -- so that it conforms more >>> to the projects overall style rules; of course there are some cases >>> where I can't readily do that (like pkg_install -- ugh), but I'll do >>> my best to make sure that the rules are withheld. >> >> s/withheld/held/ >> >> I guess the problem was the fact that I didn't use 8-space tabs for >> first-level tabs? Hard tabs are fine, correct? > > =A0 =A0Ah, the braces for the single line conditional. Yes, I see what > you mean now (fixed). > =A0 =A0Also, I see what you mean about -P being broken; mtree(8) uses > chmod instead of lchmod, chown instead of lchown, etc. This definitely > needs fixing and I'll assign separate PRs for it. Sorry -- forgot the patch. -Garrett --005045016abd7713880483131dc3 Content-Type: text/plain; charset=US-ASCII; name="bin.144411.diff.txt" Content-Disposition: attachment; filename="bin.144411.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g7frx53q0 CkluZGV4OiBleGNsdWRlcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV4Y2x1ZGVzLmMJKHJldmlzaW9uIDIw NDUzMikKKysrIGV4Y2x1ZGVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTMxLDYgKzMxLDcgQEAKIF9f RkJTRElEKCIkRnJlZUJTRCQiKTsKIAogI2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUg PHN5cy9zdGF0Lmg+CiAjaW5jbHVkZSA8c3lzL3RpbWUuaD4JCS8qIFhYWCBmb3IgbXRyZWUuaCAq LwogI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgogCkBAIC0zOSw2ICs0MCw3IEBACiAjaW5jbHVkZSA8 ZnRzLmg+CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KKyNpbmNsdWRl IDxlcnJuby5oPgogCiAjaW5jbHVkZSAibXRyZWUuaCIJCS8qIFhYWCBmb3IgZXh0ZXJuLmggKi8K ICNpbmNsdWRlICJleHRlcm4uaCIKQEAgLTY2LDEwICs2OCwyMyBAQAogCUZJTEUgKmZwOwogCWNo YXIgKmxpbmUsICpzdHI7CiAJc3RydWN0IGV4Y2x1ZGUgKmU7CisJc3RydWN0IHN0YXQgZXhjbHVk ZV9zdGF0OwogCXNpemVfdCBsZW47CiAKKwkvKiBMZXQncyByZXNvbHZlIHRoZSBuYW1lIHZpYSBz dGF0KDIpIHNvIHN5bWxpbmtzIHRvIGZpbGVzIHBhc3MuICovCisJaWYgKHN0YXQobmFtZSwgJmV4 Y2x1ZGVfc3RhdCkgPCAwKSB7CisJCWVycigxLCAiJXMiLCBuYW1lKTsKKwl9CisJLyogRG9uJ3Qg bGV0IGNlcnRhaW4gZmlsZXMgbGlrZSBkaXJlY3RvcmllcywgZmlmb3MsIGV0YyBwYXNzLiAqLwor CWlmICghU19JU1JFRyhleGNsdWRlX3N0YXQuc3RfbW9kZSkpIHsKKwkJLyogTWFrZSB0aGUgZXJy b3IgbWVzc2FnZSBtYWtlIHNlbnNlIGZvciB0aGUgZGlyZWN0b3J5IGVycm9yCisJCSAqIGNhc2Uu IEFsbCBvdGhlciB2YWx1ZXMgY2FuIGJlIEVJTlZBTC4gKi8KKwkJZXJybm8gPSBTX0lTRElSKGV4 Y2x1ZGVfc3RhdC5zdF9tb2RlKSA/IEVJU0RJUiA6IEVJTlZBTDsKKwkJZXJyKDEsICIlcyIsIG5h bWUpOworCX0KKwogCWZwID0gZm9wZW4obmFtZSwgInIiKTsKLQlpZiAoZnAgPT0gMCkKKwlpZiAo ZnAgPT0gTlVMTCkKIAkJZXJyKDEsICIlcyIsIG5hbWUpOwogCiAJd2hpbGUgKChsaW5lID0gZmdl dGxuKGZwLCAmbGVuKSkgIT0gMCkgewoKCg==
