Re: NFS + VM question
On Fri, 15 Oct 2004 13:49:48 +0100, David Malone <[EMAIL PROTECTED]> wrote: > On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > > On the other hand, the kernel should know that the mounts > > come from the same NFS source, so it might actually be able > > to handle it efficiently (i.e. share). But I really don't > > know. Any FreeBSD kernel hacker can enlighten me? > > Since the server could actually hand out different content depending > on the mount instance, I don't think the NFS client could make these > assumptions. If you try NFS mounting /usr a few times and then time > how long it takes to cat a cached file, you'll see this. > Maybe I'm missing something, but I'm not convinced that's true. NFS is "file-handle" centric: there's no real concept of a "mount point" at the server: the mount operation just gives you a handle to the root directory, so if the two mounts from a server give the same file handles to a client, then the results should be consistent. I'd go so far as to say It's even more general than that: a client mounting two different points of the server's filesystem locally could share filehandles if the server's directories intersected (or one was a proper subset of the other, which is more likely) This makes sense, given NFS's statelessness. Of course, given the way the _client_ filesystem code works, it's not going to take advantange of that particular quirk. It's almost certainly not worth doing it at this layer anyhow. (Having two local filesystems trying to share one vnode would be, em, awkward) > > If the memory isn't shared in this situation, is there a > > way to change the design so it can be shared? chroot and > > NFS are "musts", though. > > I don't think there is an easy way to get this caching to happen, > short of using hard links or some kind of union mount instead of > NFS. > "nullfs" sounds like just the job here. ie, mount the NFS filesystem once, then use nullfs to graft it into each chroot area: mount host:/usr /mnt mount -tnullfs /mnt /jail/1 mount -tnullfs /mnt /jail/2 Of course, there's more overhead than if you weren't using the extra nullfs layer, but the caching works as you want. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS + VM question
Peter Edwards wrote: > On Fri, 15 Oct 2004 13:49:48 +0100, David Malone <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote: > > > [...] > > > If the memory isn't shared in this situation, is there a > > > way to change the design so it can be shared? chroot and > > > NFS are "musts", though. > > > > I don't think there is an easy way to get this caching to happen, > > short of using hard links or some kind of union mount instead of > > NFS. > > "nullfs" sounds like just the job here. ie, mount the NFS filesystem > once, then use nullfs to graft it into each chroot area: > > mount host:/usr /mnt > mount -tnullfs /mnt /jail/1 > mount -tnullfs /mnt /jail/2 > > Of course, there's more overhead than if you weren't using the extra > nullfs layer, but the caching works as you want. Thanks for the explanation. It really sounds like nullfs would be the solution for me, but unfortunately, I can't use it because of the known pro- blems of nullfs in FreeBSD 4-stable (which is the branch that I'm using). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
open() vs the lowest unused file descriptor
Hi! Today I noticed that on Single Unix Specification V2, as well as on the Linux 2.4.26 machine I have here, that the open() call promises to return the lowest unused file descriptor when successful. I'm just wondering: does FreeBSD 4.x and 5.x promise that? If so, should we update the manpage to match SUSv2 more closely? Thank you! - Carl _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS + VM question
On Thu, 14 Oct 2004 23:57, Oliver Fromme wrote: > File: "/chroot/one/bin/httpd" > Device: 255,33554437 Inode: 2268790Links: 1 > File: "/chroot/two/bin/httpd" > Device: 255,33554439 Inode: 2268790Links: 1 > File: "/chroot/one/bin/httpd" > Device: 255,33554458 Inode: 2268790Links: 1 You could do hardlink tricks (and chflags to prevent one jail attacking the others).. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp3xnKU7ulIC.pgp Description: PGP signature
Re: open() vs the lowest unused file descriptor
Carl J wrote: Hi! Today I noticed that on Single Unix Specification V2, as well as on the Linux 2.4.26 machine I have here, that the open() call promises to return the lowest unused file descriptor when successful. I'm just wondering: does FreeBSD 4.x and 5.x promise that? If so, should we update the manpage to match SUSv2 more closely? Thank you! - Carl 4.x I'm pretty sure about 5.x I know does. This isn't a new thing. Since as far back as I can remember the UNIX semantics have been to return the lowest unused fd on an open(2) call. This has also been the subject of much discussion as finding the first free descriptor can cost a lot of processing power for applications that use large numbers of descriptors. FreeBSD uses a bitmap with hints I believe. All code would be in sys/kern_descrip.c. -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS + VM question
> It really sounds like nullfs would be the solution for me, > but unfortunately, I can't use it because of the known pro- > blems of nullfs in FreeBSD 4-stable (which is the branch > that I'm using). It would definitely be the solution, but there are still problems with it. Mark Liminon made a call for PR concerning nullfs a few month ago. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1874558+0+archive/2004/freebsd-current/20040718.freebsd-current AFAIK, none of the above problems has been solved, but I may be wrong. -- Jeremie Le Hen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
thread-safe popen(3) at 4-STABLE
Dear colleagues,
checking for hanged and CPU-eating clamav, my colleague ([EMAIL PROTECTED]) found
that popen(3) is not thread safe. What about commiting tjr's fix (attached) to
RELENG_4?
Sincerely,
D.Marck[DM5020, MCK-RIPE, DM3-RIPN]
---
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
---Index: lib/libc/gen/popen.c
===
RCS file: /home/ncvs/src/lib/libc/gen/popen.c,v
retrieving revision 1.14
diff -u -r1.14 popen.c
--- lib/libc/gen/popen.c27 Jan 2000 23:06:19 - 1.14
+++ lib/libc/gen/popen.c16 Oct 2004 16:14:38 -
@@ -51,6 +51,17 @@
#include
#include
+#ifndef _THREAD_SAFE
+#define THREAD_LOCK()
+#define THREAD_UNLOCK()
+#else
+#include
+#include "libc_private.h"
+static pthread_mutex_t pidlist_mutex = PTHREAD_MUTEX_INITIALIZER;
+#defineTHREAD_LOCK() if (__isthreaded) _pthread_mutex_lock(&pidlist_mutex)
+#defineTHREAD_UNLOCK() if (__isthreaded) _pthread_mutex_unlock(&pidlist_mutex)
+#endif /* _THREAD_SAFE */
+
extern char **environ;
static struct pid {
@@ -95,8 +106,10 @@
argv[2] = (char *)command;
argv[3] = NULL;
+ THREAD_LOCK();
switch (pid = vfork()) {
case -1:/* Error. */
+ THREAD_UNLOCK();
(void)_close(pdes[0]);
(void)_close(pdes[1]);
free(cur);
@@ -134,6 +147,7 @@
_exit(127);
/* NOTREACHED */
}
+ THREAD_UNLOCK();
/* Parent; assume fdopen can't fail. */
if (*type == 'r') {
@@ -146,9 +160,11 @@
/* Link into list of file descriptors. */
cur->fp = iop;
- cur->pid = pid;
+ cur->pid = pid;
+ THREAD_LOCK();
cur->next = pidlist;
pidlist = cur;
+ THREAD_UNLOCK();
return (iop);
}
@@ -167,12 +183,23 @@
int pstat;
pid_t pid;
- /* Find the appropriate file pointer. */
+ /*
+* Find the appropriate file pointer and remove it from the list.
+*/
+ THREAD_LOCK();
for (last = NULL, cur = pidlist; cur; last = cur, cur = cur->next)
if (cur->fp == iop)
break;
- if (cur == NULL)
+ if (cur == NULL) {
+ THREAD_UNLOCK();
return (-1);
+ }
+ /* Remove the entry from the linked list. */
+ if (last == NULL)
+ pidlist = cur->next;
+ else
+ last->next = cur->next;
+ THREAD_UNLOCK();
(void)fclose(iop);
@@ -180,11 +207,6 @@
pid = _wait4(cur->pid, &pstat, 0, (struct rusage *)0);
} while (pid == -1 && errno == EINTR);
- /* Remove the entry from the linked list. */
- if (last == NULL)
- pidlist = cur->next;
- else
- last->next = cur->next;
free(cur);
return (pid == -1 ? -1 : pstat);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] add '-' glibc extension to strftime(3)
Hi, folks,
It turns out that the GNU extension '-' in their strftime(3) implementation
is somewhat popular in several applications. The patch in the last part of
this e-mail will add a simulate implementation for it.
My question is:
(1) Am I doing things cleanly and correctly? I have attempted to
keep the code style consistent with the old one and style(9)
but maybe I have missed something else, or did not do it
sufficently?
(2) Is the way of implementing it clean enough?
Thanks for any comments!
Index: strftime.3
===
RCS file: /home/fcvs/src/lib/libc/stdtime/strftime.3,v
retrieving revision 1.34
diff -u -r1.34 strftime.3
--- strftime.3 2 Jul 2004 23:52:12 - 1.34
+++ strftime.3 16 Oct 2004 17:13:08 -
@@ -36,7 +36,7 @@
.\" @(#)strftime.3 8.1 (Berkeley) 6/4/93
.\" $FreeBSD: src/lib/libc/stdtime/strftime.3,v 1.34 2004/07/02 23:52:12 ru Exp $
.\"
-.Dd January 4, 2003
+.Dd October 17, 2004
.Dt STRFTIME 3
.Os
.Sh NAME
@@ -216,6 +216,8 @@
is replaced by national representation of the date and time
(the format is similar to that produced by
.Xr date 1 ) .
+.It Cm %-*
+GLIBC extensions. Do not do padding when making output.
.It Cm %%
is replaced by
.Ql % .
Index: strftime.c
===
RCS file: /home/fcvs/src/lib/libc/stdtime/strftime.c,v
retrieving revision 1.40
diff -u -r1.40 strftime.c
--- strftime.c 14 Jun 2004 10:31:52 - 1.40
+++ strftime.c 16 Oct 2004 17:14:24 -
@@ -59,6 +59,13 @@
#define IN_THIS2
#define IN_ALL 3
+#define PAD_DEFAULT0
+#define PAD_LESS 1
+#if 0 /* XXX NOT IMPLEMENTED YET */
+#define PAD_SPACE 2
+#define PAD_ZERO 3
+#endif
+
size_t
strftime(char * __restrict s, size_t maxsize, const char * __restrict format,
const struct tm * __restrict t)
@@ -99,13 +106,14 @@
const char * const ptlim;
int * warnp;
{
- int Ealternative, Oalternative;
+ int Ealternative, Oalternative, Palternative;
struct lc_time_T *tptr = __get_current_time_locale();
for ( ; *format; ++format) {
if (*format == '%') {
Ealternative = 0;
Oalternative = 0;
+ Palternative = PAD_DEFAULT;
label:
switch (*++format) {
case '\0':
@@ -188,21 +196,27 @@
Oalternative++;
goto label;
case 'e':
- pt = _conv(t->tm_mday, "%2d", pt, ptlim);
+ pt = _conv(t->tm_mday, (Palternative == PAD_LESS) ?
+ "%d" : "%2d",
+ pt, ptlim);
continue;
case 'F':
pt = _fmt("%Y-%m-%d", t, pt, ptlim, warnp);
continue;
case 'H':
- pt = _conv(t->tm_hour, "%02d", pt, ptlim);
+ pt = _conv(t->tm_hour, (Palternative == PAD_LESS) ?
+ "%d" : "%02d",
+ pt, ptlim);
continue;
case 'I':
pt = _conv((t->tm_hour % 12) ?
- (t->tm_hour % 12) : 12,
- "%02d", pt, ptlim);
+ (t->tm_hour % 12) : 12, (Palternative ==
PAD_LESS) ?
+ "%d" : "%02d",
+ pt, ptlim);
continue;
case 'j':
- pt = _conv(t->tm_yday + 1, "%03d", pt, ptlim);
+ pt = _conv(t->tm_yday + 1, (Palternative == PAD_LESS) ?
+ "%d" : "%03d", pt, ptlim);
continue;
case 'k':
/*
@@ -215,7 +229,9 @@
** "%l" have been swapped.
** (ado, 1993-05-24)
*/
- pt = _conv(t->tm_hour, "%2d", pt, ptlim);
+ pt = _conv(t->tm_hour, (Palternative == PAD_LESS) ?
+ "%d": "%2d",
+ pt, ptlim);
continue;
#ifdef KITCHEN_SINK
case 'K':
@@ -236,14 +252,19 @@
** (ado, 1993-05-24)
*/
pt = _conv((t->tm_hour % 12) ?
-
