svn commit: r267063 - head/sbin/geom/class/label
Author: ivoras Date: Wed Jun 4 16:29:18 2014 New Revision: 267063 URL: http://svnweb.freebsd.org/changeset/base/267063 Log: Bulk document the kern.geom.label.*.enable sysctls and tunables. Modified: head/sbin/geom/class/label/glabel.8 Modified: head/sbin/geom/class/label/glabel.8 == --- head/sbin/geom/class/label/glabel.8 Wed Jun 4 16:06:38 2014 (r267062) +++ head/sbin/geom/class/label/glabel.8 Wed Jun 4 16:29:18 2014 (r267063) @@ -223,6 +223,19 @@ This can be set to a number between 0 an If set to 0 minimal debug information is printed, and if set to 2 the maximum amount of debug information is printed. .El +.Bl -tag -width indent +.It Va kern.geom.label.*.enable : No 1 +Most +.Nm LABEL +providers implement a +.Xr sysctl 8 +flag and a tunable variable named in the above format. This flag +controls if the label provider will be active, tasting devices +and creating label nodes in the +.Xr devfs 5 +tree. It is sometimes desirable to disable certain label types if +they conflict with other classes in complex GEOM topologies. +.Bl .Sh EXIT STATUS Exit status is 0 on success, and 1 if the command fails. .Sh EXAMPLES ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r266972 - head/sbin/geom/class/label
Hi, None of the other classes have the sysctls documented here, there's only a description of the kern.geom.label.debug flag. I guess adding a wildcard catch-all section for the kern.geom.label.*.enable would be best here. On 3 June 2014 00:31, John-Mark Gurney j...@funkthat.com wrote: Ivan Voras wrote this message on Mon, Jun 02, 2014 at 15:05 +: Author: ivoras Date: Mon Jun 2 15:05:25 2014 New Revision: 266972 URL: http://svnweb.freebsd.org/changeset/base/266972 Log: Document the diskid automatic label class. While there, also document the glabel native labels and explain why there are additional nodes created for nested GEOM classes. Reminded by:jmg Shouldn't kern.geom.label.disk_ident.enable also be documented here? Thanks! -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r266972 - head/sbin/geom/class/label
Author: ivoras Date: Mon Jun 2 15:05:25 2014 New Revision: 266972 URL: http://svnweb.freebsd.org/changeset/base/266972 Log: Document the diskid automatic label class. While there, also document the glabel native labels and explain why there are additional nodes created for nested GEOM classes. Reminded by: jmg Modified: head/sbin/geom/class/label/glabel.8 Modified: head/sbin/geom/class/label/glabel.8 == --- head/sbin/geom/class/label/glabel.8 Mon Jun 2 13:48:57 2014 (r266971) +++ head/sbin/geom/class/label/glabel.8 Mon Jun 2 15:05:25 2014 (r266972) @@ -130,8 +130,26 @@ GPT UUIDs (directory .Pa /dev/gptid/ ) . .El .Pp -Generic labels are created in the directory -.Pa /dev/label/ . +Generic disk ID strings are exported as labels in the format +.Pa /dev/diskid/GEOM_CLASS-ident +e.g. +.Pa /dev/diskid/DISK-6QG3Z026 . +.Pp +Generic labels created and managed solely by +.Xr glabel 8 +are created in the +.Pa /dev/label/ +directory. +.Pp +Note that for all label types, nested GEOM classes will cause additional +device nodes to be created, with context-specific data appended to their +names. E.g. for every node like +.Pa /dev/label/bigdisk +there will be additional entries for any partitions which the device +contains, like +.Pa /dev/label/bigdiskp1 +and +.Pa /dev/label/bigdiskp1a . .Pp The first argument to .Nm ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r262332 - head/share/man/man4
Author: ivoras Date: Sat Feb 22 09:53:17 2014 New Revision: 262332 URL: http://svnweb.freebsd.org/changeset/base/262332 Log: Grammar fix Submitted by: Warren Block wblock AT wonkity.com Modified: head/share/man/man4/ada.4 Modified: head/share/man/man4/ada.4 == --- head/share/man/man4/ada.4 Sat Feb 22 07:18:06 2014(r262331) +++ head/share/man/man4/ada.4 Sat Feb 22 09:53:17 2014(r262332) @@ -126,7 +126,7 @@ The default is currently enabled. .It Va kern.cam.ada.write_cache .It Va kern.cam.ada. Ns Ar X Ns Va .write_cache .Pp -These variables determines whether device write cache should be enabled +These variables determine whether device write cache should be enabled globally or per-device or disabled. Set to 1 to enable write cache, 0 to disable, -1 to leave it as-is. Values modified at runtime take effect only after device reset ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r262294 - head/share/man/man4
Author: ivoras Date: Fri Feb 21 12:17:27 2014 New Revision: 262294 URL: http://svnweb.freebsd.org/changeset/base/262294 Log: Explain how and where kern.cam.ada.write_cache can be set in practical situations. Reviewed by: hrs Approved by: mav Modified: head/share/man/man4/ada.4 Modified: head/share/man/man4/ada.4 == --- head/share/man/man4/ada.4 Fri Feb 21 11:06:22 2014(r262293) +++ head/share/man/man4/ada.4 Fri Feb 21 12:17:27 2014(r262294) @@ -25,7 +25,7 @@ .\ .\ $FreeBSD$ .\ -.Dd February 8, 2012 +.Dd February 21, 2014 .Dt ADA 4 .Os .Sh NAME @@ -129,8 +129,13 @@ The default is currently enabled. These variables determines whether device write cache should be enabled globally or per-device or disabled. Set to 1 to enable write cache, 0 to disable, -1 to leave it as-is. -Values modified in runtime take effect only after device reset. -The global default is currently enabled. +Values modified at runtime take effect only after device reset +.Pq using the reset subcommand of Xr camcontrol 8 . +Because of that, this setting should be changed in +.Pa /boot/loader.conf +instead of +.Pa /etc/sysctl.conf . +The global default is currently 1. The per-device default is to leave it as-is (follow global setting). .El .Sh FILES ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r255202 - head/sys/netgraph/netflow
On 4 September 2013 12:17, Gleb Smirnoff gleb...@freebsd.org wrote: Log: Make default cache size more modern. -#defineCACHESIZE (65536*4) +#defineCACHESIZE (65536*16) Things like this make me wonder if there shouldn't be a constant somehwere in an ubiquitous header which would basically be a single place to modify and which would cascade all over the place. Maybe even something like a macro based on something like a YEAR_OF_RELEASE, so e.g. the code becomes #define AUTO_TUNE_BASE (YEAR_OF_RELEASE - 2000) #define AUTO_TUNE_AGGRESIVE (AUTO_TUNE_BASE * 2) #define AUTO_TUNE_CONSERVATIVE ((AUTO_TUNE_BASE * 6) / 5) #define CACHESIZE (65536 * (4 + AUTO_TUNE_CONSERVATIVE)) Of course, some power-of-2 variants should also exist... ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r254986 - head/sys/ufs/ufs
Author: ivoras Date: Wed Aug 28 10:06:20 2013 New Revision: 254986 URL: http://svnweb.freebsd.org/changeset/base/254986 Log: Take a very small step toward the Century of the Anchovy by increasing the time dirhash entries stay in memory before being considered for eviction to 1 minute. Modified: head/sys/ufs/ufs/ufs_dirhash.c Modified: head/sys/ufs/ufs/ufs_dirhash.c == --- head/sys/ufs/ufs/ufs_dirhash.c Wed Aug 28 07:48:44 2013 (r254985) +++ head/sys/ufs/ufs/ufs_dirhash.c Wed Aug 28 10:06:20 2013 (r254986) @@ -85,7 +85,7 @@ SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_d static int ufs_dirhashlowmemcount = 0; SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_lowmemcount, CTLFLAG_RD, ufs_dirhashlowmemcount, 0, number of times low memory hook called); -static int ufs_dirhashreclaimage = 5; +static int ufs_dirhashreclaimage = 60; SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_reclaimage, CTLFLAG_RW, ufs_dirhashreclaimage, 0, max time in seconds of hash inactivity before deletion in low VM events); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254986 - head/sys/ufs/ufs
On 28 August 2013 12:25, Davide Italiano dav...@freebsd.org wrote: do you have any evidence that this change impacts positively (or negatively) performances for some workloads? If yes, can you share? Yes, observation of my own servers. Without this, dirhash is basically useless since in certain situations everything gets evicted after 5 seconds and it never grows to its full potential. Also, why did you choose the '60' value (rather than something else)? Personal experience. I don't see any 'Reviewed by:' line in your commit message neither I remember a public discussion on -current or -arch or -fs about this. OTOH I think such changes deserve a wider discussion. See discussion in @stable. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254986 - head/sys/ufs/ufs
On 28 August 2013 12:44, Davide Italiano dav...@freebsd.org wrote: Do you realize that this is a driven by commit change, right? And there's no technical motivatiion about this or experimental data that confirms you've chossen the right value? I see from the archives that you didn't get any feedback by anyone working in the VM layer or by some UFS maintainer. I don't even comment about discussing -CURRENT changes in stable@. You have a point that this was a judgment call, but note that the last change to dirhash tuning (maxmem) was also done by me. Since this is -CURRENT, I will leave this commit in unless it proves detrimental in the usual testing which goes on. If you still feel strongly about this, contact me in private and we'll investigate its effects in more detail. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254986 - head/sys/ufs/ufs
On 28 August 2013 13:14, Davide Italiano dav...@freebsd.org wrote: I prefer to see a public discussion about this. Ok, Ok, I'll go start a retrograde disucussion on @filesystems :) Maybe you should come up with some evidence that your change is helpful, even after this commit. I'll try and dig something up. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
We have a single-writer / multiple-readers lock on *any particular byte* of a vnode. The rangelock code is what keeps track of this, and the locking contention I was reducing was in the rangelock bookkeeping. So, for example, if multiple processes or multiple threads read or write a file somewhat unintelligently (a small file, operations on the whole file, like in blogbench), they will effectively content for the byte 0, right? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 15 August 2013 22:19, Colin Percival cperc...@freebsd.org wrote: For workloads with R parallel reads and W parallel writes, this improves the time spent from O((R+W)^2) to O(W*(R+W)); i.e., heavy parallel-read workloads become significantly more scalable. No statistically significant change in buildworld time has been measured, but synthetic tests of parallel 'dd /dev/null' and 'openssl enc /dev/null' with the input file cached yield dramatic (up to 10x) improvement with high (up to 128 processes) levels of parallelism. That's interesting. Have you tried running the blogbench benchmark before after? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254380 - in head/sys: kern sys
On 15 August 2013 22:32, Colin Percival cperc...@freebsd.org wrote: No, I wasn't aware that it existed. Given that this change applies only to parallel operations *on the same vnode* and blogbench seems to have traffic randomly spread between many files, I doubt there would be any difference. Maybe it could help a bit on the directories? Whatever the problem may be (does FreeBSD still have single-writer + multiple readers lock for processes accessing the same vnode?), there is a huge difference in performance with blogbench between FreeBSD and Linux. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r249581 - head/sys/modules/geom/geom_label
Author: ivoras Date: Wed Apr 17 09:19:29 2013 New Revision: 249581 URL: http://svnweb.freebsd.org/changeset/base/249581 Log: Link g_label_disk_ident when building geom_label as a module Modified: head/sys/modules/geom/geom_label/Makefile Modified: head/sys/modules/geom/geom_label/Makefile == --- head/sys/modules/geom/geom_label/Makefile Wed Apr 17 07:31:53 2013 (r249580) +++ head/sys/modules/geom/geom_label/Makefile Wed Apr 17 09:19:29 2013 (r249581) @@ -4,6 +4,7 @@ KMOD= geom_label SRCS= g_label.c +SRCS+= g_label_disk_ident.c SRCS+= g_label_ext2fs.c SRCS+= g_label_gpt.c SRCS+= g_label_iso9660.c ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r249508 - in head/sys: conf geom/label
On 16 April 2013 11:31, Jaakko Heinonen j...@freebsd.org wrote: On 2013-04-15, Ivan Voras wrote: Introduce glabel labels based on GEOM ident attributes. In this initial implementation, error on the side of conservatism and only create labels for GEOMs of classes DISK and MULTIPATH. After this commit I get a panic on boot. My kernel has been compiled with gcc. Thanks for the report, I'm investigating it. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r249564 - head/sys/geom/label
Author: ivoras
Date: Tue Apr 16 19:58:24 2013
New Revision: 249564
URL: http://svnweb.freebsd.org/changeset/base/249564
Log:
Fix the buffer-overflow-fixing fixes.
Pointy-hat to: me, for not realizing snprintf() is available in kernel.
Thanks to: jh, for bringing me the good news of snprintf(), Pawel Worach, for
noting that the panic can be provoked in i386 and not in amd64
Modified:
head/sys/geom/label/g_label_disk_ident.c
Modified: head/sys/geom/label/g_label_disk_ident.c
==
--- head/sys/geom/label/g_label_disk_ident.cTue Apr 16 19:39:27 2013
(r249563)
+++ head/sys/geom/label/g_label_disk_ident.cTue Apr 16 19:58:24 2013
(r249564)
@@ -40,38 +40,41 @@ __FBSDID($FreeBSD$);
#define G_LABEL_DISK_IDENT_DIR diskid
-static char* classes_pass[] = { G_DISK_CLASS_NAME, G_MULTIPATH_CLASS_NAME,
NULL };
+static char* classes_pass[] = { G_DISK_CLASS_NAME, G_MULTIPATH_CLASS_NAME,
+NULL };
static void
g_label_disk_ident_taste(struct g_consumer *cp, char *label, size_t size)
{
struct g_class *cls;
char ident[100];
- int ident_len = sizeof(ident);
+ int ident_len, found, i;
g_topology_assert_not();
label[0] = '\0';
cls = cp-provider-geom-class;
- /* Get the GEOM::ident string and construct a label in the format
CLASS_NAME-ident */
+ /*
+* Get the GEOM::ident string, and construct a label in the format
+* CLASS_NAME-ident
+*/
+ ident_len = sizeof(ident);
if (g_io_getattr(GEOM::ident, cp, ident_len, ident) == 0) {
- int i, found = 0;
-
if (ident_len == 0 || ident[0] == '\0')
return;
- for (i = 0; classes_pass[i] != NULL; i++)
- if (strcmp(classes_pass[i], cls-name) == 0)
+ for (i = 0, found = 0; classes_pass[i] != NULL; i++)
+ if (strcmp(classes_pass[i], cls-name) == 0) {
found = 1;
+ break;
+ }
if (!found)
return;
- if (strlen(cls-name) + ident_len + 2 size)
- ident[ident_len - strlen(cls-name) - 2] = '\0';
- else
- ident[ident_len] = '\0';
- strcpy(label, cls-name);
- strcat(label, -);
- strcat(label, ident);
+ /*
+* We can safely ignore the result of strncpy; the label will
+* simply be truncated, which at most is only annoying.
+*/
+ (void)snprintf(label, size, %s-%s, cls-name, ident);
}
}
@@ -81,4 +84,5 @@ struct g_label_desc g_label_disk_ident =
.ld_enabled = 1
};
-G_LABEL_INIT(disk_ident, g_label_disk_ident, Create device nodes for drives
which export a disk identification string);
+G_LABEL_INIT(disk_ident, g_label_disk_ident, Create device nodes for drives
+which export a disk identification string);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r249571 - head/sys/geom/label
Author: ivoras Date: Tue Apr 16 22:42:40 2013 New Revision: 249571 URL: http://svnweb.freebsd.org/changeset/base/249571 Log: Comment typo fix. Is aware of the importance of comments: dim Modified: head/sys/geom/label/g_label_disk_ident.c Modified: head/sys/geom/label/g_label_disk_ident.c == --- head/sys/geom/label/g_label_disk_ident.cTue Apr 16 22:09:08 2013 (r249570) +++ head/sys/geom/label/g_label_disk_ident.cTue Apr 16 22:42:40 2013 (r249571) @@ -71,8 +71,8 @@ g_label_disk_ident_taste(struct g_consum if (!found) return; /* -* We can safely ignore the result of strncpy; the label will -* simply be truncated, which at most is only annoying. +* We can safely ignore the result of snprintf(): the label +* will simply be truncated, which at most is only annoying. */ (void)snprintf(label, size, %s-%s, cls-name, ident); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r249564 - head/sys/geom/label
On 16 April 2013 22:01, Dimitry Andric d...@freebsd.org wrote: On Apr 16, 2013, at 21:58, Ivan Voras ivo...@freebsd.org wrote: Author: ivoras Date: Tue Apr 16 19:58:24 2013 New Revision: 249564 URL: http://svnweb.freebsd.org/changeset/base/249564 Log: Fix the buffer-overflow-fixing fixes. ... + /* + * We can safely ignore the result of strncpy; the label will + * simply be truncated, which at most is only annoying. + */ + (void)snprintf(label, size, %s-%s, cls-name, ident); s/strncpy/snprintf/ ? :-) The typo fairy is strong this day :) Thanks! ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r249507 - head/sys/geom
Author: ivoras
Date: Mon Apr 15 15:55:40 2013
New Revision: 249507
URL: http://svnweb.freebsd.org/changeset/base/249507
Log:
Introduce a symbol for the GEOM class name instead of using the ad-hoc string
constant.
Modified:
head/sys/geom/geom_disk.c
head/sys/geom/geom_disk.h
head/sys/geom/geom_dump.c
Modified: head/sys/geom/geom_disk.c
==
--- head/sys/geom/geom_disk.c Mon Apr 15 13:00:42 2013(r249506)
+++ head/sys/geom/geom_disk.c Mon Apr 15 15:55:40 2013(r249507)
@@ -75,7 +75,7 @@ static g_dumpconf_t g_disk_dumpconf;
static g_provgone_t g_disk_providergone;
static struct g_class g_disk_class = {
- .name = DISK,
+ .name = G_DISK_CLASS_NAME,
.version = G_VERSION,
.start = g_disk_start,
.access = g_disk_access,
Modified: head/sys/geom/geom_disk.h
==
--- head/sys/geom/geom_disk.h Mon Apr 15 13:00:42 2013(r249506)
+++ head/sys/geom/geom_disk.h Mon Apr 15 15:55:40 2013(r249507)
@@ -44,6 +44,8 @@
#include sys/_mutex.h
#include sys/disk.h
+#define G_DISK_CLASS_NAME DISK
+
struct disk;
typedefint disk_open_t(struct disk *);
Modified: head/sys/geom/geom_dump.c
==
--- head/sys/geom/geom_dump.c Mon Apr 15 13:00:42 2013(r249506)
+++ head/sys/geom/geom_dump.c Mon Apr 15 15:55:40 2013(r249507)
@@ -44,6 +44,7 @@ __FBSDID($FreeBSD$);
#include geom/geom.h
#include geom/geom_int.h
+#include geom/geom_disk.h
static void
@@ -146,7 +147,7 @@ g_conftxt(void *p, int flag)
sb = p;
g_topology_assert();
LIST_FOREACH(mp, g_classes, class) {
- if (!strcmp(mp-name, DISK) || !strcmp(mp-name, MD))
+ if (!strcmp(mp-name, G_DISK_CLASS_NAME) || !strcmp(mp-name,
MD))
g_conftxt_class(sb, mp);
}
sbuf_finish(sb);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r249508 - in head/sys: conf geom/label
Author: ivoras
Date: Mon Apr 15 16:09:24 2013
New Revision: 249508
URL: http://svnweb.freebsd.org/changeset/base/249508
Log:
Introduce glabel labels based on GEOM ident attributes. In this initial
implementation, error on the side of conservatism and only create labels
for GEOMs of classes DISK and MULTIPATH.
Discussed with: trasz
Approved by: silence from freebsd-geom@
Added:
head/sys/geom/label/g_label_disk_ident.c (contents, props changed)
Modified:
head/sys/conf/files
head/sys/geom/label/g_label.c
head/sys/geom/label/g_label.h
Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Apr 15 15:55:40 2013(r249507)
+++ head/sys/conf/files Mon Apr 15 16:09:24 2013(r249508)
@@ -2495,6 +2495,7 @@ geom/label/g_label_ntfs.c optional geom_
geom/label/g_label_reiserfs.c optional geom_label
geom/label/g_label_ufs.c optional geom_label
geom/label/g_label_gpt.c optional geom_label
+geom/label/g_label_disk_ident.coptional geom_label
geom/linux_lvm/g_linux_lvm.c optional geom_linux_lvm
geom/mirror/g_mirror.c optional geom_mirror
geom/mirror/g_mirror_ctl.c optional geom_mirror
Modified: head/sys/geom/label/g_label.c
==
--- head/sys/geom/label/g_label.c Mon Apr 15 15:55:40 2013
(r249507)
+++ head/sys/geom/label/g_label.c Mon Apr 15 16:09:24 2013
(r249508)
@@ -89,6 +89,7 @@ const struct g_label_desc *g_labels[] =
g_label_ntfs,
g_label_gpt,
g_label_gpt_uuid,
+ g_label_disk_ident,
NULL
};
@@ -339,7 +340,7 @@ g_label_taste(struct g_class *mp, struct
pp-mediasize - pp-sectorsize);
} while (0);
for (i = 0; g_labels[i] != NULL; i++) {
- char label[64];
+ char label[128];
if (g_labels[i]-ld_enabled == 0)
continue;
Modified: head/sys/geom/label/g_label.h
==
--- head/sys/geom/label/g_label.h Mon Apr 15 15:55:40 2013
(r249507)
+++ head/sys/geom/label/g_label.h Mon Apr 15 16:09:24 2013
(r249508)
@@ -87,6 +87,7 @@ extern struct g_label_desc g_label_reise
extern struct g_label_desc g_label_ntfs;
extern struct g_label_desc g_label_gpt;
extern struct g_label_desc g_label_gpt_uuid;
+extern struct g_label_desc g_label_disk_ident;
#endif /* _KERNEL */
struct g_label_metadata {
Added: head/sys/geom/label/g_label_disk_ident.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/geom/label/g_label_disk_ident.cMon Apr 15 16:09:24 2013
(r249508)
@@ -0,0 +1,84 @@
+/*-
+ * Copyright (c) 2012 Ivan Voras ivo...@freebsd.org
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+
+#include sys/param.h
+#include sys/systm.h
+#include sys/kernel.h
+#include sys/malloc.h
+
+#include geom/geom.h
+#include geom/geom_disk.h
+#include geom/label/g_label.h
+#include geom/multipath/g_multipath.h
+
+
+#define G_LABEL_DISK_IDENT_DIR diskid
+
+static char* classes_pass[] = { G_DISK_CLASS_NAME, G_MULTIPATH_CLASS_NAME,
NULL };
+
+static void
+g_label_disk_ident_taste(struct g_consumer *cp, char *label, size_t size)
+{
+ struct g_class *cls;
+ char ident[100];
+ int ident_len = sizeof(ident);
+
+ g_topology_assert_not();
+ label[0] = '\0';
+
+ cls = cp-provider-geom-class
Re: svn commit: r244385 - head/sys/kern
On 18 December 2012 08:36, Andrey Zonov z...@freebsd.org wrote: Author: zont Date: Tue Dec 18 07:36:45 2012 New Revision: 244385 URL: http://svnweb.freebsd.org/changeset/base/244385 Log: - Add sysctl to allow unprivileged users to call mlock(2)-family system calls and turn it on. - Do not allow to call them inside jail. [1] There's a sysctl branch security.jail.param.allow. which might be useful here to add for jails. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r240462 - head/share/man/man5
Author: ivoras Date: Thu Sep 13 10:26:55 2012 New Revision: 240462 URL: http://svn.freebsd.org/changeset/base/240462 Log: Document the *_chroot, *_user, *_group and *_nice knobs for services started by rcng. Reviewed by: wblock, dougb Modified: head/share/man/man5/rc.conf.5 Modified: head/share/man/man5/rc.conf.5 == --- head/share/man/man5/rc.conf.5 Thu Sep 13 10:25:42 2012 (r240461) +++ head/share/man/man5/rc.conf.5 Thu Sep 13 10:26:55 2012 (r240462) @@ -168,6 +168,22 @@ If set to .Dq Li NO , no swapfile is installed, otherwise the value is used as the full pathname to a file to use for additional swap space. +.It Va Ns Ao Ar name Ac Ns Va _chroot +.Pq Vt str +.Xr chroot +to this directory before running the service. +.It Va Ns Ao Ar name Ac Ns Va _user +.Pq Vt str +Run the service under this user account. +.It Va Ns Ao Ar name Ac Ns Va _group +.Pq Vt str +Run the chrooted service under this system group. Unlike the _user +setting, this setting has no effect if the service is not chrooted. +.It Ns Ao Ar name Ac Ns Va _nice +.Pq Vt int +The +.Xr nice 1 +value to run the service under. .It Va apm_enable .Pq Vt bool If set to ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r233294 - in head: . contrib/com_err crypto/heimdal crypto/heimdal/admin crypto/heimdal/appl crypto/heimdal/appl/afsutil crypto/heimdal/appl/ftp crypto/heimdal/appl/ftp/common crypto/h
On 25 March 2012 12:59, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Mar 22, 2012 at 08:48:44AM +, Stanislav Sedov wrote: - Heimdal's KDC now require sqlite to operate. We use the bundled version and install it as libheimsqlite. If some other FreeBSD components will require it in the future we can rename it to libbsdsqlite and use for these components as well. Can some ports (svn, for example) use this library? Judging from past experience, that would not be a good idea. However, libbsdsqlite is a *very* good idea, now that there's finally one user it which cannot be hacked around :) It will help both present development (the pkgng is also AFAIK using sqlite) and future developments (all the little binary-blob databases in the system could finally use something structured and future-proof). I will personally teach any doubting Thomas on how wonderful sqlite and SQL in general really is [*] ;) [*] for their specific, narrow field of application, of course ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r233506 - head/etc
Author: ivoras Date: Mon Mar 26 11:48:47 2012 New Revision: 233506 URL: http://svn.freebsd.org/changeset/base/233506 Log: Add MySQL port 3306 Obtained from:http://www.iana.org/assignments/port-numbers MFC after:1 week Modified: head/etc/services Modified: head/etc/services == --- head/etc/services Mon Mar 26 09:34:17 2012(r233505) +++ head/etc/services Mon Mar 26 11:48:47 2012(r233506) @@ -2219,6 +2219,8 @@ iscsi-target 3260/tcp # iSCSI port iscsi-target 3260/udp # iSCSI port ccmail 3264/tcp #cc:mail/lotus ccmail 3264/udp #cc:mail/lotus +mysql 3306/tcp #MySQL +mysql 3306/udp #MySQL dec-notes /tcp #DEC Notes dec-notes /udp #DEC Notes rdp3389/tcp #Microsoft Remote Desktop Protocol ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r232547 - head/sys/kern
Author: ivoras
Date: Mon Mar 5 14:19:43 2012
New Revision: 232547
URL: http://svn.freebsd.org/changeset/base/232547
Log:
Print out process name and thread id in the debugging message.
This is useful because the message can end up in system logs in
non-debugging operation.
Reviewed by: attilio (earlier version)
Modified:
head/sys/kern/kern_lock.c
Modified: head/sys/kern/kern_lock.c
==
--- head/sys/kern/kern_lock.c Mon Mar 5 14:04:12 2012(r232546)
+++ head/sys/kern/kern_lock.c Mon Mar 5 14:19:43 2012(r232547)
@@ -1277,8 +1277,9 @@ lockmgr_printinfo(const struct lock *lk)
(uintmax_t)LK_SHARERS(lk-lk_lock));
else {
td = lockmgr_xholder(lk);
- printf(lock type %s: EXCL by thread %p (pid %d)\n,
- lk-lock_object.lo_name, td, td-td_proc-p_pid);
+ printf(lock type %s: EXCL by thread %p
+ (pid %d, %s, tid %d)\n, lk-lock_object.lo_name, td,
+ td-td_proc-p_pid, td-td_proc-p_comm, td-td_tid);
}
x = lk-lk_lock;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r232209 - in head: lib/libthr/thread sys/kern
On 27 February 2012 14:38, David Xu davi...@freebsd.org wrote: Author: davidxu Date: Mon Feb 27 13:38:52 2012 New Revision: 232209 URL: http://svn.freebsd.org/changeset/base/232209 Log: Follow changes made in revision 232144, pass absolute timeout to kernel, this eliminates a clock_gettime() syscall. Any chance of a MFC? I use rwlocks a lot; removing a syscall from all operations looks like a nice improvement. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230984 - head/sys/kern
On 4 February 2012 17:49, Ryan Stone rst...@freebsd.org wrote: Author: rstone Date: Sat Feb 4 16:49:29 2012 New Revision: 230984 URL: http://svn.freebsd.org/changeset/base/230984 Log: Whenever a new kernel thread is spawned, explicitly clear any CPU affinity set on the new thread. This prevents the thread from inadvertently inheriting affinity from a random sibling. Shouldn't new threads inherit affinity from the threads which spawned them? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228424 - in head/sys: kern sys
On 23 January 2012 23:53, Florian Smeets f...@freebsd.org wrote: which creates a database work set of ~1.5GB. Max throughput was achieved at 20 Clients. At 40 threads the results varied between 43000 - 76500 across reboots. Attilio suspects that this can be caused by the kernel memory layout changing under the woods creating cache effects difficult to control, therefor the scaling factor was reduced to 10 (~150MB work set) and the numbers got deterministic across reboot. Or possibly NUMA? Though 40 processes and 1.5 GB seem too low for NUMA effects to be so noticable... Was the round-robin allocator talked about in here: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-October/036525.html ever actually committed? I seem to remember some other thread which said it wasn't yet but can't find it now, and I also cannot find the commit. AFAIK the current state of NUMA is still described in http://svn.freebsd.org/changeset/base/210550 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230207 - in head/sys: netinet sys
2012/1/19 Gleb Smirnoff gleb...@freebsd.org: Do you use them? Or do you know software that use them? That's easy: Google: SIOCSIFADDR About 55,400 results A different question is if any *important* software uses it... ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r230221 - head/sys/ufs/ufs
Author: ivoras
Date: Mon Jan 16 15:47:42 2012
New Revision: 230221
URL: http://svn.freebsd.org/changeset/base/230221
Log:
Add a bit of verbosity to the comment.
Modified:
head/sys/ufs/ufs/ufs_dirhash.c
Modified: head/sys/ufs/ufs/ufs_dirhash.c
==
--- head/sys/ufs/ufs/ufs_dirhash.c Mon Jan 16 15:38:45 2012
(r230220)
+++ head/sys/ufs/ufs/ufs_dirhash.c Mon Jan 16 15:47:42 2012
(r230221)
@@ -1248,7 +1248,12 @@ ufsdirhash_lowmem()
{
struct dirhash *dh, *dh_temp;
int memfreed = 0;
- /* XXX: this 10% may need to be adjusted */
+ /*
+* Will free a *minimum* of 10% of the dirhash, but possibly much
+* more (depending on dirhashreclaimage). System with large dirhashes
+* probably also need a much larger dirhashreclaimage.
+* XXX: this percentage may need to be adjusted.
+*/
int memwanted = ufs_dirhashmem / 10;
ufs_dirhashlowmemcount++;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r227822 - head/sys/fs/tmpfs
Author: ivoras
Date: Tue Nov 22 16:18:12 2011
New Revision: 227822
URL: http://svn.freebsd.org/changeset/base/227822
Log:
Avoid panics from recursive rename operations. Not a perfect patch but
good enough for now.
PR: kern/159418
Submitted by: Gleb Kurtsou
Reviewed by: kib
MFC after:1 month
Modified:
head/sys/fs/tmpfs/tmpfs_vnops.c
Modified: head/sys/fs/tmpfs/tmpfs_vnops.c
==
--- head/sys/fs/tmpfs/tmpfs_vnops.c Tue Nov 22 16:08:12 2011
(r227821)
+++ head/sys/fs/tmpfs/tmpfs_vnops.c Tue Nov 22 16:18:12 2011
(r227822)
@@ -965,11 +965,8 @@ tmpfs_rename(struct vop_rename_args *v)
/* If we need to move the directory between entries, lock the
* source so that we can safely operate on it. */
- if (tdvp != fdvp) {
- error = vn_lock(fdvp, LK_EXCLUSIVE | LK_RETRY);
- if (error != 0)
- goto out;
- }
+ if (fdvp != tdvp fdvp != tvp)
+ vn_lock(fdvp, LK_EXCLUSIVE | LK_RETRY);
fdnode = VP_TO_TMPFS_DIR(fdvp);
fnode = VP_TO_TMPFS_NODE(fvp);
de = tmpfs_dir_lookup(fdnode, fnode, fcnp);
@@ -1143,7 +1140,7 @@ tmpfs_rename(struct vop_rename_args *v)
error = 0;
out_locked:
- if (fdnode != tdnode)
+ if (fdvp != tdvp fdvp != tvp)
VOP_UNLOCK(fdvp, 0);
out:
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227310 - head/sys/fs/tmpfs
On 7 November 2011 17:21, Marcel Moolenaar mar...@freebsd.org wrote: Author: marcel Date: Mon Nov 7 16:21:50 2011 New Revision: 227310 URL: http://svn.freebsd.org/changeset/base/227310 Log: Don astbestos garment and remove the warning about TMPFS being experimental -- highly experimental even. So far the closest to a bug in TMPFS that people have gotten to relates to how ZFS can take away from the memory that TMPFS needs. One can argue that such is not a bug in TMPFS. Irrespective, even if there is a bug here and there in TMPFS, it's not in our own advantage to scare people away from using TMPFS. I for one have been using it, even with ZFS, very successfully. Thanks! It should be ok by now. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r226683 - head/usr.sbin/bsnmpd/modules/snmp_hostres
Author: ivoras Date: Mon Oct 24 12:21:58 2011 New Revision: 226683 URL: http://svn.freebsd.org/changeset/base/226683 Log: Fix typo MFC after:1 month Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c == --- head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct 24 10:48:13 2011(r226682) +++ head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct 24 12:21:58 2011(r226683) @@ -634,7 +634,7 @@ op_hrDiskStorageTable(struct snmp_contex value-v.integer = entry-media; return (SNMP_ERR_NOERROR); - case LEAF_hrDiskStorageRemoveble: + case LEAF_hrDiskStorageRemovable: value-v.integer = entry-removable; return (SNMP_ERR_NOERROR); Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def == --- head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def Mon Oct 24 10:48:13 2011(r226682) +++ head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_tree.def Mon Oct 24 12:21:58 2011(r226683) @@ -149,7 +149,7 @@ (1 hrDiskStorageEntry : INTEGER op_hrDiskStorageTable (1 hrDiskStorageAccess INTEGER GET) (2 hrDiskStorageMedia INTEGER GET) - (3 hrDiskStorageRemoveble INTEGER GET) + (3 hrDiskStorageRemovable INTEGER GET) (4 hrDiskStorageCapacity INTEGER GET) ) ) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r226684 - head/usr.sbin/bsnmpd/modules/snmp_hostres
Author: ivoras Date: Mon Oct 24 12:43:20 2011 New Revision: 226684 URL: http://svn.freebsd.org/changeset/base/226684 Log: It seems that the warning is much less severe than its message says. The device is certainly added to the list after the first pass. Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c == --- head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct 24 12:21:58 2011(r226683) +++ head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct 24 12:43:20 2011(r226684) @@ -442,7 +442,7 @@ disk_OS_get_disks(void) /* * not found there - insert it as immutable */ - syslog(LOG_WARNING, %s: device '%s' not in + syslog(LOG_WARNING, %s: adding device '%s' to device list, __func__, disk); if ((entry = device_entry_create(disk, , )) == NULL) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r226685 - head/usr.sbin/bsnmpd/modules/snmp_hostres
Author: ivoras
Date: Mon Oct 24 12:59:39 2011
New Revision: 226685
URL: http://svn.freebsd.org/changeset/base/226685
Log:
Apparently, ada drives are better treated similarly to da drives.
Modified:
head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c
Modified: head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c
==
--- head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct
24 12:43:20 2011(r226684)
+++ head/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c Mon Oct
24 12:59:39 2011(r226685)
@@ -476,7 +476,8 @@ disk_OS_get_disks(void)
disk_entry-media = DSM_UNKNOWN;
disk_entry-removable = SNMP_FALSE;
- if (strncmp(disk_entry-dev_name, da, 2) == 0) {
+ if (strncmp(disk_entry-dev_name, da, 2) == 0 ||
+ strncmp(disk_entry-dev_name, ada, 3) == 0) {
disk_entry-media = DSM_HARDDISK;
disk_entry-removable = SNMP_FALSE;
} else if (strncmp(disk_entry-dev_name, cd, 2) == 0) {
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r225954 - head/bin/mv
Author: ivoras
Date: Mon Oct 3 21:48:10 2011
New Revision: 225954
URL: http://svn.freebsd.org/changeset/base/225954
Log:
Don't chop IO into small pieces, follow cp(1) and just use MAXPHYS.
Modified:
head/bin/mv/mv.c
Modified: head/bin/mv/mv.c
==
--- head/bin/mv/mv.cMon Oct 3 21:19:15 2011(r225953)
+++ head/bin/mv/mv.cMon Oct 3 21:48:10 2011(r225954)
@@ -260,40 +260,34 @@ static int
fastcopy(const char *from, const char *to, struct stat *sbp)
{
struct timeval tval[2];
- static u_int blen;
- static char *bp;
+ static u_int blen = MAXPHYS;
+ static char *bp = NULL;
mode_t oldmode;
int nread, from_fd, to_fd;
if ((from_fd = open(from, O_RDONLY, 0)) 0) {
- warn(%s, from);
+ warn(fastcopy: open() failed (from): %s, from);
return (1);
}
- if (blen sbp-st_blksize) {
- if (bp != NULL)
- free(bp);
- if ((bp = malloc((size_t)sbp-st_blksize)) == NULL) {
- blen = 0;
- warnx(malloc failed);
- return (1);
- }
- blen = sbp-st_blksize;
+ if (bp == NULL (bp = malloc((size_t)blen)) == NULL) {
+ warnx(malloc(%u) failed, blen);
+ return (1);
}
while ((to_fd =
open(to, O_CREAT | O_EXCL | O_TRUNC | O_WRONLY, 0)) 0) {
if (errno == EEXIST unlink(to) == 0)
continue;
- warn(%s, to);
+ warn(fastcopy: open() failed (to): %s, to);
(void)close(from_fd);
return (1);
}
while ((nread = read(from_fd, bp, (size_t)blen)) 0)
if (write(to_fd, bp, (size_t)nread) != nread) {
- warn(%s, to);
+ warn(fastcopy: write() failed: %s, to);
goto err;
}
if (nread 0) {
- warn(%s, from);
+ warn(fastcopy: read() failed: %s, from);
err: if (unlink(to))
warn(%s: remove, to);
(void)close(from_fd);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r223955 - head/share/man/man8
Author: ivoras Date: Tue Jul 12 14:18:54 2011 New Revision: 223955 URL: http://svn.freebsd.org/changeset/base/223955 Log: Sort Xr's by number then by name Nitpicked by: niclas zeising at gmail.com :) Modified: head/share/man/man8/picobsd.8 Modified: head/share/man/man8/picobsd.8 == --- head/share/man/man8/picobsd.8 Tue Jul 12 14:04:36 2011 (r223954) +++ head/share/man/man8/picobsd.8 Tue Jul 12 14:18:54 2011 (r223955) @@ -647,8 +647,8 @@ already exists on disk (e.g.\ as a resu .Sh SEE ALSO .Xr crunchgen 1 , .Xr mdconfig 8 , -.Xr swapon 8 , -.Xr nanobsd 8 +.Xr nanobsd 8 , +.Xr swapon 8 .Sh AUTHORS .An -nosplit .An Andrzej Bialecki Aq ab...@freebsd.org , ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r223912 - head/share/man/man8
Author: ivoras Date: Sun Jul 10 20:15:21 2011 New Revision: 223912 URL: http://svn.freebsd.org/changeset/base/223912 Log: Cross reference nanobsd(8) Modified: head/share/man/man8/picobsd.8 Modified: head/share/man/man8/picobsd.8 == --- head/share/man/man8/picobsd.8 Sun Jul 10 18:57:35 2011 (r223911) +++ head/share/man/man8/picobsd.8 Sun Jul 10 20:15:21 2011 (r223912) @@ -647,7 +647,8 @@ already exists on disk (e.g.\ as a resu .Sh SEE ALSO .Xr crunchgen 1 , .Xr mdconfig 8 , -.Xr swapon 8 +.Xr swapon 8 , +.Xr nanobsd 8 .Sh AUTHORS .An -nosplit .An Andrzej Bialecki Aq ab...@freebsd.org , ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r220584 - in head/sys: amd64/amd64 i386/i386
On 14 April 2011 00:27, Jung-uk Kim j...@freebsd.org wrote: That means your VM has broken CPUID support. To get there, it has to meet two conditions, i.e., TSC is invariant and it has APERF/MPERF MSRs. A simple workaround is setting machdep.disable_tsc=1 tuanable from loader but your VM is the real culprit here. You are probably right but fixing VMs is not going to happen (or not soon enough) so workarounds must be implemented. I don't know if it is called early enough for this purpose, but detect_virtual() in kern/subr_param.c initializes the vm_guest variable which could be useful for such workarounds (also see how vm_guest is used in init_param1() in the same file to scale down HZ). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r219699 - head/sys/kern
Author: ivoras Date: Wed Mar 16 16:22:59 2011 New Revision: 219699 URL: http://svn.freebsd.org/changeset/base/219699 Log: The hardware has caught up; improvements are now observed even at 128, but stay conservative and bump read_max to only 64 (it will probably be a good idea to increase this to 128 after the next major release). Modified: head/sys/kern/vfs_cluster.c Modified: head/sys/kern/vfs_cluster.c == --- head/sys/kern/vfs_cluster.c Wed Mar 16 16:09:08 2011(r219698) +++ head/sys/kern/vfs_cluster.c Wed Mar 16 16:22:59 2011(r219699) @@ -71,7 +71,7 @@ static int write_behind = 1; SYSCTL_INT(_vfs, OID_AUTO, write_behind, CTLFLAG_RW, write_behind, 0, Cluster write-behind; 0: disable, 1: enable, 2: backed off); -static int read_max = 32; +static int read_max = 64; SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, read_max, 0, Cluster read-ahead max block count); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 18:46, Roman Divacky rdiva...@freebsd.org wrote: On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: Author: ivoras Date: Wed Mar 16 16:22:59 2011 New Revision: 219699 URL: http://svn.freebsd.org/changeset/base/219699 Log: The hardware has caught up; improvements are now observed even at 128, but stay conservative and bump read_max to only 64 (it will probably be a good idea to increase this to 128 after the next major release). how did you measure this? Specifically for this commit: my desktop 2xSATA 7200 RPM drives, gmirror, single read dd stream, bs=1m. (Are there any ready read multi-stream read tests which are not trivial i.e. they start from different positions in the file?) results: read_max=32 - 78 MB/s read_max=64 - 136 MB/s read_max=128 - 141 MB/s I'm the one who previously bumped read_max from 8 to 32 about a year ago, based on tests under an (otherwise idle, naturally) VMWare cluster on a FC SAN, and a similar point of saturation was at read_max=64. Now it is at 128 with raw hardware. Maybe it should be tuned at 2^(major_freebsd_version-2) :) (as for safety stability, I've put 2-3 new web servers in production this year with read_max=128 irregardless of this commit. It's stable). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 20:59, Garrett Cooper gcoo...@freebsd.org wrote: On Wed, Mar 16, 2011 at 12:51 PM, Ivan Voras ivo...@freebsd.org wrote: On 16 March 2011 18:46, Roman Divacky rdiva...@freebsd.org wrote: On Wed, Mar 16, 2011 at 04:22:59PM +, Ivan Voras wrote: Author: ivoras Date: Wed Mar 16 16:22:59 2011 New Revision: 219699 URL: http://svn.freebsd.org/changeset/base/219699 Log: The hardware has caught up; improvements are now observed even at 128, but stay conservative and bump read_max to only 64 (it will probably be a good idea to increase this to 128 after the next major release). how did you measure this? Specifically for this commit: my desktop 2xSATA 7200 RPM drives, gmirror, single read dd stream, bs=1m. (Are there any ready read multi-stream read tests which are not trivial i.e. they start from different positions in the file?) Would be interesting to see how well things work with the new geom_raid bits and with other drives (SAS, SCSI). Yes, I'd be interested in that; I'll try it when I get the chance to test new hardware. For now, there's a report (which actually inspired me to retest and commit this) from someone who tried this on 2x 15k RPM SAS drives, with much better results using read_max=128 (thread gmirror performance on freebsd-fs@). I estimate that because his drives were 15kRPM from the start, the improvement isn't as drastic going from 8 to 128 as on these SATA drives I tested on (faster seeks). He went from ~~ 195 MB/s to ~~ 258 MB/s while I go from ~~ 50 MB/s to ~~ 140 MB/s. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219699 - head/sys/kern
On 16 March 2011 21:37, Ivan Voras ivo...@freebsd.org wrote: For now, there's a report (which actually inspired me to retest and commit this) from someone who tried this on 2x 15k RPM SAS drives, with much better results using read_max=128 (thread gmirror performance on freebsd-fs@). I estimate that because his drives were 15kRPM from the start, the improvement isn't as drastic going from 8 to 128 as on these SATA drives I tested on (faster seeks). He went from ~~ 195 MB/s to ~~ 258 MB/s while I go from ~~ 50 MB/s to ~~ 140 MB/s. Btw I also tested that random IO isn't affected by this: it isn't. The read-ahead heuristics is working. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219679 - head/sys/i386/include
On 16 March 2011 21:03, Erik Trulsson ertr1...@student.uu.se wrote: On Wed, Mar 16, 2011 at 06:45:53PM +0100, Roman Divacky wrote: On Wed, Mar 16, 2011 at 12:32:56PM -0400, Jung-uk Kim wrote: On Tuesday 15 March 2011 08:45 pm, Maxim Dounin wrote: This isn't really different as long as GENERIC kernel used, as GENERIC defines I486_CPU. Fixed in r219698, sorry. Actually, I think we should remove i486 from GENERIC at some point. It has too many limitations. For example, I really love to implement atomic 64-bit mem read/write using cmpxchg8b (no 0xf00f joke, please) but I cannot do that cleanly without removing I486 support or checking cpu_class at run-time. :-( if we drop i486 I think it makes sense to require something that has at least SSE2, thus we can have the same expectations as on amd64. No, that would remove support from far too many machines that people actually use to run FreeBSD. There are probably only a handful of people (if that) who actually run FreeBSD on an actual 486-class machine, but requiring SSE2 would mean dropping support for Pentium-III and Athlon-XP equipped machines and I believe there are a large number of such machines still in use, and they are still perfectly suitable for a large number of tasks. This is understandable but I also think it deserves a poll at stable@ and current@. It might be worth keeping i486 for all of 9-stable but removing it before 10-stable. Judging from previous releases, 9.x would be supported until at least 2016. I don't follow the embedded world that much, but from what I saw, most (incl. Soekris) are moving to Atom designs which support SSE2. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219708 - head/usr.bin/vmstat
On 17 March 2011 02:05, Ed Maste ema...@freebsd.org wrote: Author: emaste Date: Thu Mar 17 01:05:54 2011 New Revision: 219708 URL: http://svn.freebsd.org/changeset/base/219708 Log: Remove uptime validity check that hasn't been necessary since r151417 switched to clock_gettime. vmstat will now not exit with an error if run on a system with 10 years of uptime. I hope you have a system to test this on :) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r218603 - head/sbin/tunefs
On 13 February 2011 11:51, Bruce Evans b...@optusnet.com.au wrote: On Sat, 12 Feb 2011, Konstantin Belousov wrote: Log: When creating a directory entry for the journal, always read at least the fragment, and write the full block. Reading less might not work due to device sector size bigger then size of direntries in the last directory fragment. I think it should always write full fragments too (and the kernel should always read/write in units of fragments, not sectors of any size). Or at least One Single Variable, preferably recorded in the superblock, so when the need arises there's only one thing to change (so it might as well be fragment size in case of UFS). There is currently nothing technically wrong with what this commit does, but it's pretty much a certainty that future will be more strange than today and future developers may forget there are two places they need to change. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r217780 - head/sbin/geom/class/virstor
Author: ivoras Date: Mon Jan 24 14:24:10 2011 New Revision: 217780 URL: http://svn.freebsd.org/changeset/base/217780 Log: Added a blurb about thin provisioning, fixed some formatting. Modified: head/sbin/geom/class/virstor/gvirstor.8 Modified: head/sbin/geom/class/virstor/gvirstor.8 == --- head/sbin/geom/class/virstor/gvirstor.8 Mon Jan 24 14:01:30 2011 (r217779) +++ head/sbin/geom/class/virstor/gvirstor.8 Mon Jan 24 14:24:10 2011 (r217780) @@ -1,4 +1,4 @@ -.\ Copyright (c) 2006-2008 Ivan Voras ivo...@freebsd.org +.\ Copyright (c) 2006-2011 Ivan Voras ivo...@freebsd.org .\ All rights reserved. .\ .\ Redistribution and use in source and binary forms, with or without @@ -24,7 +24,7 @@ .\ .\ $FreeBSD$ .\ -.Dd December 17, 2008 +.Dd January 24, 2011 .Dt GVIRSTOR 8 .Os .Sh NAME @@ -80,6 +80,10 @@ The idea behind is similar to the concept of Virtual Memory in operating systems, effectively allowing users to overcommit on storage .Pq free file system space . +The concept is also known as thin provisioning in virtualization +environments, only here it is implemented on the level of physical storage +devices. +.Pp The first argument to .Nm indicates an action to be performed: ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r217033 - in head: lib/libstand sys/boot/ficl sys/boot/i386 sys/boot/pc98 sys/boot/zfs sys/conf
On 5 January 2011 23:24, Dimitry Andric d...@freebsd.org wrote:
Author: dim
Date: Wed Jan 5 22:24:33 2011
New Revision: 217033
URL: http://svn.freebsd.org/changeset/base/217033
Log:
On i386 and amd64, consistently use the following options whenever we
want to avoid using any advanced CPU features:
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
I'm late to the party - but is there any hope of centralizing these
and then doing something like CFLAGS += ${CC_NO_FP} ? As soon as we
get a newer compiler someone will have to add -mno-sse4 to the list
(if not already with clang...).
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 7 December 2010 11:21, Pawel Jakub Dawidek p...@freebsd.org wrote: PS. Do you know your change breaks all current ZFS installation if stripesize is defined for a provider? # zpool create tank ada0 (upgrade FreeBSD so that ada0 now reports 4kB stripesize) # zpool import tank cannot import 'tank': invalid vdev configuration Actually I did test the patch and, similar to the Solaris people, found that ZFS records ashift in metadata and uses the recorded one instead of hardcoded / detected one. What you found here really shouldn't happen. Are you sure only stripesize was increased in your case, not sectorsize? So you change was not only poorly thought out and not reviewed, but also not even minimally tested. Before we go any further, back it out. This actually is the first problem that requires backing it out. I will do it. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r216256 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: ivoras Date: Tue Dec 7 15:24:08 2010 New Revision: 216256 URL: http://svn.freebsd.org/changeset/base/216256 Log: Undo r216230: the interaction between saved ashift in metadata and detected ashift does not support this. With this change, pools created while stripesize=512 could not be imported when stripesize becomes larger (on the same drive). Noticed by: pjd Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Dec 7 12:44:33 2010(r216255) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Dec 7 15:24:08 2010(r216256) @@ -496,10 +496,7 @@ vdev_geom_open(vdev_t *vd, uint64_t *psi /* * Determine the device's minimum transfer size. */ - if (pp-stripesize pp-sectorsize) - *ashift = highbit(MIN(pp-stripesize, SPA_MAXBLOCKSIZE)) - 1; - else - *ashift = highbit(MAX(pp-sectorsize, SPA_MINBLOCKSIZE)) - 1; + *ashift = highbit(MAX(pp-sectorsize, SPA_MINBLOCKSIZE)) - 1; /* * Clear the nowritecache bit, so that on a vdev_reopen() we will ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 7 December 2010 12:31, Pawel Jakub Dawidek p...@freebsd.org wrote: On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote: On 7 December 2010 11:21, Pawel Jakub Dawidek p...@freebsd.org wrote: PS. Do you know your change breaks all current ZFS installation if stripesize is defined for a provider? # zpool create tank ada0 (upgrade FreeBSD so that ada0 now reports 4kB stripesize) # zpool import tank cannot import 'tank': invalid vdev configuration Actually I did test the patch and, similar to the Solaris people, found that ZFS records ashift in metadata and uses the recorded one instead of hardcoded / detected one. What you found here really shouldn't happen. Are you sure only stripesize was increased in your case, not sectorsize? if (pp-stripesize pp-sectorsize) *ashift = highbit(MIN(pp-stripesize, SPA_MAXBLOCKSIZE)) - 1; else *ashift = highbit(MAX(pp-sectorsize, SPA_MINBLOCKSIZE)) - 1; If stripesize will start to be 4096, the ashift will change. Not sure what you test was, but it only works the other way around - create pool with 4kB ashift and import it when ashift is 512 bytes. My test was flawed, it made me conclude that ashift from metadata would be used in this case (this case is actually one of the more trivial ones - vdev created with ashift=9 used on device which is capable of ashift=9 but advertises ashift=12). In case it would be useful in the future, this is blocked in vdev_open(): http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c#L1075 I think that to solve this edge case properly, ZFS would have to know that both ashift values are valid for the device, i.e. basically it would at this point need to somehow know about our sectorsize and stripesize, not just ashift. OpenSolaris lists mention that pools can be created from devices with different ashift values, which is good news. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 6 December 2010 19:44, Pawel Jakub Dawidek p...@freebsd.org wrote: On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote: Author: ivoras Date: Mon Dec 6 12:18:02 2010 New Revision: 216230 URL: http://svn.freebsd.org/changeset/base/216230 Log: Use GEOM stripesize field when calculating ashift. This will enable correct alignment on drives with large sector sizes (e.g. 4 KiB) but the implementation might need to be revisited if devices with large stripesizes appear (e.g. if RAID controllers or flash drives start using the field), probably by introducing a physsectorsize field in GEOM providers. Please back this out as soon as possible! Given information such as this: http://www.solarismen.de/archives/5-Solaris-and-the-new-4K-Sector-Disks-e.g.-WDxxEARS-Part-2.html http://article.gmane.org/gmane.os.solaris.opensolaris.zfs/43986 and my last message on the subject in the thread: http://permalink.gmane.org/gmane.os.freebsd.devel.geom/4376 Can you explain why is it wrong, and what can go wrong with changing ashift in this way? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 6 December 2010 20:22, Pawel Jakub Dawidek p...@freebsd.org wrote: On Mon, Dec 06, 2010 at 07:44:53PM +0100, Pawel Jakub Dawidek wrote: On Mon, Dec 06, 2010 at 12:18:03PM +, Ivan Voras wrote: Author: ivoras Date: Mon Dec 6 12:18:02 2010 New Revision: 216230 URL: http://svn.freebsd.org/changeset/base/216230 Log: Use GEOM stripesize field when calculating ashift. This will enable correct alignment on drives with large sector sizes (e.g. 4 KiB) but the implementation might need to be revisited if devices with large stripesizes appear (e.g. if RAID controllers or flash drives start using the field), probably by introducing a physsectorsize field in GEOM providers. Please back this out as soon as possible! Discussed with: mav, mostly silence on freebsd-geom@ and freebsd-fs@ Guess why it wasn't picked up by anyone? In other words... Stop hack around. This is so irritating. If disk lies about its sector size, add quirks at the layer where disk is discovered. Don't hack ZFS, UFS, any other file system and GEOM classes, because its easiest for you. It would be best if you could just leave it to mav@ who knows this area and knows what he is doing. Those drive-by hacks of yours are really doing more evil than good. I regard your personal opinion on this topic in little regard, as you have too much of it. Please persuade me on technical grounds why ashift, a property intended for address alignment, should not be set in this way. If your answer is I don't know but you are still wrong because I say so I will respect it and back it out but only until I/we discuss the question with upstream ZFS developers. From my POW, this is similar to changing UFS default fragment size to match stripesize, which is a patch I also intend to commit (after a review by mckusick, or course). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Firstly, thank you, your explanations and questions are very good and address the problems in a good way to discuss about it. I respect that you took the time to write this answer! On 6 December 2010 20:53, Pawel Jakub Dawidek p...@freebsd.org wrote: On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: Please persuade me on technical grounds why ashift, a property intended for address alignment, should not be set in this way. If your answer is I don't know but you are still wrong because I say so I will respect it and back it out but only until I/we discuss the question with upstream ZFS developers. No. You persuade me why changing ashift in ZFS, which, as the comment clearly states is device's minimum transfer size is better and not hackish than presenting the disk with properly configured sector size. You are right, it was, at least originally, defined as the device's minimum transfer size, and it is in this context hackish to change it to something that isn't it. But there are two reasons that I think are important, which resulted in changing this: 1) It is being used out of the original context in the mailing list posts I've referenced - it was being used (and in a worse way, by having a hacked zpool binary) for alignment like I did in the patch, despite that the sectorsize wasn't changed. 2) The solaris big sector project, described in http://arc.opensolaris.org/caselog/PSARC/2008/769/final_spec.txt basically blesses ZFS to work with big sectors, and states ZFS can automatically run on larger sector size disk after the label change and I/O path change. Since the effect of having a larger sectorsize will effectively be only the change in ashift, this is what I've done. I would of course also be happy with simply having drives with sectorsize=4096, but I've given up on this route because of two reasons: mav was essentially against it since it will break compatibility if suddenly changed and the posts on opensolaris mailing lists are basically saying that it is likely that the 512/4096 kludge will remain forever and it's unlikely to change. This can not only affect disks that still use 512 bytes sectors, but doesn't fix the problem at all. It just works around the problem in ZFS when configured on top of raw disks. I'm not sure how to parse can not only affect disks that still use 512 byte sectors - if you are saying that it can affect disks with 512 byte sectors, I can think of only one case when it can have a serious effect: if the drive (or GEOM) suddenly use 4 KiB sectorsize on a drive which was previously formatted with ZFS as a drive with 512 byte sectors. All other combinations work because ashift is a part of ZFS metadata - this calculation is overriden in case e.g. a zvol created with ashift=12 is imported on a kernel/OS which only sees 512 byte sectors. What about other file systems? What about other GEOM classes? GELI is great example here, as people use ZFS on top of GELI alot. GELI integrity verification works in a way that not reporting disk sector size properly will have huge negative performance impact. ZFS' ashift won't change that. Does this mean that, despite that ZFS is correctly aligned, GELI can break this alignment policy so still, at the end, produce wrong alignments for IOs? If so, I understand your concern, but it looks like a problem with GELI, not ZFS. The same problem will occur if any other file system type is created which is properly aligned from the POW of the administrator. So you should back this change out, provide technical arguments (if they exist) that this is the right solution to the problem and not hey, here is a patch, I think it is ok. Thank you, I will try to remember to give more details in commits. BTW. ZFS is no longer open-source if you didn't notice. I have noticed but I don't understand how it affects FreeBSD. I would like to discuss this sometime but unless you have some urgent interpretation of this information, I think it's best to start another thread about it. I think that, basically, the whole argument boils down to the question like while ZFS will most likely implement big sector support in this way, it doesn't right now, so should we do it ourselves? I hope that this information I've written helps explain why I did the patch. If you are still against it, I will back it out. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 6 December 2010 21:18, John Baldwin j...@freebsd.org wrote: On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: Please persuade me on technical grounds why ashift, a property intended for address alignment, should not be set in this way. If your answer is I don't know but you are still wrong because I say so I will respect it and back it out but only until I/we discuss the question with upstream ZFS developers. No. You persuade me why changing ashift in ZFS, which, as the comment clearly states is device's minimum transfer size is better and not hackish than presenting the disk with properly configured sector size. This can not only affect disks that still use 512 bytes sectors, but doesn't fix the problem at all. It just works around the problem in ZFS when configured on top of raw disks. What about other file systems? What about other GEOM classes? GELI is great example here, as people use ZFS on top of GELI alot. GELI integrity verification works in a way that not reporting disk sector size properly will have huge negative performance impact. ZFS' ashift won't change that. I am mostly on your side here, but I wonder if GELI shouldn't prefer the stripesize anyway? For example, if you ran GELI on top of RAID-5 I imagine it would be far more performant for it to use stripe-size logical blocks instead of individual sectors for the underlying media. The RAID-5 argument also suggests that other filesystems should probably prefer stripe sizes to physical sector sizes when picking block sizes, etc. For what it's worth, apparently linux has the concept of physical and logical sector sizes (possibly in addition to stripe size), with physical being 4096 and logical 512, for example: # hdparm -I /dev/sde | grep size Logical Sector size: 512 bytes Physical Sector size: 4096 bytes device size with M = 1024*1024: 1430799 MBytes device size with M = 1000*1000: 1500301 MBytes (1500 GB) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
On 6 December 2010 22:16, Bruce Cran br...@cran.org.uk wrote: On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote: For what it's worth, apparently linux has the concept of physical and logical sector sizes (possibly in addition to stripe size), with physical being 4096 and logical 512, for example: # hdparm -I /dev/sde | grep size Logical Sector size: 512 bytes Physical Sector size: 4096 bytes device size with M = 1024*1024: 1430799 MBytes device size with M = 1000*1000: 1500301 MBytes (1500 GB) So do we, except they're both the same for Advanced Format drives: There is a subtle difference here which may be important. We have the concepts of sectorsize and stripesize. I think camcontrol actually reports logical and physical sector sizes as reported by low-level drivers but currently GEOM names logical sector size as sectorsize and physical sector size as stripesize. The term stripesize can be overloaded to mean both the item in question - 4 KiB physical sector sizes and RAID stripe sizes. I think this situation is bad and that the two meanings should be split. # camcontrol identify /dev/ada1 ... device model WDC WD10EARS-00Z5B1 ... sector size logical 512, physical 512, offset 0 Agreed. Some drives lie. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r216134 - in head: share/man/man9 sys/amd64/include sys/arm/include sys/i386/include sys/ia64/include sys/mips/include sys/pc98/include sys/powerpc/include sys/sparc64/include sys/sun4
On 3 December 2010 13:46, John Baldwin j...@freebsd.org wrote: On Friday, December 03, 2010 5:16:51 am Bruce Cran wrote: On Fri, 3 Dec 2010 20:45:12 +1100 (EST) Bruce Evans b...@optusnet.com.au wrote: KASSERT() in little inline functions gives a lot of bloat for such an unlikely error. Stupid callers can still pass any garbage count except 0. Yes, this catches a specific case that hps raised a few years ago: sending zero-length packets/frames would fail by causing the system to hang. Should we just document the restriction in the man page and not try and prevent it at runtime? Documenting it is probably sufficient. I'd say it depends on if the specific case that hps raised a few years ago sentence part refers to an actual problem; i.e. did it happen in practice? If yes, leaving KASSERTs looks like the best option. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r215425 - head/usr.sbin/iostat
Author: ivoras Date: Wed Nov 17 15:12:10 2010 New Revision: 215425 URL: http://svn.freebsd.org/changeset/base/215425 Log: Change wait banner to qlen to be more indicative of its purpose and to be more inline with what gstat uses. Reviewed by: gnn Silence from: phk, keramida Modified: head/usr.sbin/iostat/iostat.8 head/usr.sbin/iostat/iostat.c Modified: head/usr.sbin/iostat/iostat.8 == --- head/usr.sbin/iostat/iostat.8 Wed Nov 17 13:52:09 2010 (r215424) +++ head/usr.sbin/iostat/iostat.8 Wed Nov 17 15:12:10 2010 (r215425) @@ -348,7 +348,7 @@ write operations per second kilobytes read per second .It kw/s kilobytes write per second -.It wait +.It qlen transactions queue length .It svc_t average duration of transactions, in milliseconds Modified: head/usr.sbin/iostat/iostat.c == --- head/usr.sbin/iostat/iostat.c Wed Nov 17 13:52:09 2010 (r215424) +++ head/usr.sbin/iostat/iostat.c Wed Nov 17 15:12:10 2010 (r215425) @@ -750,11 +750,11 @@ devstats(int perf_select, long double et printf(\n); if (Iflag == 0) printf( - device r/s w/skr/skw/s wait svc_t %%b + device r/s w/skr/skw/s qlen svc_t %%b ); else printf( - device r/i w/ikr/ikw/i wait svc_t %%b + device r/i w/ikr/ikw/i qlen svc_t %%b ); if (Tflag 0) printf(tin tout ); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r215178 - in head: lib/libc/sys sys/kern sys/sys
On 16 November 2010 02:48, Luigi Rizzo ri...@iet.unipi.it wrote: On Tue, Nov 16, 2010 at 01:33:53AM +0100, Ivan Voras wrote: On 15 November 2010 18:10, Luigi Rizzo ri...@iet.unipi.it wrote: 2. [generic] passing pointers between userland and kernel requires remapping the pointer when going up or down. As the mapping would be application specific, i don't see much use in allowing room for a pointer without kernel code to map userland - kernel pointers. I'm not thinking of passing a *working* pointer into the kernel but used as a cookie, similar to how it's used in kqueue: the intention being the application can send and get a pointer which means something to the application, not something usable to the kernel. oh, but then you are thinking of something completely different. The SO_USER_COOKIE is never returned to the application; it is only passed to another kernel subsystem, so it must be significant there, not for the application. Ah, ok then. I was thinking you are maybe trying to do something else, like tagging a socket with additional information from userland. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r214359 - head/sys/ufs/ufs
Author: ivoras
Date: Mon Oct 25 21:46:23 2010
New Revision: 214359
URL: http://svn.freebsd.org/changeset/base/214359
Log:
Bring vfs.ufs.dirhash_maxmem into the age of the fruitbat and make it
autotuned. It is only an upper bound (the memory is not always allocated)
and the system contains a vm_lowmem handler so nothing will crash and burn
if it's tuned too high.
Reviewed by: mckusick
Modified:
head/sys/ufs/ufs/ufs_dirhash.c
Modified: head/sys/ufs/ufs/ufs_dirhash.c
==
--- head/sys/ufs/ufs/ufs_dirhash.c Mon Oct 25 20:52:33 2010
(r214358)
+++ head/sys/ufs/ufs/ufs_dirhash.c Mon Oct 25 21:46:23 2010
(r214359)
@@ -72,7 +72,8 @@ static int ufs_mindirhashsize = DIRBLKSI
SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_minsize, CTLFLAG_RW,
ufs_mindirhashsize,
0, minimum directory size in bytes for which to use hashed lookup);
-static int ufs_dirhashmaxmem = 2 * 1024 * 1024;
+static int ufs_dirhashmaxmem = 2 * 1024 * 1024;/* NOTE: initial value.
It is
+ tuned in ufsdirhash_init() */
SYSCTL_INT(_vfs_ufs, OID_AUTO, dirhash_maxmem, CTLFLAG_RW, ufs_dirhashmaxmem,
0, maximum allowed dirhash memory usage);
static int ufs_dirhashmem;
@@ -1290,6 +1291,9 @@ ufsdirhash_lowmem()
void
ufsdirhash_init()
{
+ ufs_dirhashmaxmem = lmax(roundup(hibufspace / 64, PAGE_SIZE),
+ 2 * 1024 * 1024);
+
ufsdirhash_zone = uma_zcreate(DIRHASH, DH_NBLKOFF * sizeof(doff_t),
NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0);
mtx_init(ufsdirhash_mtx, dirhash list, NULL, MTX_DEF);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213662 - in head: sbin/geom/class/concat sbin/geom/class/eli sbin/geom/class/journal sbin/geom/class/mirror sbin/geom/class/part sbin/geom/class/raid3 sbin/geom/class/shsec sbin/geom/
On 10 October 2010 10:54, Ivan Voras ivo...@freebsd.org wrote: On 9 October 2010 22:20, Andrey V. Elsukov a...@freebsd.org wrote: Author: ae Date: Sat Oct 9 20:20:27 2010 New Revision: 213662 URL: http://svn.freebsd.org/changeset/base/213662 Log: Replace strlen(_PATH_DEV) with sizeof(_PATH_DEV) - 1. Um, this looks like a pointless change and for the worse; Even at -O1 the compiler will reduce strlen(constant) to just its result and for code like printf(%d\n, sizeof(1234567)) produce code like: ^ should be strlen(), of course :) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213662 - in head: sbin/geom/class/concat sbin/geom/class/eli sbin/geom/class/journal sbin/geom/class/mirror sbin/geom/class/part sbin/geom/class/raid3 sbin/geom/class/shsec sbin/geom/
On 9 October 2010 22:20, Andrey V. Elsukov a...@freebsd.org wrote: Author: ae Date: Sat Oct 9 20:20:27 2010 New Revision: 213662 URL: http://svn.freebsd.org/changeset/base/213662 Log: Replace strlen(_PATH_DEV) with sizeof(_PATH_DEV) - 1. Um, this looks like a pointless change and for the worse; Even at -O1 the compiler will reduce strlen(constant) to just its result and for code like printf(%d\n, sizeof(1234567)) produce code like: movl$7, %esi movl$.LC0, %edi movl$0, %eax callprintf And (though tastes differ) I think the sizeof() variant is less readable. The strlen(_PATH_something) idiom is common in other parts of the kernel outside GEOM. In short - why was this done? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213398 - head/bin/rm
On 4 October 2010 13:42, Alexander Best arun...@freebsd.org wrote: good point. ZFS should really be added to the list and LFS should go away. are there any other relevant filesystems without a fixed-block size that need to be mentioned? what about afs? or tmpfs? (it's not that the block sizes aren't fixed, it's that the assignment of blocks to the file is not fixed). ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r212496 - head/sys/modules/crypto
Author: ivoras Date: Sun Sep 12 16:28:26 2010 New Revision: 212496 URL: http://svn.freebsd.org/changeset/base/212496 Log: List low-level Blowfish ECB module in the SRCS. It looks like it was dropped by accident (and it would be inconvenient to implement it otherwise because it uses internal non-published headers). MFC after:1 week Modified: head/sys/modules/crypto/Makefile Modified: head/sys/modules/crypto/Makefile == --- head/sys/modules/crypto/MakefileSun Sep 12 15:59:14 2010 (r212495) +++ head/sys/modules/crypto/MakefileSun Sep 12 16:28:26 2010 (r212496) @@ -12,7 +12,7 @@ KMOD = crypto SRCS = crypto.c cryptodev_if.c SRCS += criov.c cryptosoft.c xform.c SRCS += cast.c deflate.c rmd160.c rijndael-alg-fst.c rijndael-api.c -SRCS += skipjack.c bf_enc.c bf_skey.c +SRCS += skipjack.c bf_enc.c bf_ecb.c bf_skey.c SRCS += des_ecb.c des_enc.c des_setkey.c SRCS += sha1.c sha2.c SRCS += opt_param.h cryptodev_if.h bus_if.h device_if.h ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r211123 - head/sys/kern
Author: ivoras Date: Mon Aug 9 22:22:46 2010 New Revision: 211123 URL: http://svn.freebsd.org/changeset/base/211123 Log: Elaborate on how hirunningspace was chosen. Modified: head/sys/kern/vfs_bio.c Modified: head/sys/kern/vfs_bio.c == --- head/sys/kern/vfs_bio.c Mon Aug 9 22:22:06 2010(r211122) +++ head/sys/kern/vfs_bio.c Mon Aug 9 22:22:46 2010(r211123) @@ -622,8 +622,11 @@ bufinit(void) /* * Note: The 16 MB upper limit for hirunningspace was chosen -* arbitrarily and may need further tuning. The lower 1 MB -* limit is the historical upper limit for hirunningspace. +* arbitrarily and may need further tuning. It corresponds to +* 128 outstanding write IO requests (if IO size is 128 KiB), +* which fits with many RAID controllers' tagged queing limits. +* The lower 1 MB limit is the historical upper limit for +* hirunningspace. */ hirunningspace = lmax(lmin(roundup(hibufspace / 64, MAXBSIZE), 16 * 1024 * 1024), 1024 * 1024); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r211126 - head/sys/kern
Author: ivoras Date: Mon Aug 9 22:56:10 2010 New Revision: 211126 URL: http://svn.freebsd.org/changeset/base/211126 Log: Bumping the read-ahead count once more, to value equivalent to 512 KiB on most system, based on benchmark results on a low-end fibre channel SAN under VMWare: vfs.read_max read performance 8 (historical default) 83 MB/s 16 (recent bump) 131 MB/s 32 (this version) 152 MB/s 64157 MB/s (results are +/- 3 MB/s) As read-ahead is heuristic, based on past IO requests, it shouldn't be problematic. The new default is still smaller then in other OSes. Modified: head/sys/kern/vfs_cluster.c Modified: head/sys/kern/vfs_cluster.c == --- head/sys/kern/vfs_cluster.c Mon Aug 9 22:30:14 2010(r211125) +++ head/sys/kern/vfs_cluster.c Mon Aug 9 22:56:10 2010(r211126) @@ -71,7 +71,7 @@ static int write_behind = 1; SYSCTL_INT(_vfs, OID_AUTO, write_behind, CTLFLAG_RW, write_behind, 0, Cluster write-behind; 0: disable, 1: enable, 2: backed off); -static int read_max = 16; +static int read_max = 32; SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, read_max, 0, Cluster read-ahead max block count); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r211129 - head/sys/kern
Author: ivoras Date: Mon Aug 9 23:32:37 2010 New Revision: 211129 URL: http://svn.freebsd.org/changeset/base/211129 Log: Fix (hopefully) the spelling of queuing. Submitted by: bf1783 at gmail com Modified: head/sys/kern/vfs_bio.c Modified: head/sys/kern/vfs_bio.c == --- head/sys/kern/vfs_bio.c Mon Aug 9 23:29:37 2010(r211128) +++ head/sys/kern/vfs_bio.c Mon Aug 9 23:32:37 2010(r211129) @@ -624,7 +624,7 @@ bufinit(void) * Note: The 16 MB upper limit for hirunningspace was chosen * arbitrarily and may need further tuning. It corresponds to * 128 outstanding write IO requests (if IO size is 128 KiB), -* which fits with many RAID controllers' tagged queing limits. +* which fits with many RAID controllers' tagged queuing limits. * The lower 1 MB limit is the historical upper limit for * hirunningspace. */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r211031 - head/sys/kern
Author: ivoras Date: Sat Aug 7 18:30:10 2010 New Revision: 211031 URL: http://svn.freebsd.org/changeset/base/211031 Log: To help with sequential read UFS performance on modern systems, increase the vfs.read_max default. For most systems this means going from 128 KiB to 256 KiB, which is still very conservative and lower than what most other operating systems use, but as a sane default should not interfere much with existing systems. For systems with RAID volumes and/or virtualization envirnments, where read performance is very important, increasing this sysctl tunable to 32 or even more will demonstratively yield additional performance benefits. If MAXPHYS ever gets bumped up, it will probably be a good idea to slave read_max to it. Modified: head/sys/kern/vfs_cluster.c Modified: head/sys/kern/vfs_cluster.c == --- head/sys/kern/vfs_cluster.c Sat Aug 7 17:57:58 2010(r211030) +++ head/sys/kern/vfs_cluster.c Sat Aug 7 18:30:10 2010(r211031) @@ -71,7 +71,7 @@ static int write_behind = 1; SYSCTL_INT(_vfs, OID_AUTO, write_behind, CTLFLAG_RW, write_behind, 0, Cluster write-behind; 0: disable, 1: enable, 2: backed off); -static int read_max = 8; +static int read_max = 16; SYSCTL_INT(_vfs, OID_AUTO, read_max, CTLFLAG_RW, read_max, 0, Cluster read-ahead max block count); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r210410 - head/sys/kern
Author: ivoras Date: Fri Jul 23 12:30:29 2010 New Revision: 210410 URL: http://svn.freebsd.org/changeset/base/210410 Log: Make lorunningspace catch up with hirunningspace. While there, add comment about the magic numbers. Prodded by: alc Modified: head/sys/kern/vfs_bio.c Modified: head/sys/kern/vfs_bio.c == --- head/sys/kern/vfs_bio.c Fri Jul 23 11:00:46 2010(r210409) +++ head/sys/kern/vfs_bio.c Fri Jul 23 12:30:29 2010(r210410) @@ -620,9 +620,14 @@ bufinit(void) hibufspace = lmax(3 * maxbufspace / 4, maxbufspace - MAXBSIZE * 10); lobufspace = hibufspace - MAXBSIZE; - lorunningspace = 512 * 1024; + /* +* Note: The 16 MB upper limit for hirunningspace was chosen +* arbitrarily and may need further tuning. The lower 1 MB +* limit is the historical upper limit for hirunningspace. +*/ hirunningspace = lmax(lmin(roundup(hibufspace / 64, MAXBSIZE), 16 * 1024 * 1024), 1024 * 1024); + lorunningspace = roundup(hirunningspace / 2, MAXBSIZE); /* * Limit the amount of malloc memory since it is wired permanently into ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r210217 - head/sys/kern
On 21 July 2010 06:18, Bruce Evans b...@optusnet.com.au wrote: On Mon, 19 Jul 2010, John Baldwin wrote: Log: In keeping with the Age-of-the-fruitbat theme, scale up hirunningspace on machines which can clearly afford the memory. This is a somewhat conservative version of the patch - more fine tuning may be necessary. Idea from: Thread on hackers@ Discussed with: alc Sorry I didn't look at the thread, but I wonder if you should increase lorunningspace similarly. The previous ratio of lorunningspace to hirunningspace was 1/2 - is this still a good target? There is a possibly related problem with writing through file systems to high-latency disk devices like dvds. getblk() often takes many seconds, and occasionally takes a couple of _minutes_. dvd's aren't quite that slow, and can easily write hirunningspace = 1MB in 1 second, except possibly if the file system is not designed for high-latency devices (like most including cd9660 and udf are :-() so it does lots of random i/o). The above is mostly for 1 active file system... It does seem like there would be more benefitial to hang these variables per mount-point or something similar but I'm content that they are tunable and that the new values help high-end machines, probably in cooperation with tagged (NCQ-like) IO. Presumably you could use 'lmax(lmin(..., 16 * 1024 * 1024), 1024 * 1024))'? Better. Normal formatting is sometimes broken to avoid lines longer than 80 characters. This works here. I don't like this. Yes, this was the reason for the original patch's formatting :) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r210295 - head/sys/kern
Author: ivoras Date: Tue Jul 20 13:59:51 2010 New Revision: 210295 URL: http://svn.freebsd.org/changeset/base/210295 Log: Fix expression style. Prodded by: jhb Modified: head/sys/kern/vfs_bio.c Modified: head/sys/kern/vfs_bio.c == --- head/sys/kern/vfs_bio.c Tue Jul 20 12:36:36 2010(r210294) +++ head/sys/kern/vfs_bio.c Tue Jul 20 13:59:51 2010(r210295) @@ -621,9 +621,8 @@ bufinit(void) lobufspace = hibufspace - MAXBSIZE; lorunningspace = 512 * 1024; - hirunningspace = lmin(roundup(hibufspace/64, MAXBSIZE), 16*1024*1024); - if (hirunningspace 1024 * 1024) - hirunningspace = 1024 * 1024; + hirunningspace = lmax(lmin(roundup(hibufspace / 64, MAXBSIZE), + 16 * 1024 * 1024), 1024 * 1024); /* * Limit the amount of malloc memory since it is wired permanently into ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r210217 - head/sys/kern
Author: ivoras Date: Sun Jul 18 10:15:33 2010 New Revision: 210217 URL: http://svn.freebsd.org/changeset/base/210217 Log: In keeping with the Age-of-the-fruitbat theme, scale up hirunningspace on machines which can clearly afford the memory. This is a somewhat conservative version of the patch - more fine tuning may be necessary. Idea from: Thread on hackers@ Discussed with: alc Modified: head/sys/kern/vfs_bio.c Modified: head/sys/kern/vfs_bio.c == --- head/sys/kern/vfs_bio.c Sun Jul 18 08:54:31 2010(r210216) +++ head/sys/kern/vfs_bio.c Sun Jul 18 10:15:33 2010(r210217) @@ -621,7 +621,9 @@ bufinit(void) lobufspace = hibufspace - MAXBSIZE; lorunningspace = 512 * 1024; - hirunningspace = 1024 * 1024; + hirunningspace = lmin(roundup(hibufspace/64, MAXBSIZE), 16*1024*1024); + if (hirunningspace 1024 * 1024) + hirunningspace = 1024 * 1024; /* * Limit the amount of malloc memory since it is wired permanently into ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r210117 - head/sys/kern
Author: ivoras
Date: Thu Jul 15 13:46:30 2010
New Revision: 210117
URL: http://svn.freebsd.org/changeset/base/210117
Log:
A cosmetic change - don't output empty flags.
Modified:
head/sys/kern/sched_ule.c
Modified: head/sys/kern/sched_ule.c
==
--- head/sys/kern/sched_ule.c Thu Jul 15 13:21:25 2010(r210116)
+++ head/sys/kern/sched_ule.c Thu Jul 15 13:46:30 2010(r210117)
@@ -2656,16 +2656,16 @@ sysctl_kern_sched_topology_spec_internal
}
sbuf_printf(sb, /cpu\n);
- sbuf_printf(sb, %*s flags, indent, );
if (cg-cg_flags != 0) {
+ sbuf_printf(sb, %*s flags, indent, );
if ((cg-cg_flags CG_FLAG_HTT) != 0)
sbuf_printf(sb, flag name=\HTT\HTT group/flag);
if ((cg-cg_flags CG_FLAG_THREAD) != 0)
sbuf_printf(sb, flag name=\THREAD\THREAD
group/flag);
if ((cg-cg_flags CG_FLAG_SMT) != 0)
sbuf_printf(sb, flag name=\SMT\SMT group/flag);
+ sbuf_printf(sb, /flags\n);
}
- sbuf_printf(sb, /flags\n);
if (cg-cg_children 0) {
sbuf_printf(sb, %*s children\n, indent, );
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r209037 - head/sys/kern
Author: ivoras
Date: Fri Jun 11 09:27:33 2010
New Revision: 209037
URL: http://svn.freebsd.org/changeset/base/209037
Log:
In another move to join with the age of the Fruitbat, increase SYSV
shared resources defaults beyond absolute minimums.
The new values are chosen mostly by magic. They are still fairly
small and will need increasing for large installations (especially
SHMMAX). However, they are now enough to e.g. start PostgreSQL
installations with ~~300 users and nearly 512 MB of shared buffers.
Reviewed by: A short discussion on hackers@
Modified:
head/sys/kern/sysv_sem.c
head/sys/kern/sysv_shm.c
Modified: head/sys/kern/sysv_sem.c
==
--- head/sys/kern/sysv_sem.cFri Jun 11 08:13:26 2010(r209036)
+++ head/sys/kern/sysv_sem.cFri Jun 11 09:27:33 2010(r209037)
@@ -133,16 +133,16 @@ struct sem_undo {
* Configuration parameters
*/
#ifndef SEMMNI
-#define SEMMNI 10 /* # of semaphore identifiers */
+#define SEMMNI 50 /* # of semaphore identifiers */
#endif
#ifndef SEMMNS
-#define SEMMNS 60 /* # of semaphores in system */
+#define SEMMNS 340 /* # of semaphores in system */
#endif
#ifndef SEMUME
-#define SEMUME 10 /* max # of undo entries per process */
+#define SEMUME 50 /* max # of undo entries per process */
#endif
#ifndef SEMMNU
-#define SEMMNU 30 /* # of undo structures in system */
+#define SEMMNU 150 /* # of undo structures in system */
#endif
/* shouldn't need tuning */
Modified: head/sys/kern/sysv_shm.c
==
--- head/sys/kern/sysv_shm.cFri Jun 11 08:13:26 2010(r209036)
+++ head/sys/kern/sysv_shm.cFri Jun 11 09:27:33 2010(r209037)
@@ -133,7 +133,7 @@ static int sysctl_shmsegs(SYSCTL_HANDLER
* Tuneable values.
*/
#ifndef SHMMAXPGS
-#defineSHMMAXPGS 8192/* Note: sysv shared memory is swap
backed. */
+#defineSHMMAXPGS 131072 /* Note: sysv shared memory is swap
backed. */
#endif
#ifndef SHMMAX
#defineSHMMAX (SHMMAXPGS*PAGE_SIZE)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r208983 - head/sys/kern
Author: ivoras
Date: Thu Jun 10 11:48:14 2010
New Revision: 208983
URL: http://svn.freebsd.org/changeset/base/208983
Log:
Unconfuse THREAD and SMT flags
Modified:
head/sys/kern/sched_ule.c
Modified: head/sys/kern/sched_ule.c
==
--- head/sys/kern/sched_ule.c Thu Jun 10 11:01:17 2010(r208982)
+++ head/sys/kern/sched_ule.c Thu Jun 10 11:48:14 2010(r208983)
@@ -2662,8 +2662,10 @@ sysctl_kern_sched_topology_spec_internal
if (cg-cg_flags != 0) {
if ((cg-cg_flags CG_FLAG_HTT) != 0)
sbuf_printf(sb, flag name=\HTT\HTT group/flag);
+ if ((cg-cg_flags CG_FLAG_THREAD) != 0)
+ sbuf_printf(sb, flag name=\THREAD\THREAD
group/flag);
if ((cg-cg_flags CG_FLAG_SMT) != 0)
- sbuf_printf(sb, flag name=\THREAD\SMT
group/flag);
+ sbuf_printf(sb, flag name=\SMT\SMT group/flag);
}
sbuf_printf(sb, /flags\n);
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r208190 - head/usr.sbin/daemon
Author: ivoras Date: Mon May 17 11:18:33 2010 New Revision: 208190 URL: http://svn.freebsd.org/changeset/base/208190 Log: Slightly improve wording. Modified: head/usr.sbin/daemon/daemon.8 Modified: head/usr.sbin/daemon/daemon.8 == --- head/usr.sbin/daemon/daemon.8 Mon May 17 09:37:59 2010 (r208189) +++ head/usr.sbin/daemon/daemon.8 Mon May 17 11:18:33 2010 (r208190) @@ -63,7 +63,8 @@ Note, that the file will be created shor actually executed, and will remain after the process exits (although it will be removed if the execution fails). .It Fl u Ar user -Run the program with the rights of user specified, requires privilege. +Login name of the user to execute the program under. +Requires adequate superuser privileges. .El .Sh EXIT STATUS The ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r205487 - head/sys/vm
On 22 March 2010 23:39, Kip Macy km...@freebsd.org wrote: Author: kmacy Date: Mon Mar 22 22:39:32 2010 New Revision: 205487 URL: http://svn.freebsd.org/changeset/base/205487 Log: - enable alignment on amd64 only Does this mean you have determined that aligning these structures is not as beneficial on i386 or is there something else going on? ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: I486_CPU and I586_CPU removed from GENERIC kernel [was Re: svn commit: r205307 - head/sys/i386/conf]
On 19 March 2010 17:22, Valentin Nechayev ne...@netch.kiev.ua wrote: Fri, Mar 19, 2010 at 17:13:00, ivoras wrote about Re: I486_CPU and I586_CPU removed from GENERIC kernel [was Re: svn commit: r205307 - head/sys/i386/conf]: SSE in the userland you mean? Regardless, I don't think there is now reason for compiling everything as for i386. E.g. why not add at least -mtune=generic or even also -march=i686 to default gcc options? http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html Having userland compiled with i686 will give the same effect as i686-only kernel: it won't boot on machines which doesn't conform to. If it is supposed to boot on i486 and higher, no more than -march=i486 can be used. Yes, this is how I read the change - the move from i386 to i686. I apologize if I got it wrong :) As it was pointed out earlier - small systems users and designers probably have special install procedures because of the nature of the business. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r204870 - head/sys/modules
On 8 March 2010 19:29, Ivan Voras ivo...@freebsd.org wrote: On 8 March 2010 19:14, Ivan Voras ivo...@freebsd.org wrote: On 8 March 2010 16:01, Nathan Whitehorn nwhiteh...@freebsd.org wrote: Author: nwhitehorn Date: Mon Mar 8 15:01:08 2010 New Revision: 204870 URL: http://svn.freebsd.org/changeset/base/204870 Log: Enable tmpfs unconditionally on all platforms. No one I spoke to could remember why it was x86 only, and it works just as well on at least powerpc as on x86. And it still has the Big Ugly run away! run away! banner displayed on load :( I've just run it through the tools/regression/fstest suite and it passes all tests except the NFSv4-style permissions related ones (tests/granular/*): Failed 6/192 test scripts. 181/3473 subtests failed. Files=192, Tests=3473, 90 wallclock secs ( 7.58 cusr + 30.63 csys = 38.21 CPU) Failed 6/192 test programs. 181/3473 subtests failed. Well nevermind, I spoke too soon - it fails the regression/fsx tests immediately :( ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r204249 - head/sys/dev/syscons/snake
Author: ivoras
Date: Tue Feb 23 15:27:07 2010
New Revision: 204249
URL: http://svn.freebsd.org/changeset/base/204249
Log:
The New and Improved snake_server - Service Pack 1: now even more
sensitive to load average variations!
Modified:
head/sys/dev/syscons/snake/snake_saver.c
Modified: head/sys/dev/syscons/snake/snake_saver.c
==
--- head/sys/dev/syscons/snake/snake_saver.cTue Feb 23 15:12:41 2010
(r204248)
+++ head/sys/dev/syscons/snake/snake_saver.cTue Feb 23 15:27:07 2010
(r204249)
@@ -114,7 +114,7 @@ snake_saver(video_adapter_t *adp, int bl
savs[0] += dirx + diry;
if (FANCY_SNAKE) {
update_msg();
- load = LOAD_HIGH(averunnable.ldavg[0]) * 100;
+ load = ((averunnable.ldavg[0] * 100 + FSCALE / 2)
FSHIFT);
if (load == 0)
color = FG_LIGHTGREY | BG_BLACK;
else if (load / mp_ncpus = 50)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
