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

  • Next message: Terry Lambert: "Re: Meta: explain what where when? (was Re: userland access todevicesis moving!)" 
    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"

  • Next message: Terry Lambert: "Re: Meta: explain what where when? (was Re: userland access todevicesis moving!)"

    Relevant Pages

    • Re: [RFC 0/7] [RFC] cramfs: fake write support
      ... the same idea in multiple filesystems. ... implementation of union mounts. ... Unionfs is complex and for many embedded systems with constrained resources Unionfs adds a lot of extra overhead. ... With Unionfs a page write causes the entire file to be copied up to the r/w tmpfs and locked into the page cache causing unnecessary RAM overhead. ...
      (Linux-Kernel)
    • 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)