When is storage allocated for a newly created ext2 inode?

Question

I'm reading in Understanding the Linux Kernel, 3rd Edition on how to create a new regular file on ext2fs.
(Book is available online at multiple places: not sure as to their legalities. A later version of just the relevant chapter is at O'reilly's site - but it does not have all the relevant data)

As I see it, the Linux kernel has to create a new inode, and to allocate the necessary blocks to it.

The book outlines the following procedures:

• Creating inodes (p. 758)
• Allocating a Data Block (p. 764)

What I don't understand is when does the kernel allocate the new inode's data blocks.

Near the end (para. 14) of the Creating inodes procedure, I see the following:

Invokes ext2_preread_inode() to read from disk the block containing the inode and to put the block in the page cache. This type of read-ahead is done because it is likely that a recently created inode will be written back soon.

So, just prior to that - seems to me a logical place to allocate the inode's blocks. However, It may be that the ext2 architects decided to do the allocation at a different time.

Does anyone know when is storage allocated for a newly created ext2 inode?

Answer 1

In book i found this:

5. Allocates the disk inode: sets the corresponding bit in the inode bitmap and marks the buffer containing the bitmap as dirty. Moreover, if the filesystem has been mounted specifying the MS_SYNCHRONOUS flag (see the section “Mounting a Generic Filesystem” in Chapter 12), the function invokes sync_dirty_buffer( ) to start the I/O write operation and waits until the operation terminates.

It means that in terms of book allocating disk inode means just setting the BIT in in memory-kept inode bitmap and marking this bitmap buffer dirty. It means that soon this bitmap would be written back to storage.

About ext2_preread_inode(), here is the code:

static void ext2_preread_inode(struct inode *inode)
166 {
167         unsigned long block_group;
168         unsigned long offset;
169         unsigned long block;
170         struct ext2_group_desc * gdp;
171         struct backing_dev_info *bdi;
172 
173         bdi = inode->i_mapping->backing_dev_info;
174         if (bdi_read_congested(bdi))
175                 return;
176         if (bdi_write_congested(bdi))
177                 return;
178 
179         block_group = (inode->i_ino - 1) / EXT2_INODES_PER_GROUP(inode->i_sb);
180         gdp = ext2_get_group_desc(inode->i_sb, block_group, NULL);
181         if (gdp == NULL)
182                 return;
183 
184         /*
185          * Figure out the offset within the block group inode table
186          */
187         offset = ((inode->i_ino - 1) % EXT2_INODES_PER_GROUP(inode->i_sb)) *
188                                 EXT2_INODE_SIZE(inode->i_sb);
189         block = le32_to_cpu(gdp->bg_inode_table) +
190                                 (offset >> EXT2_BLOCK_SIZE_BITS(inode->i_sb));
191         sb_breadahead(inode->i_sb, block);
192 }

I am not kernel master, but it seems that this function just preread some block of the inode bitmap, which holds the current inode index. This is done in terms of performance increasing as mentioned in comments.

So my understanding - is that when they talk about INODE BLOCK, they mean a block of bitmap when particular inode bit is set. When this block is allocated? When you perform mkfs.ext2.

Maybe i didn't catch the question, so i have a small addition: If you are asking about the allocation of blocks for file linked with this inode then answer is the following:

The ext2_get_block() function ..., invokes the ext2_alloc_ block( ) function to actually search for a free block in the Ext2 partition.

so the answer then ext2_create -> ... -> ext2_alloc_ block

Answer 2

IIRC, on modern compilers the answer is "when flushing the fiile from disk cache". That may appear quite late, but remember that ext2 tries to avoid fragmentation. If you can delay the allocation of blocks until the whole file is in disk cache, you know exactly how big it is and can allocate one contiguous block.