Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 May 2003 02:37:05 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Tony Maher <tonymaher@optushome.com.au>
Cc:        hackers@freebsd.org
Subject:   Re: Change request for mount_null manpage
Message-ID:  <3ED1E041.8ABA63A2@mindspring.com>
References:  <200305260836.h4Q8abgZ021438@dt.home>

next in thread | previous in thread | raw e-mail | index | archive | help
Tony Maher wrote:
> I have an outstanding PR regarding nullfs
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/28566
> 
> I have now removed /usr/hack nullfs mount and retested startx.
> It all works fine now and I think this PR can now be closed (I'll submit
> PR followup after some more testing).  Also at the time of this PR I stopped
> using nullfs mounts for /home because linux binaries would not work (no PR
> for this).  I have also retested this and everything works fine.

This is because of the named pipe that's used for local
clients; you can set an environment variable to disable
local connections via the named pipe, but be sure to turn
TCP back on, or you won't have any transport at all.  8-).

Making connections via TCP will also prevent Netscape or
Mozilla from eating all your memory for bitmaps, which are
not cached on a window basis, so you basically "leak" them
until you exit the application and it loses its connection
to the X Server, if you use a local connection, which lets
it use the shared memory extension.


> I think the warning in mount_null man page could be toned down.

Probably not a good idea, actually; in general, the reason
the warning should stay is that there's still explicit
cache coherency issues, when you stack a nullfs on top of
an FS, and leave the original FS mount point visible in the
namespace.

FS stacking broke at the time of the VM and buffer cache
unification, and it's only gotten more broken as time went
on, unfortunately.  The VM changes removed the explicit
cache coherency, and replaced it with implicit, losing all
the synchronization points that are still needed when you
stack vnodes with real vmobject_t's; that those changes
were not also made to LFS when they were made to FFS is
pretty much why LFS died.

-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED1E041.8ABA63A2>