mirror of https://gitee.com/openkylin/linux.git
GFS2: Add explanation of extended attr on-disk format
Some useful info regarding the on-disk representation of GFS2 extended attributes. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
This commit is contained in:
parent
d34843d0c4
commit
b6ed2e03df
|
@ -333,6 +333,28 @@ struct gfs2_leaf {
|
|||
|
||||
/*
|
||||
* Extended attribute header format
|
||||
*
|
||||
* This works in a similar way to dirents. There is a fixed size header
|
||||
* followed by a variable length section made up of the name and the
|
||||
* associated data. In the case of a "stuffed" entry, the value is
|
||||
* inline directly after the name, the ea_num_ptrs entry will be
|
||||
* zero in that case. For non-"stuffed" entries, there will be
|
||||
* a set of pointers (aligned to 8 byte boundary) to the block(s)
|
||||
* containing the value.
|
||||
*
|
||||
* The blocks containing the values and the blocks containing the
|
||||
* extended attribute headers themselves all start with the common
|
||||
* metadata header. Each inode, if it has extended attributes, will
|
||||
* have either a single block containing the extended attribute headers
|
||||
* or a single indirect block pointing to blocks containing the
|
||||
* extended attribure headers.
|
||||
*
|
||||
* The maximim size of the data part of an extended attribute is 64k
|
||||
* so the number of blocks required depends upon block size. Since the
|
||||
* block size also determines the number of pointers in an indirect
|
||||
* block, its a fairly complicated calculation to work out the maximum
|
||||
* number of blocks that an inode may have relating to extended attributes.
|
||||
*
|
||||
*/
|
||||
|
||||
#define GFS2_EA_MAX_NAME_LEN 255
|
||||
|
|
Loading…
Reference in New Issue