Skip to content
  • David Chinner's avatar
    [XFS] Don't block pdflush when writing back inodes · a3f74ffb
    David Chinner authored
    
    
    When pdflush is writing back inodes, it can get stuck on inode cluster
    buffers that are currently under I/O. This occurs when we write data to
    multiple inodes in the same inode cluster at the same time.
    
    Effectively, delayed allocation marks the inode dirty during the data
    writeback. Hence if the inode cluster was flushed during the writeback of
    the first inode, the writeback of the second inode will block waiting for
    the inode cluster write to complete before writing it again for the newly
    dirtied inode.
    
    Basically, we want to avoid this from happening so we don't block pdflush
    and slow down all of writeback. Hence we introduce a non-blocking async
    inode flush flag that pdflush uses. If this flag is set, we use
    non-blocking operations (e.g. try locks) whereever we can to avoid
    blocking or extra I/O being issued.
    
    SGI-PV: 970925
    SGI-Modid: xfs-linux-melb:xfs-kern:30501a
    
    Signed-off-by: default avatarDavid Chinner <dgc@sgi.com>
    Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
    a3f74ffb