Re: NFS client/buffer cache deadlock

From: Marc Olzheim (marcolz_at_stack.nl)
Date: 04/26/05

  • Next message: Marc G. Fournier: "Re: PostgreSQL in FreeBSD jails"
    Date: Tue, 26 Apr 2005 18:43:46 +0200
    To: Brian Fundakowski Feldman <green@freebsd.org>
    
    
    

    [changed cc: from standards@ back to stable@ again.]

    On Tue, Apr 26, 2005 at 12:25:49PM -0400, Brian Fundakowski Feldman wrote:
    > You can assure that this happens in only two ways:
    >
    > 1. Make a complete copy of the data. This is what currently occurs:
    > it gets stuffed into the buffer cache as the write happens.
    > 2. Keep the data around synchronously -- by virtue of the write system
    > call being used synchronously, the thread's VM context is around,
    > and duplication need not occur.

    It seems as though FreeBSD 4.x either used 2) or does something wrong
    indeed. Why would 2) be a problem on FreeBSD 5.x ? Can't the pages
    written from be locked during the write, instead of copied internally ?

    Btw. running the writev program with 20 * 100 MB on UFS on a 512MB
    FreeBSD 6-CURRENT system practicly locks the filesystem down _and_
    causes all processes to be swapped out in favor of the buffer cache.
    'top' however, doesnt' show a rise in BUF usage.

    On FreeBSD 4.x, the system performance as usual during the writev to
    UFS.

    Marc

    
    



  • Next message: Marc G. Fournier: "Re: PostgreSQL in FreeBSD jails"

    Relevant Pages

    • Re: umass(4)/uhci(4) REALLY slow
      ... > On FreeBSD, it really lags. ... This is probably due to something we're not doing in msdosfs. ... probably your msdosfs file system block size. ... None of the lower levels (buffer cache, driver, usb) ...
      (freebsd-current)
    • Re: Increase disk cache and buffers in 5.3?
      ... Set min as being something less than 1/2 of memory ... Luckly, when FreeBSD does get too aggressive in freeing process memory, ... softupdates code by allowing for larger true buffer cache (which is related ... actually did allow for full decoupling of the dirty buffer ...
      (comp.unix.bsd.freebsd.misc)