On Thu, Jan 19, 2006 at 01:55:22AM -0500, Ensel Sharon wrote:
>
>
> On Wed, 18 Jan 2006, Kris Kennaway wrote:
>
> > > hmmm...the cut and paste of that loud warning was from a 6.0-RELEASE man
> > > page ... if I need to be CURRENT to get the updated man page, do I also
> > > need to be CURRENT to
Folks,
I've written up some patches to add dependency checking to config(8). This
will help prevent link errors when compiling kernels with an incomplete
kernel config (things like fxp without miibus; umass without da/scbus, etc.)
The current set of patches add support to config(8) to read, pars
> I just tried to cvsup using cvsup14.us.freebsd.org, and got no
> updates. I know there were changes, so I tried cvsup15.us.freebsd.org, and
> got the desired changes.
>
> Can the cvsup14.us.freebsd.org maintainer check it's health?
>
> (if this isn't the right place, please direct me to the co
On Wed, Jan 18, 2006 at 02:54:04PM -0500, Ensel Sharon wrote:
>
>
> On Wed, 18 Jan 2006, Kris Kennaway wrote:
>
> > > RISK. BEWARE OF DOG. SLIPPERY WHEN WET.
> > >
> > > So, based on this, all of my null_mounts are actually mounted read-only.
> >
> > As others have said, this is no long
Ensel Sharon wrote:
> hmmm...the cut and paste of that loud warning was from a 6.0-RELEASE man
> page ... if I need to be CURRENT to get the updated man page, do I also
> need to be CURRENT to get the safe null_mount code itself ?
>
> Or is 6.0-RELEASE safe ? (re: null_mount)
It probably wouldn'
On Wed, 18 Jan 2006, Kris Kennaway wrote:
> > RISK. BEWARE OF DOG. SLIPPERY WHEN WET.
> >
> > So, based on this, all of my null_mounts are actually mounted read-only.
>
> As others have said, this is no longer applicable to FreeBSD 6.0, and
> it's been removed from HEAD.
hmmm...the cu
On Wed, Jan 18, 2006 at 12:35:29PM -0500, Ensel Sharon wrote:
>
> I am running over 2000 null mounts on a FreeBSD 6.0-RELEASE system. I am
> well aware of the status of the null_mount code, as advertised in the
> mount_nullfs man page:
>
> THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (R
On Wed, 18 Jan 2006, Devon H. O'Dell wrote:
This has been removed from the manpage because it's no longer
accurate. I believe I recall seeing another thread with someone asking
whether it still applied and the answer was, ``No.''
On a test installation I am running > 100 Jails with around 200
2006/1/18, Ensel Sharon <[EMAIL PROTECTED]>:
>
> I am running over 2000 null mounts on a FreeBSD 6.0-RELEASE system. I am
> well aware of the status of the null_mount code, as advertised in the
> mount_nullfs man page:
>
> THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T
> W
From: "Ensel Sharon" <[EMAIL PROTECTED]>
I am running over 2000 null mounts on a FreeBSD 6.0-RELEASE system. I
am
well aware of the status of the null_mount code, as advertised in the
mount_nullfs man page:
I am noticing both system instability and data corruption issues on
disk
following
On Wednesday 18 January 2006 11:31, rookie wrote:
> 2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>:
> > I assume we already know how to propagate priority for mutexes, so
> > once you know how to propagate for RWlocks, it all just works.
>
> As I can see, propagate priority for mutex needs a little
I am running over 2000 null mounts on a FreeBSD 6.0-RELEASE system. I am
well aware of the status of the null_mount code, as advertised in the
mount_nullfs man page:
THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T
WORK)
AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR
2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>:
> I assume we already know how to propagate priority for mutexes, so
> once you know how to propagate for RWlocks, it all just works.
As I can see, propagate priority for mutex needs a little modify to
turnstiles code, that's not a great deal.
> Yes,
On Wed, 18 Jan 2006, rookie wrote:
> 2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>:
> >You will eventually do priority propagation for all of them
> > (A, B, and C) until G's priority is <= the priority of RW1.
> > It doesn't matter if you do one at a time or all of them
> > at once. They all (A,
2006/1/18, Daniel Eischen <[EMAIL PROTECTED]>:
>You will eventually do priority propagation for all of them
> (A, B, and C) until G's priority is <= the priority of RW1.
> It doesn't matter if you do one at a time or all of them
> at once. They all (A, B, C) have to release RW1 before
> G can run
I just tried to cvsup using cvsup14.us.freebsd.org, and got no
updates. I know there were changes, so I tried cvsup15.us.freebsd.org, and
got the desired changes.
Can the cvsup14.us.freebsd.org maintainer check it's health?
(if this isn't the right place, please direct me to the correct place.
T
On Wed, 18 Jan 2006, rookie wrote:
> >> This approach fails beacause you need to propagate priority for any
> blocking
> >> thread for any owners (if needed).
>
> > I'm not sure I follow -- got a simple example?
> > A writer won't be able to get the write lock until _all_ of the
> > current read l
>> This approach fails beacause you need to propagate priority for any
blocking
>> thread for any owners (if needed).
> I'm not sure I follow -- got a simple example?
> A writer won't be able to get the write lock until _all_ of the
> current read lock owners have released the lock. It doesn't
>
18 matches
Mail list logo
