1. 27 2月, 2010 7 次提交
    • J
      ocfs2: Set the xattr name+value pair in one place · 69a3e539
      Joel Becker 提交于
      We create two new functions on ocfs2_xa_loc, ocfs2_xa_prepare_entry()
      and ocfs2_xa_store_inline_value().
      
      ocfs2_xa_prepare_entry() makes sure that the xl_entry field of
      ocfs2_xa_loc is ready to receive an xattr.  The entry will point to an
      appropriately sized name+value region in storage.  If an existing entry
      can be reused, it will be.  If no entry already exists, it will be
      allocated.  If there isn't space to allocate it, -ENOSPC will be
      returned.
      
      ocfs2_xa_store_inline_value() stores the data that goes into the 'value'
      part of the name+value pair.  For values that don't fit directly, this
      stores the value tree root.
      
      A number of operations are added to ocfs2_xa_loc_operations to support
      these functions.  This reflects the disparate behaviors of xattr blocks
      and buckets.
      
      With these functions, the overlapping ocfs2_xattr_set_entry_local() and
      ocfs2_xattr_set_entry_normal() can be replaced with a single call
      scheme.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      69a3e539
    • J
      ocfs2: Wrap calculation of name+value pair size. · 199799a3
      Joel Becker 提交于
      An ocfs2 xattr entry stores the text name and value as a pair in the
      storage area.  Obviously names and values can be variable-sized.  If a
      value is too large for the entry storage, a tree root is stored instead.
      The name+value pair is also padded.
      
      Because of this, there are a million places in the code that do:
      
      	if (needs_external_tree(value_size)
      		namevalue_size = pad(name_size) + tree_root_size;
      	else
      		namevalue_size = pad(name_size) + pad(value_size);
      
      Let's create some convenience functions to make the code more readable.
      There are three forms.  The first takes the raw sizes.  The second takes
      an ocfs2_xattr_info structure.  The third takes an existing
      ocfs2_xattr_entry.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      199799a3
    • J
      ocfs2: Add a name_len field to ocfs2_xattr_info. · 18853b95
      Joel Becker 提交于
      Rather than calculating strlen all over the place, let's store the
      name length directly on ocfs2_xattr_info.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      18853b95
    • J
      ocfs2: Prefix the member fields of struct ocfs2_xattr_info. · 6b240ff6
      Joel Becker 提交于
      struct ocfs2_xattr_info is a useful structure describing an xattr
      you'd like to set.  Let's put prefixes on the member fields so it's
      easier to read and use.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      6b240ff6
    • J
      ocfs2: Remove xattrs via ocfs2_xa_loc · bde1e540
      Joel Becker 提交于
      Add ocfs2_xa_remove_entry(), which will remove an xattr entry from its
      storage via the ocfs2_xa_loc descriptor.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      bde1e540
    • J
      ocfs2: Introduce ocfs2_xa_loc · 11179f2c
      Joel Becker 提交于
      The ocfs2 extended attribute (xattr) code is very flexible.  It can
      store xattrs in the inode itself, in an external block, or in a tree of
      data structures.  This allows the number of xattrs to be bounded by the
      filesystem size.
      
      However, the code that manages each possible storage location is
      different.  Maintaining the ocfs2 xattr code requires changing each hunk
      separately.
      
      This patch is the start of a series introducing the ocfs2_xa_loc
      structure.  This structure wraps the on-disk details of an xattr
      entry.  The goal is that the generic xattr routines can use
      ocfs2_xa_loc without knowing the underlying storage location.
      
      This first pass merely implements the basic structure, initializing it,
      and wiping the name+value pair of the entry.
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      11179f2c
    • T
      ocfs2: add extent block stealing for ocfs2 v5 · b89c5428
      Tiger Yang 提交于
      This patch add extent block (metadata) stealing mechanism for
      extent allocation. This mechanism is same as the inode stealing.
      if no room in slot specific extent_alloc, we will try to
      allocate extent block from the next slot.
      Signed-off-by: NTiger Yang <tiger.yang@oracle.com>
      Acked-by: NTao Ma <tao.ma@oracle.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      b89c5428
  2. 24 12月, 2009 1 次提交
  3. 17 12月, 2009 1 次提交
    • C
      sanitize xattr handler prototypes · 431547b3
      Christoph Hellwig 提交于
      Add a flags argument to struct xattr_handler and pass it to all xattr
      handler methods.  This allows using the same methods for multiple
      handlers, e.g. for the ACL methods which perform exactly the same action
      for the access and default ACLs, just using a different underlying
      attribute.  With a little more groundwork it'll also allow sharing the
      methods for the regular user/trusted/secure handlers in extN, ocfs2 and
      jffs2 like it's already done for xfs in this patch.
      
      Also change the inode argument to the handlers to a dentry to allow
      using the handlers mechnism for filesystems that require it later,
      e.g. cifs.
      
      [with GFS2 bits updated by Steven Whitehouse <swhiteho@redhat.com>]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Acked-by: NJoel Becker <joel.becker@oracle.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      431547b3
  4. 29 10月, 2009 1 次提交
  5. 23 9月, 2009 11 次提交
  6. 05 9月, 2009 7 次提交
  7. 21 7月, 2009 1 次提交
  8. 06 5月, 2009 1 次提交
    • T
      ocfs2: Don't printk the error when listing too many xattrs. · a46fa684
      Tao Ma 提交于
      Currently the kernel defines XATTR_LIST_MAX as 65536
      in include/linux/limits.h.  This is the largest buffer that is used for
      listing xattrs.
      
      But with ocfs2 xattr tree, we actually have no limit for the number.  If
      filesystem has more names than can fit in the buffer, the kernel
      logs will be pollluted with something like this when listing:
      
      (27738,0):ocfs2_iterate_xattr_buckets:3158 ERROR: status = -34
      (27738,0):ocfs2_xattr_tree_list_index_block:3264 ERROR: status = -34
      
      So don't print "ERROR" message as this is not an ocfs2 error.
      Signed-off-by: NTao Ma <tao.ma@oracle.com>
      Signed-off-by: NJoel Becker <joel.becker@oracle.com>
      a46fa684
  9. 04 4月, 2009 1 次提交
    • M
      ocfs2: Add a name indexed b-tree to directory inodes · 9b7895ef
      Mark Fasheh 提交于
      This patch makes use of Ocfs2's flexible btree code to add an additional
      tree to directory inodes. The new tree stores an array of small,
      fixed-length records in each leaf block. Each record stores a hash value,
      and pointer to a block in the traditional (unindexed) directory tree where a
      dirent with the given name hash resides. Lookup exclusively uses this tree
      to find dirents, thus providing us with constant time name lookups.
      
      Some of the hashing code was copied from ext3. Unfortunately, it has lots of
      unfixed checkpatch errors. I left that as-is so that tracking changes would
      be easier.
      Signed-off-by: NMark Fasheh <mfasheh@suse.com>
      Acked-by: NJoel Becker <joel.becker@oracle.com>
      9b7895ef
  10. 13 3月, 2009 2 次提交
  11. 27 2月, 2009 3 次提交
  12. 03 2月, 2009 1 次提交
    • T
      ocfs2: Access the xattr bucket only before modifying it. · 554e7f9e
      Tao Ma 提交于
      In ocfs2_xattr_value_truncate, we may call b-tree codes which will
      extend the journal transaction. It has a potential problem that it
      may let the already-accessed-but-not-dirtied buffers gone. So we'd
      better access the bucket after we call ocfs2_xattr_value_truncate.
      And as for the root buffer for the xattr value, b-tree code will
      acess and dirty it, so we don't need to worry about it.
      Signed-off-by: NTao Ma <tao.ma@oracle.com>
      Signed-off-by: NMark Fasheh <mfasheh@suse.com>
      554e7f9e
  13. 06 1月, 2009 3 次提交