xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, for-next, updated. v3.8-rc1-3

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, for-next, updated. v3.8-rc1-37-g1e82379
From: xfs@xxxxxxxxxxx
Date: Thu, 14 Feb 2013 17:37:08 -0600 (CST)
Delivered-to: xfs@xxxxxxxxxxx
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-next has been updated
  1e82379 xfs: xfs_bmap_add_attrfork_local is too generic
      from  fa5566e4ffb918131a054413eb42075a77a41413 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 1e82379b018ceed0f0912327c60d73107dacbcb3
Author: Dave Chinner <dchinner@xxxxxxxxxx>
Date:   Mon Feb 11 15:58:13 2013 +1100

    xfs: xfs_bmap_add_attrfork_local is too generic
    
    When we are converting local data to an extent format as a result of
    adding an attribute, the type of data contained in the local fork
    determines the behaviour that needs to occur.
    
    xfs_bmap_add_attrfork_local() already handles the directory data
    case specially by using S_ISDIR() and calling out to
    xfs_dir2_sf_to_block(), but with verifiers we now need to handle
    each different type of metadata specially and different metadata
    formats require different verifiers (and eventually block header
    initialisation).
    
    There is only a single place that we add and attribute fork to
    the inode, but that is in the attribute code and it knows nothing
    about the specific contents of the data fork. It is only the case of
    local data that is the issue here, so adding code to hadnle this
    case in the attribute specific code is wrong. Hence we are really
    stuck trying to detect the data fork contents in
    xfs_bmap_add_attrfork_local() and performing the correct callout
    there.
    
    Luckily the current cases can be determined by S_IS* macros, and we
    can push the work off to data specific callouts, but each of those
    callouts does a lot of work in common with
    xfs_bmap_local_to_extents(). The only reason that this fails for
    symlinks right now is is that xfs_bmap_local_to_extents() assumes
    the data fork contains extent data, and so attaches a a bmap extent
    data verifier to the buffer and simply copies the data fork
    information straight into it.
    
    To fix this, allow us to pass a "formatting" callback into
    xfs_bmap_local_to_extents() which is responsible for setting the
    buffer type, initialising it and copying the data fork contents over
    to the new buffer. This allows callers to specify how they want to
    format the new buffer (which is necessary for the upcoming CRC
    enabled metadata blocks) and hence make xfs_bmap_local_to_extents()
    useful for any type of data fork content.
    
    Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
    Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
    Signed-off-by: Ben Myers <bpm@xxxxxxx>

-----------------------------------------------------------------------

Summary of changes:
 fs/xfs/xfs_bmap.c | 114 ++++++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 93 insertions(+), 21 deletions(-)


hooks/post-receive
-- 
XFS development tree

<Prev in Thread] Current Thread [Next in Thread>
  • [XFS updates] XFS development tree branch, for-next, updated. v3.8-rc1-37-g1e82379, xfs <=