2
Assume disc blocks are 8K bytes and that disc addresses are 32 bits: •
from the information in the i-node? – What size can be directly addressed 
– What size of file requires a double indirect block?
– What is the largest possible file?

Source: http://ti.uni-due.de/ti/en/education/teaching/ss06/dv2/ex2_sol.pdf

Can somebody help me solve these kinds of questions?

unj2
  • 52,135
  • 87
  • 247
  • 375
  • possible duplicate of [Maximum file size given a particular inode structure?](http://stackoverflow.com/questions/2742163/maximum-file-size-given-a-particular-inode-structure) (found via "inode maximum file size block size") –  Dec 08 '10 at 01:54

3 Answers3

8

I used to be a file systems developer some years ago.

Using the material provided in the link ...

Any file offset in the range of 0 .. (80 kB - 1) inclusive can be accessed using the direct blocks stored in the inode. This is derived from the fact that there are ten 8 kB blocks.

As a disc block is 8 kB (8192 bytes), and disc addresses are 32 bits (4 bytes), each disc block can hold up to 2048 (8192 / 4) disc address entries. This means that the singly indirect block can reference up to 2048 * 8 kB bytes of file data (16 MB). Extending this, we find that a doubly indirect block can reference up to 2048 * 2048 * 8kB of file data (32 GB).

Up to 80 kB of file data can be accessed using the direct blocks. This translates into file offsets 0 through (80 kB - 1) inclusive.

Up to 16 MB of file data can be accessed using the singly indirect block stored in the inode. This translates into files offsets 80 kB through (16 MB + 80 kB - 1) inclusive.

Up to 32 GB of file data can be accessed using the doubly indirect block stored in the inode. This translates into file offsets (16 MB + 80 kB) through (32 GB + 16 MB + 80 kB - 1) inclusive.

Up to 64 TB of file data can be accessed using the triply indirect block stored in the inode. This translates into file offsets (32 GB + 16 MB + 80 kB) through to (64 TB + 32 GB + 16 MB + 80 kB - 1)inclusive.

Consequently the theoretical maximum size of a file is 64 TB + 32 GB + 16 MB + 80 kB.

The practical maximum size is a different matter. It can be limited by any one or combination of the following:

  1. Size of the disc.
  2. Size of partition.
  3. Inherent file system meta-data limitations. Some file systems are not designed to address beyond size X, even though X is less than the theoretical maximum file size.
  4. Related to item 3, yet deserving of its own is the number of bits reserved in the inode to store the size of the file. If memory serves, the original Ext2 limited the file size to 32 bits. This created a (2 GB - 1) limit for the file size.

Some of the practical limitations can be "worked around" if the file system supports sparse files (the one described in the link probably does as it uses indirect blocks). Sparse files allow situations such as a 2 TB file "fitting" on a 1 GB disc without using 2 TB of actual disk space. Incidentally, this is one of the reasons why an inode may often contain information about the number of blocks actually used by the file.

Hope that helps.

Sparky
  • 13,505
  • 4
  • 26
  • 27
1

I'm not familiar with unix systems but on page 18 /19 of the document you gave in your question the answer seems to be given. What is your problem?

Assume disc blocks are 8K bytes and that disc addresses are 32 bits: – What size can be directly addressed from the information in the i-node? – What size of file requires a double indirect block? – What is the largest possible file? Answer: a) Disk blocks= 8K bytes i-node => 10 disk block adress 8K*10= 80K can be accessed directly

JerryK
  • 82
  • 1
  • 8
  • You ask: "I dont understand how can one 8K block can address 2048 kb?" I think thats the wrong question. Rather why not ask why is it the unix system only allows 11bits (11bits create 2048 'different numbers or addresses) Then for single indirect addressing each of these 2048 addresses points to a block of size 8k and so the biggest file addressable is 2048x8k = 16M – JerryK Dec 09 '10 at 02:15
  • @Sparky. Well done. Very well explained. If my rep was just a little more i would be up voting you contrib. Only one niggle remains. why on page18 of the source doc do they present the 2048 as 2^3 x 2^8? – JerryK Dec 10 '10 at 01:16
1

The answer is actually given in the file, one would need to read over the source material, those slides were based on.

Basically:

Assume disc blocks are 8K bytes and that disc addresses are 32 bits:
1)What size can be directly addressed from the information in the i-node?
2)What size of file requires a double indirect block? 
3)What is the largest possible file?

On the slide before the answer, the structure of a Unix File is explained, it very clearly states 10 block address.

So obviously 8K * 10 = 80k bytes.

Without the lecture itself I won't be able to quote your own material, you can research that yourself, but i will continue.

I do know that 2^8 is 256 and 2^3 is 8 so 256*8 = 2048KB which is 2MB * 8 = 16384 * 1024 = 16777216 = 16MB

Double Indirect is the address of the indirect ( twice ) so just 2048 * 2048 which is 4GB * 8 * 1024 = 34359738368 = 32GB

Triple indirect is the address of the indirect in double indirect address so

32GB * 2048 ( 2MB ) = 70368744177664 = 64TB

Yes, I looked at the answer and came to some conclusions, without the source material I can't anything else the lecture isn't posted.

Security Hound
  • 2,577
  • 3
  • 25
  • 42
  • I dont understand how can one 8K block can address 2048 kb? – unj2 Dec 08 '10 at 21:28
  • You can either post your lecture notes or you can read them yourself I did the best to explain it. I will point out that 8k block is not addressing 2048kb its a 80,000 address block that is addressing 2048KB because of the structure for unix ( reference your class notes ). – Security Hound Dec 09 '10 at 15:18
  • I should add that you could in theory multiply stuff by 8,000 ( instead of 1024 and/or 8 ) because 1024 is exactly but on a disk ~1000KB = 1MB because of various principles. Your solution file I do believe actually uses 8K – Security Hound Dec 09 '10 at 15:24