.\" This manpage has been automatically generated by docbook2man
.\" from a DocBook document. This tool can be found at:
.\"
.\" Please send any bug reports, improvements, comments, patches,
.\" etc. to Steve Cheng .
.TH "EXT2_BLOCK_TO_PATH" "9" "09 October 2005" "" ""
.SH NAME
ext2_block_to_path \- parse the block number into array of offsets
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
int ext2_block_to_path (struct inode * \fIinode\fB, long \fIi_block\fB, int \fIoffsets[4]\fB, int * \fIboundary\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIinode\fB\fR
inode in question (we are only interested in its superblock)
.TP
\fB\fIi_block\fB\fR
block number to be parsed
.TP
\fB\fIoffsets[4]\fB\fR
array to store the offsets in
.TP
\fB\fIboundary\fB\fR
set this non-zero if the referred-to block is likely to be
followed (on disk) by an indirect block.
To store the locations of file's data ext2 uses a data structure common
for UNIX filesystems - tree of pointers anchored in the inode, with
data blocks at leaves and indirect blocks in intermediate nodes.
This function translates the block number into path in that tree -
return value is the path length and \fIoffsets\fR[n] is the offset of
pointer to (n+1)th node in the nth one. If \fIblock\fR is out of range
(negative or too large) warning is printed and zero returned.
.SH "NOTE"
.PP
function doesn't find node addresses, so no IO is needed. All
we need to know is the capacity of indirect blocks (taken from the
inode->i_sb).