Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c
From: Jeff Roberson (jroberson_at_chesapeake.net)
Date: 06/19/03
- Previous message: Garance A Drosihn: "Re: marking normal sleep identifiers as such."
- In reply to: The Hermit Hacker: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c"
- Next in thread: Terry Lambert: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 19 Jun 2003 02:40:19 -0400 (EDT) To: The Hermit Hacker <scrappy@hub.org>
On Wed, 18 Jun 2003, The Hermit Hacker wrote:
> On Wed, 18 Jun 2003, Sheldon Hearn wrote:
>
> > On (2003/06/18 13:53), Poul-Henning Kamp wrote:
> >
> > > With that said, I will also add, that I will take an incredibly
> > > dim view of anybody who tries to add more gunk in this area, and
> > > that I am perfectly willing to derail unionfs and nullfs (or pretty
> > > much anything else on the list above) if that is what it takes to
> > > clean up the buffer cache.
> >
> > Makes sense. After all, these filesystems are only just now recovering
> > from "we can fix these later" breakage introduced years ago. What's a
> > few more years without 'em? :-)
>
> 'K, this kinda hurts ... there are a growing # of us that are actually
> using unionfs and nullfs on production systems ... not small servers, but
> several thousand processes with over 100 union mounts ... other then the
> vnode leak stuff that David has been investigating, I've yet to see
> anything that I would considering warranting the 'DO NOT USE / CAVEAT
> EMPTOR' that is in the man pages ... :(
>
Yes, I also have great issue with breaking the stacking layers. Fixing
the buffer cache should have no impact on them if this is done correctly.
Lets please not try to break any more functionality.
Cheers,
Jeff
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Garance A Drosihn: "Re: marking normal sleep identifiers as such."
- In reply to: The Hermit Hacker: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c"
- Next in thread: Terry Lambert: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- Re: [patch 01/26] mount options: add documentation
... Several filesystems which use mount options, ... Table displaying status of
all in-kernel filesystems: ... unionfs none ... The unionfs ->remount
code supports branch-management options which can ... (Linux-Kernel) - Re: Your CVS fix 1.109 to union_vnops.c
... >> for nullfs and not for unionfs, ... upper layer file
... (freebsd-current) - Re: Your CVS fix 1.109 to union_vnops.c
... > for nullfs and not for unionfs, ... 'nullfs' has only one underlying
file system, ... The latter is the inode number in case of UFS. ... With 'unionfs'
you can have underlying files from two different layers ... (freebsd-current) - Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c
... > using unionfs and nullfs on production systems ... ... (freebsd-arch) - Re: [ANN] 8-CURRENT, RELENG_7 and RELENG_6 have gotten latest ?unionfs improvements
... The union mount option is completely separate ... more broken than unionfs.
... NULLFS and UMAPFS). ... of an arbitrary existing directory tree, ...
(freebsd-current)