Re: is read-write nullfs safe?
On Tue, Jun 19, 2007 at 02:39:22PM +0800, Rong-en Fan wrote: > On 6/19/07, Josh Paetzel <[EMAIL PROTECTED]> wrote: > >On Tuesday 19 June 2007, Rong-en Fan wrote: > >> I'm running 6.2-RELEASE, and I am wondering > >> if using nullfs w/ rw is safe in a production environment? > >> My impression is that ro nullfs is ok, but not rw. > >> Is this still the case? > >> > >> Regards, > >> Rong-En Fan > > > >I've been using r/w nullfs in production for ages without issue...sure > >you're not confusing nullfs with unionfs? > > I'm aware that unionfs status and I think it's usable > in 7.x, right? > > I was asking about nullfs because the following lines > in sys/conf/NOTES: > > # NB: The NULL, PORTAL, UMAP and UNION filesystems are known to be > # buggy, and WILL panic your system if you attempt to do anything with > # them. They are included here as an incentive for some enterprising > # soul to sit down and fix them. Yeah, that's almost completely stale for both 6.x and 7.x. nullfs is entirely stable, and unionfs is much better (i.e. not the instant disaster it used to be), although it still has some serious issues. I think umap was actually disconnected entirely from the kernel and module build, although the code was not removed (it should be, that's what the attic is for). portal probably has bugs since no-one uses it. Kris pgpcaQx4mEJmh.pgp Description: PGP signature
Re: is read-write nullfs safe?
I use it all the time for compiles on top of nfs On 6/18/07, Rong-en Fan <[EMAIL PROTECTED]> wrote: I'm running 6.2-RELEASE, and I am wondering if using nullfs w/ rw is safe in a production environment? My impression is that ro nullfs is ok, but not rw. Is this still the case? Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: deinstall ports
Rodrigo Galiano wrote: > No, if you make 'deinstall' under a specific port it will only uninstall > the > software package with the dependencies. If you want to deinstall > dependencies do the command 'make clean' to check out what will be > actually > installed and diff the output with the results obtained with the > 'pkg_info' > command. Then finally do the command 'pkg_delete #package_name#' to > deinstall the dependencies. I believe the original question was if removing a package would by default removes the dependencies of the package too, to which the answer is no. I don't think the intention of the original poster was to attempt to actually deinstall the dependencies. Perhaps I misread the original post. Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
WAS: misc/113825: WARN Error in FreeBSD 6.2-STABLE (/usr/src/lib/libc/rpc/getpublickey.c)
Sigh . . .
Here are the patches I was trying to upload when the PR was closed
without mercy. :)
jmc
# Patch for misc/113825 for csup
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -c 'contrib/csup/proto.c.old' 'contrib/csup/proto.c'
Index: ./contrib/csup/proto.c.old
*** ./contrib/csup/proto.c.old Tue Jun 19 04:29:42 2007
--- ./contrib/csup/proto.c Tue Jun 19 05:31:31 2007
***
*** 68,74
};
static voidkiller_start(struct killer *, struct mux *);
! static void *killer_run(void *);
static voidkiller_stop(struct killer *);
static int proto_waitconnect(int);
--- 68,74
};
static voidkiller_start(struct killer *, struct mux *);
! static voidkiller_run(void *);
static voidkiller_stop(struct killer *);
static int proto_waitconnect(int);
***
*** 963,968
--- 963,970
/* Start the killer thread. It is used to protect against some signals
during the multi-threaded run so that we can gracefully fail. */
+ typedef void *(*start_routine)(void *);
+
static void
killer_start(struct killer *k, struct mux *m)
{
***
*** 976,988
sigaddset(&k->sigset, SIGTERM);
sigaddset(&k->sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, &k->sigset, NULL);
! error = pthread_create(&k->thread, NULL, killer_run, k);
if (error)
err(1, "pthread_create");
}
/* The main loop of the killer thread. */
! static void *
killer_run(void *arg)
{
struct killer *k;
--- 978,991
sigaddset(&k->sigset, SIGTERM);
sigaddset(&k->sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, &k->sigset, NULL);
! error = pthread_create(&k->thread, NULL, (start_routine)killer_run, k);
if (error)
err(1, "pthread_create");
}
/* The main loop of the killer thread. */
!
! static void
killer_run(void *arg)
{
struct killer *k;
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 06:52:53 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
# (\A|/).*\.olb\Z
# (\A|/).*\.old\Z
# (\A|/).*\.orig\Z
# (\A|/).*\.rej\Z
# (\A|/).*\.so\Z
# (\A|/).*\.Z\Z
# (\A|/)\.del\-.*\Z
# (\A|/)\.make\.state\Z
# (\A|/)\.nse_depinfo\Z
# (\A|/)core\Z
# (\A|/)tags\Z
# (\A|/)TAGS\Z
# p 'contrib/csup/proto.c.old' 25477 1182245491 0100644
End of ApplyPatch data
End of Patch kit [created: Tue Jun 19 06:52:53 2007]
Patch checksum: 96 2948 4469
Checksum: 114 3601 58469
# Patch for misc/113825 for ggated
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -c 'sbin/ggate/ggated/ggated.c.old' 'sbin/ggate/ggated/ggated.c'
Index: ./sbin/ggate/ggated/ggated.c.old
*** ./sbin/ggate/ggated/ggated.c.oldMon Jun 18 23:05:16 2007
--- ./sbin/ggate/ggated/ggated.cMon Jun 18 23:08:02 2007
***
*** 756,761
--- 756,762
error = pthread_mutex_unlock(&outqueue_mtx);
assert(error == 0);
}
+ return arg;
}
static void *
***
WAS: misc/113825: WARN Error in FreeBSD 6.2-STABLE (/usr/src/lib/libc/rpc/getpublickey.c)
Maybe you would like unified diff's better? Sorry . . .
jmc
# misc/113825
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -ruN 'contrib/csup/proto.c.old' 'contrib/csup/proto.c'
Index: ./contrib/csup/proto.c.old
--- ./contrib/csup/proto.c.old Tue Jun 19 04:29:42 2007
+++ ./contrib/csup/proto.c Tue Jun 19 05:31:31 2007
@@ -68,7 +68,7 @@
};
static void killer_start(struct killer *, struct mux *);
-static void*killer_run(void *);
+static void killer_run(void *);
static void killer_stop(struct killer *);
static int proto_waitconnect(int);
@@ -963,6 +963,8 @@
/* Start the killer thread. It is used to protect against some signals
during the multi-threaded run so that we can gracefully fail. */
+typedef void *(*start_routine)(void *);
+
static void
killer_start(struct killer *k, struct mux *m)
{
@@ -976,13 +978,14 @@
sigaddset(&k->sigset, SIGTERM);
sigaddset(&k->sigset, SIGPIPE);
pthread_sigmask(SIG_BLOCK, &k->sigset, NULL);
- error = pthread_create(&k->thread, NULL, killer_run, k);
+ error = pthread_create(&k->thread, NULL, (start_routine)killer_run, k);
if (error)
err(1, "pthread_create");
}
/* The main loop of the killer thread. */
-static void *
+
+static void
killer_run(void *arg)
{
struct killer *k;
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 07:31:02 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
# (\A|/).*\.olb\Z
# (\A|/).*\.old\Z
# (\A|/).*\.orig\Z
# (\A|/).*\.rej\Z
# (\A|/).*\.so\Z
# (\A|/).*\.Z\Z
# (\A|/)\.del\-.*\Z
# (\A|/)\.make\.state\Z
# (\A|/)\.nse_depinfo\Z
# (\A|/)core\Z
# (\A|/)tags\Z
# (\A|/)TAGS\Z
# p 'contrib/csup/proto.c.old' 25477 1182245491 0100644
End of ApplyPatch data
End of Patch kit [created: Tue Jun 19 07:31:02 2007]
Patch checksum: 73 2412 32655
Checksum: 91 3047 19426
# misc/113825
#
# To apply this patch:
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'applypatch' program with this patch file as input.
#
# If you do not have 'applypatch', it is part of the 'makepatch' package
# that you can fetch from the Comprehensive Perl Archive Network:
# http://www.perl.com/CPAN/authors/Johan_Vromans/makepatch-x.y.tar.gz
# In the above URL, 'x' should be 2 or higher.
#
# To apply this patch without the use of 'applypatch':
# STEP 1: Chdir to the source directory.
# STEP 2: Run the 'patch' program with this file as input.
#
End of Preamble
Patch data follows
diff -ruN 'sbin/ggate/ggated/ggated.c.old' 'sbin/ggate/ggated/ggated.c'
Index: ./sbin/ggate/ggated/ggated.c.old
--- ./sbin/ggate/ggated/ggated.c.oldMon Jun 18 23:05:16 2007
+++ ./sbin/ggate/ggated/ggated.cMon Jun 18 23:08:02 2007
@@ -756,6 +756,7 @@
error = pthread_mutex_unlock(&outqueue_mtx);
assert(error == 0);
}
+ return arg;
}
static void *
@@ -810,6 +811,7 @@
}
free(req);
}
+ return arg;
}
static void
End of Patch data
ApplyPatch data follows
# Data version: 1.0
# Date generated : Tue Jun 19 07:35:00 2007
# Generated by: makepatch 2.03
# Recurse directories : Yes
# Excluded files : (\A|/).*\~\Z
# (\A|/).*\.a\Z
# (\A|/).*\.bak\Z
# (\A|/).*\.BAK\Z
# (\A|/).*\.elc\Z
# (\A|/).*\.exe\Z
# (\A|/).*\.gz\Z
# (\A|/).*\.ln\Z
# (\A|/).*\.o\Z
# (\A|/).*\.obj\Z
Re: is read-write nullfs safe?
Rong-en Fan wrote: > I'm running 6.2-RELEASE, and I am wondering > if using nullfs w/ rw is safe in a production environment? > My impression is that ro nullfs is ok, but not rw. > Is this still the case? I've been using a r/w nullfs for the last several months with no issues. Granted, I don't do a heavy amount of writing to the mount point but I haven't seen any issues with it whatsoever. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange problem with skype on RELENG_6 KERNEL since the end of may.
On Thu, 14 Jun 2007 09:29:09 -0500
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> A RELENG_6 kernel from May 21 works fine with skype but boot a newer
> kernel and skype seems to be blocking port 80. Apache logs show
> nothing. I can find no logs errors anywhere but a telnet to port 80
> answers with what would seem to be binary chars. I close skype and
> all is back to normal. I had originally thought that it had to do
> with the new xorg installation but it seems to be something in the
> kernel. The configurations were the same, basically GENERIC with all
> the pf stuff.
Hi,
Skype has an option to listen on tcp/80 and tcp/443 for incoming connections,
because it assumes somehow that firewalls will be configured to allow that
traffic in (some Windowze world assumption, i guess).
In the tools menu, go to Options, Advanced, untick the option that reads "Use
port (sic) 80 and 443 as alternatives for incoming connections".
Apply, exit skype, restart it.
confirm with
sockstat -4 | grep skype | grep \*:80
that skype is NOT listening on port 80 (you shouldn't see any output back from
that cmd) ( similar for 443)
_
{Beto|Norberto|Numard} Meijome
RTFM and STFW before anything bad happens.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When inode change time changes?
On Sunday 17 June 2007 00:24, Artem Kuchin wrote: > Maybe someone can englighten me when > inode change time changes? What must be done > with file to change it (except writing to it)? stat(2) would be very enlightening in this context. > I tried chmoding - it does not affect inode time. chmod works for me: nik:1:~$ stat -f "%c" /tmp/test 1182266005 nik:1:~$ chmod -rw /tmp/test nik:1:~$ stat -f "%c" /tmp/test 1182266014 How do check the timestamps? Do you use stat(1) or something else? Nikos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange problem with skype on RELENG_6 KERNEL since the end of may.
On Tue, 2007-06-19 at 23:40 +1000, Norberto Meijome wrote: > > On Thu, 14 Jun 2007 09:29:09 -0500 > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > A RELENG_6 kernel from May 21 works fine with skype but boot a newer > > kernel and skype seems to be blocking port 80. Apache logs show > > nothing. I can find no logs errors anywhere but a telnet to port 80 > > answers with what would seem to be binary chars. I close skype and > > all is back to normal. I had originally thought that it had to do > > with the new xorg installation but it seems to be something in the > > kernel. The configurations were the same, basically GENERIC with all > > the pf stuff. > > Hi, > > Skype has an option to listen on tcp/80 and tcp/443 for incoming connections, > because it assumes somehow that firewalls will be configured to allow that > traffic in (some Windowze world assumption, i guess). > > In the tools menu, go to Options, Advanced, untick the option that reads "Use > port (sic) 80 and 443 as alternatives for incoming connections". > > Apply, exit skype, restart it. > > confirm with > > sockstat -4 | grep skype | grep \*:80 > > that skype is NOT listening on port 80 (you shouldn't see any output back from > that cmd) ( similar for 443) > Doesn't this imply that the OP was running Skype as root? signature.asc Description: This is a digitally signed message part
Re: Strange problem with skype on RELENG_6 KERNEL since the end of may.
Tom Evans wrote: On Tue, 2007-06-19 at 23:40 +1000, Norberto Meijome wrote: On Thu, 14 Jun 2007 09:29:09 -0500 "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: A RELENG_6 kernel from May 21 works fine with skype but boot a newer kernel and skype seems to be blocking port 80. Apache logs show nothing. I can find no logs errors anywhere but a telnet to port 80 answers with what would seem to be binary chars. I close skype and all is back to normal. I had originally thought that it had to do with the new xorg installation but it seems to be something in the kernel. The configurations were the same, basically GENERIC with all the pf stuff. Hi, Skype has an option to listen on tcp/80 and tcp/443 for incoming connections, because it assumes somehow that firewalls will be configured to allow that traffic in (some Windowze world assumption, i guess). In the tools menu, go to Options, Advanced, untick the option that reads "Use port (sic) 80 and 443 as alternatives for incoming connections". Apply, exit skype, restart it. confirm with sockstat -4 | grep skype | grep \*:80 that skype is NOT listening on port 80 (you shouldn't see any output back from that cmd) ( similar for 443) Doesn't this imply that the OP was running Skype as root? Yes if the sysctl's below net.inet.ip.portrange all have there default values. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Video Turns Software Leads Into Buyers
Greetings! You have a state-of-the-art software application, but do your customers know it? Bridge the gap between your latest software solutions and the end user with video. PixelFish is a video production company that excels at producing high-quality videos that sell. Our talented and accomplished crew starts with a focused and innovative script to match your messaging needs. We then hand off the approved script to our team of videographers who coordinate each and every detail to get the best footage. Experienced and savvy editors complete the final stages to produce the marketing or educational video that keeps you at the cutting edge of software development. I have embedded a few samples of our work to the right. Click on the videos to see what we can do. We digitize our videos for optimal distribution over the web, via e-mail, CD-ROM and other popular media platforms. We also provide the right tools for measuring the positive impact of each video investment instantly and around the clock. Whether you are looking to train your customers on your latest application, promote your software, or simply create a software demonstration guide, PixelFish is your one-stop-shop for affordable video solutions for all types of purposes. Call us today to begin the planning process of your video or to gather more information. You can reach us at 800.503.3020 or on our website at www.pixelfish.com. Wed love to work with you to help turn your software leads into sales. Sincerely, Justin Love PixelFish, Inc. 800.503.3020 x7109 mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] http://www.pixelfish.com";>http://www.pixelfish.com http://stream01.pixelfish.com/certiport30/meter_vm.php";>Certiport http://stream01.pixelfish.com/quadrant/meter_vm.php";>Quadrant http://stream01.pixelfish.com/investools/meter_vm.php";>InvesTools Unsubscribe to safely remove yourself from this email list, please send email to [EMAIL PROTECTED] Powered by Pixelfish http://www.pixelfish.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Video Turns Software Leads Into Buyers
Greetings! You have a state-of-the-art software application, but do your customers know it? Bridge the gap between your latest software solutions and the end user with video. PixelFish is a video production company that excels at producing high-quality videos that sell. Our talented and accomplished crew starts with a focused and innovative script to match your messaging needs. We then hand off the approved script to our team of videographers who coordinate each and every detail to get the best footage. Experienced and savvy editors complete the final stages to produce the marketing or educational video that keeps you at the cutting edge of software development. I have embedded a few samples of our work to the right. Click on the videos to see what we can do. We digitize our videos for optimal distribution over the web, via e-mail, CD-ROM and other popular media platforms. We also provide the right tools for measuring the positive impact of each video investment instantly and around the clock. Whether you are looking to train your customers on your latest application, promote your software, or simply create a software demonstration guide, PixelFish is your one-stop-shop for affordable video solutions for all types of purposes. Call us today to begin the planning process of your video or to gather more information. You can reach us at 800.503.3020 or on our website at www.pixelfish.com. Wed love to work with you to help turn your software leads into sales. Sincerely, Justin Love PixelFish, Inc. 800.503.3020 x7109 mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] http://www.pixelfish.com";>http://www.pixelfish.com http://stream01.pixelfish.com/certiport30/meter_vm.php";>Certiport http://stream01.pixelfish.com/quadrant/meter_vm.php";>Quadrant http://stream01.pixelfish.com/investools/meter_vm.php";>InvesTools Unsubscribe to safely remove yourself from this email list, please send email to [EMAIL PROTECTED] Powered by Pixelfish http://www.pixelfish.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
unionfs6-p19-20070504 and devfs on a very recent 6.2-STABLE
Hello, I'm using unionfs on a recently (approx. 5 days ago) cvsup'ed 6.2-STABLE with the http://people.freebsd.org/~daichi/unionfs/unionfs6-p19-20070504.diff patch and have a problem with devfs mounted over unionfs. I made a testsetup in March where I used a 6.2-STABLE at that time without additional patches. On the testsystem it works fine. On the new system, devfs does not work, a devfs mounted below some unionfs mount point can be seen in df and mount, but no device nodes appear in /dev/. Let me explain in more detail: I mount a template of a jail using unionfs: /sbin/mount -t unionfs -o noatime,below /vserv/template/stage2 /vserv/somehost Then I mount the necessary devfs: mount_devfs devfs /vserv/somehost/dev In parallel, I mount a devfs somewhere else: mount_devfs devfs /mnt Both mounts show up: # mount /dev/ad4s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad4s1f on /vserv (ufs, local, soft-updates) /dev/ad4s1d on /usr (ufs, local, soft-updates) /dev/ad4s1e on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) linprocfs on /usr/compat/linux/proc (linprocfs, local) :/vserv/template/stage2 on /vserv/somehost (unionfs, local, noatime) devfs on /vserv/ns2.vistec.net/dev (devfs, local) devfs on /mnt (devfs, local) But: no files in the devfs below the unionfs mount point, while on the other point, plenty of files appear: # ls -la /vserv/ns2.vistec.net/dev/ | wc -l 3 # ls -la /mnt/ | wc -l 100 Is this some bug with devfs and the recent unionfs patch ? -- [EMAIL PROTECTED] +49 171 310137213 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unionfs6-p19-20070504 and devfs on a very recent 6.2-STABLE
Hi! > I'm using unionfs on a recently (approx. 5 days ago) cvsup'ed > 6.2-STABLE with the > > http://people.freebsd.org/~daichi/unionfs/unionfs6-p19-20070504.diff > > patch and have a problem with devfs mounted over unionfs. Going back to the most recent stable without unionfs6-p19-20070504 works. -- [EMAIL PROTECTED] +49 171 310137213 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is read-write nullfs safe?
Rong-en Fan wrote: > I'm running 6.2-RELEASE, and I am wondering > if using nullfs w/ rw is safe in a production environment? > My impression is that ro nullfs is ok, but not rw. > Is this still the case? nullfs is quite stable from my impression at least for my workload. We use it for some heavily loaded package building environment. The old unionfs implementation may have some problems. Cheers, ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange problem with skype on RELENG_6 KERNEL since the end of may.
On Tue, 19 Jun 2007 17:26:59 +0100
Tom Evans <[EMAIL PROTECTED]> wrote:
> Doesn't this imply that the OP was running Skype as root?
touche.
but from what OP described, that's what was happening... :D ouch :D
_
{Beto|Norberto|Numard} Meijome
"Any society that would give up a little liberty to gain a little security will
deserve neither and lose both."
Benjamin Franklin
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
how much beer do I need to get this patch applied?
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/88486 This patch was supplied 2 years ago now. It doesn't change current/ expected behavior but does allow those of us with many, many systems to not get useless e-mail. It's not even my patch! I would simply like to see this done... -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
