reading data disk blocks of a file

reading data disk blocks of a file

[Pallavi]

hello,
what are the internal operations to real a file..I understand that the
semantic layer
converts a filename into a key but where in the source code is the
implementation of this semantic layer found and how does it exactly
convert the name to a key?

A key will lead me to a node. That node had range of keys each
corresponding to an item.The key I get will point to an item. Let's
say the item contains data, but given that the item size is limited
the data may be spread  across items nodes. How are all the data
blocks where data from particular file is stored identified.
Basically i want to know how are all the data blocks of a file are
accessed and read?

Re: reading data disk blocks of a file

[Vladimir Saveliev]

Hello

On Wed, 2004-12-22 at 18:38, Pallavi wrote:
> hello,
> what are the internal operations to real a file..I understand that the
> semantic layer
> converts a filename into a key but where in the source code is the
> implementation of this semantic layer found and how does it exactly
> convert the name to a key?
> 
Having key of directory and name in it to look for you compose key of
directory entry and search with that key through filesystem tree. If
entry is found - you get key of file found entry points to.


> A key will lead me to a node. That node had range of keys each
> corresponding to an item.The key I get will point to an item. Let's
> say the item contains data, but given that the item size is limited
> the data may be spread  across items nodes.

If file data are spread across several nodes - there will be several
items. Keys of those items are different.

>  How are all the data
> blocks where data from particular file is stored identified.
> Basically i want to know how are all the data blocks of a file are
> accessed and read?
> 

reiserfs may store file data either in data blocks or in formatted
nodes.
To read data stored in data blocks you have to find number of block
where data you need are stored at. reiserfs stores those block numbers
in items which can be found by key. Once you have a number of block -
you have to read it to reach file data.

When file data stored in formatted node - you also make a key of
position in a file and search through the tree. Found item contains data
you looked for.

Re: reading data disk blocks of a file

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pallavi wrote:
> hello,
> what are the internal operations to real a file..I understand that the
> semantic layer
> converts a filename into a key but where in the source code is the
> implementation of this semantic layer found and how does it exactly
> convert the name to a key?
> 
> A key will lead me to a node. That node had range of keys each
> corresponding to an item.The key I get will point to an item. Let's
> say the item contains data, but given that the item size is limited
> the data may be spread  across items nodes. How are all the data
> blocks where data from particular file is stored identified.
> Basically i want to know how are all the data blocks of a file are
> accessed and read?
> 

This link might help your understanding of the layout:
http://web.archive.org/web/20021013181038/http://www.namesys.com/content_table.html#6_1

Unfortunately, it doesn't cover version 2 keys, which are essentially
the same as version 1 keys, but rather than splitting offset/type as
32:32 bits, they're split 60:4 to allow for much larger file offsets.

To figure out how a name is looked up, your best bet is to start at
reiserfs_lookup (namei.c) which quickly dives into the tree parsing
code, but at a high enough level that you should be able to follow it down.

Files in a reiserfs filesystem (assuming indirect items only for now)
are stored as a list of data block numbers inside an item. The key
associated with the item includes the starting file offset for the
blocks contained in that item. So, for example, you may see the
following (using v2 stat data, which is assumed for any new fs):

For the sake of illustration, I've chosen a file offset that is deep
enough into the file to ensure that it will be in a different leaf node.

leaf_node {
 [possibly other item heads]
  item_head {
    ih_key {
      k_dir_id = 12345;
      k_object_id = 12346;
      k_offset = 0
      k_type = TYPE_STAT_DATA;
    }
    [size of item body, etc]
  }
 [other item heads and item bodies, including the first
  batch of indirect block pointers]
  item body: stat_data {
    [size, permissions, etc]
  }
 [possibly other item bodies]
}

another leaf_node {
  item_head {
    ih_key {
      k_dir_id = 12345; (same as stat data)
      k_object_id = 12346 (same as stat data)
      k_offset = 4194304; (position in file, in bytes, 4MB)
      k_type = TYPE_INDIRECT;
    }
    [size of item body, etc]
  }
[...]
 item body: [100000 100001 100002 100003 100004 100005 100006 ...]
            (array of block numbers)
}


The array of block numbers contain the location of the file data.

Occasionally, when the file is small enough, the last chunk of data may
be stored inside the leaf node itself as item data. These are called
"tails" and are used to conserve disk space when small files are used.

In userspace, it's possible to discover what blocks are used by a
particular file by using the FIBMAP ioctl on the file.

Also, if you'd like to see the disk format more visually, try using
"debugreiserfs -D <device>" to dump the fs metadata in a table format.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBya63LPWxlyuTD7IRAsazAJ9VxJpoOIUkxMeYnhrQZO5a8zC2QACeLpFp
/u2zfOdohJ6XKamRSvkzFDU=
=J4dj
-----END PGP SIGNATURE-----