struct inode in system has number of blocks & block numbers but no corresponding data offset byte in storage device.HowFilesystem evenWorks without it

I like to know how data is stored in storage. So what I know about a simple file system organizational struct that contains meta data about a file called inode is that it has two member fields

struct inode { blkcnt_t i_blocks; ... loff_t i_size; }

I am assuming that i_blocks is storing block numbers. but how block numbers are numbered? its of type u64

so the question is if this field contains all the block [numbers] then how they are stored u64 means 64 bit and if I represent each 4 bit relate to block numbers then there are 16 blocks per inode. so for example if i_blocks field is 0b1111 1110.... so 1111 is block number 15 and 1110 is block number 14 and so on. so I like to know if number of bits to represent a block number is 4 bit then there can be only 15 blocks in inode so this way I have block numbers and number of blocks but I still could not field the third field which is >>> what is the base address of data block so for example if inode number is 1111 that correspond to some.txt text file with data hello world then where is the offset of hello world data in storage device. This data offset field array of corresponding inode numbers I could not find. Can any one please direct me to the answer in where I can find the data offset byte in storage medium and it has to be in inode struct?

Short sketch for finding inode number ii:

• find the inode block where ii lives: ii/InodesPerBlock; use this as an index into the inodeblocks.
• find the index into this block : ii%InodesPerBlock
• treat (cast) this location as an Inode, and use the first entry in the blocks[] array as the number of the first data block.

For finding a file, this operation must be precededed by a similar operation for finding the directory entry and finding the file's inodeNumber

NOTE: there are a lot of manifest constants, these can all be found in the superblock

• Block size
• filesystem Type
• size of a blockNumber
• number of Inode Blocks (or: number of Inodes)
• size of an inode (or: InodesPerBlock)
• Number of Data Blocks
• Location of the inode containing the root Directory
• Location of the freelist containing the unused block numbers
• State/backup/...
• et cetera ...

NOTE2: this is a simplified scheme. Modern file systems may contain additional structures for efficiency or redundancy. Also: a filesystem may combine more than one physical block into one logical block (e.g. 8*512 -->> 4096)

NOTE3: the superblock is located at blocknumber=0 (at least in UFS) That means that 0 can be used as sentinel value for blocknumbers referring to actual (non-root) blocks. So, the blocknumber arrays inside the inodes can be initialized to all-zeros.

NOTE4: these structures all reside on disk. The kernel may maintain (it will!) additional, similar structures in memory. These structures will refer to both themselves (using pointers, or offsets, or indices) or they will refer to disk blocks (numbers).