WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Difference between revisions of "Architecture - Punch and Extent Migration Requirements"

From Obsolete Lustre Wiki
Jump to navigationJump to search
(Created page with '{|class="wikitable" style="width:75%;" border="1" cellspacing="0" |+ Punch functionality use cases |- |'''tag'''||'''summary''' |- |checkvers || optionally an inode version can b...')
(No difference)

Revision as of 16:55, 14 January 2010

Punch functionality use cases
tag summary
checkvers optionally an inode version can be passed to the punch call and the punch will only take place if the inode, when locked has the version passed into the call. This enables handling races between modifying inodes and punching data from them.
access there is an ioctl to probe the presence of data in an extent. If any data in the extent has been punched, the ioctl will indicate so. The success case is that all data in the extent is present in the inode
punchextentmap an EA can be installed that points to or contains an extent map that describes the extents that have been punched from the file.
sparseispunched optionally, the recorded extents can be omitted and data is deemed punched if a sparse area is found in the file.
punchmigrate punched data can be migrated to another offset in another inode instead of freed

References

Punch and Extent Migration