1. 08 Sep, 2009 1 commit
    • Steven Whitehouse's avatar
      GFS2: Be extra careful about deallocating inodes · acf7e244
      Steven Whitehouse authored
      
      
      There is a potential race in the inode deallocation code if two
      nodes try to deallocate the same inode at the same time. Most of
      the issue is solved by the iopen locking. There is still a small
      window which is not covered by the iopen lock. This patches fixes
      that and also makes the deallocation code more robust in the face of
      any errors in the rgrp bitmaps, or erroneous iopen callbacks from
      other nodes.
      
      This does introduce one extra disk read, but that is generally not
      an issue since its the same block that must be written to later
      in the deallocation process. The total disk accesses therefore stay
      the same,
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      acf7e244
  2. 27 Aug, 2009 1 commit
    • Steven Whitehouse's avatar
      GFS2: Remove no_formal_ino generating code · 8d8291ae
      Steven Whitehouse authored
      
      
      The inum structure used throughout GFS2 has two fields. One
      no_addr is the disk block number of the inode in question and
      is used everywhere as the inode number. The other, no_formal_ino,
      is used only as the generation number for NFS.
      
      Historically the no_formal_ino field was set using a complicated
      system of one global and one per-node file containing inode numbers
      in order to ensure that each no_formal_ino was unique. Also this
      code made no provision for what would happen when eventually the
      (64 bit) numbers ran out. Now I know that is pretty unlikely to
      happen given the large space of numbers, but it is possible
      nevertheless.
      
      The only guarantee required for no_formal_ino is that, for any
      single inode, the same number doesn't get reused too quickly.
      
      We already have a generation number which is kept in the inode
      and initialised from a counter in the resource group (almost
      no overhead, since we have to touch the resource group anyway
      in order to allocate an inode in the first place). Aside from
      ensuring that we never use the value 0 in the no_formal_ino
      field, we can use that counter directly.
      
      As a result of that change, we lose about 200 lines of code and
      also gain about 10 creates/sec on the postmark benchmark (on
      my test machine).
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      8d8291ae
  3. 26 Aug, 2009 2 commits
    • Steven Whitehouse's avatar
      GFS2: Rename eattr.[ch] as xattr.[ch] · 307cf6e6
      Steven Whitehouse authored
      
      
      Use the more conventional name for the extended attribute
      support code. Update all the places which care.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      307cf6e6
    • Steven Whitehouse's avatar
      GFS2: Clean up of extended attribute support · 40b78a32
      Steven Whitehouse authored
      
      
      This has been on my list for some time. We need to change the way
      in which we handle extended attributes to allow faster file creation
      times (by reducing the number of transactions required) and the
      extended attribute code is the main obstacle to this.
      
      In addition to that, the VFS provides a way to demultiplex the xattr
      calls which we ought to be using, rather than rolling our own. This
      patch changes the GFS2 code to use that VFS feature and as a result
      the code shrinks by a couple of hundred lines or so, and becomes
      easier to read.
      
      I'm planning on doing further clean up work in this area, but this
      patch is a good start. The cleaned up code also uses the more usual
      "xattr" shorthand, I plan to eliminate the use of "eattr" eventually
      and in the mean time it serves as a flag as to which bits of the code
      have been updated.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      40b78a32
  4. 25 Aug, 2009 1 commit
  5. 24 Aug, 2009 2 commits
  6. 18 Aug, 2009 1 commit
    • Wengang Wang's avatar
      GFS2: free disk inode which is deleted by remote node -V2 · 970343cd
      Wengang Wang authored
      this patch is for the same problem that Benjamin Marzinski fixes at commit
      b94a170e
      
      
      
      quotation of the original problem:
      
      ---cut here---
      When a file is deleted from a gfs2 filesystem on one node, a dcache
      entry for it may still exist on other nodes in the cluster. If this
      happens, gfs2 will be unable to free this file on disk. Because of this,
      it's possible to have a gfs2 filesystem with no files on it and no free
      space. With this patch, when a node receives a callback notifying it
      that the file is being deleted on another node, it schedules a new
      workqueue thread to remove the file's dcache entry.
      ---end cut---
      
      after applying Benjamin's patch, I think there is still a case in which the disk
      inode remains even when "no space" is hit. the case is that when running
      d_prune_aliases() against the inode, there are one or more dentries(aliases)
      which have reference count number > 0. in this case the dentries won't be pruned.
      and even later, the reference count becomes to 0, the dentries can still be
      cached in memory. unfortunately, no callback come again, things come back to
      the state before the callback runs. thus the on disk inode remains there until
      in memoryinode is removed for some other reason(shrinking inode cache or unmount
      the volume..).
      
      this patch is to remove those dentries when their reference count becomes to 0 and
      the inode is deleted by remote node. for implementation, gfs2_dentry_delete() is
      added as dentry_operations.d_delete. the function returns true when the inode is
      deleted by remote node. in dput(), gfs2_dentry_delete() is called and since it
      returns true, the dentry is unhashed from dcache and then removed. when all dentries
      are removed, the in memory inode get removed so that the on disk inode is freed.
      Signed-off-by: default avatarWengang Wang <wen.gang.wang@oracle.com>
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      970343cd
  7. 17 Aug, 2009 6 commits
  8. 16 Aug, 2009 2 commits
  9. 14 Aug, 2009 3 commits
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 · 3011c7f0
      Linus Torvalds authored
      * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (38 commits)
        V4L/DVB (12441): siano: read buffer overflow
        V4L/DVB (12440): Use kzalloc for frontend states to have struct dvb_frontend properly
        V4L/DVB (12438): Read buffer overflow
        V4L/DVB (12437): dvb: siano uses/depends on INPUT
        V4L/DVB (12436): stk-webcam: read buffer overflow
        V4L/DVB (12432): em28xx: fix regression in Empire DualTV digital tuning
        V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM default handlers
        V4L/DVB (12428): hdpvr: add missing initialization of current_norm
        V4L/DVB (12424): soc-camera: fix recursive locking in .buf_queue()
        V4L/DVB (12422): media/zr364xx: fix build errors
        V4L/DVB (12405): em28xx-cards: move register 0x13 setting to the proper place
        V4L/DVB (12411): em28xx: Fix artifacts with Silvercrest webcam
        V4L/DVB (12410): em28xx: Move the non-board dependent part to be outside em28xx_pre_card_setup()
        V4L/DVB (12407): em28xx: Adjust Silvercrest xtal frequency
        V4L/DVB (12406): em28xx: fix: don't do image interlacing on webcams
        V4L/DVB (12403): em28xx: properly reports some em2710 chips
        V4L/DVB (12402): em28xx: fix: some em2710 chips use a different vendor ID
        V4L/DVB (12401): m9v011: add vflip/hflip controls to control mirror/upside down
        V4L/DVB (12400): em28xx: Allow changing fps on webcams
        V4L/DVB (12399): mt9v011: Add support for controlling frame rates
        ...
      3011c7f0
    • Steven Whitehouse's avatar
      GFS2: Fix permissions on "recover" file · d7e623da
      Steven Whitehouse authored
      
      
      Although this file is only ever written and not read by
      userspace, it seems that the utils are opening this
      file O_RDWR, so we need to allow that.
      
      Also fixes the whitespace which seemed to be broken.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      Cc: David Teigland <teigland@redhat.com>
      d7e623da
  10. 13 Aug, 2009 21 commits