Hi Jason, On 7/16/05, Jason J. Herne <hernejj@xxxxxxxxxxxx> wrote: > > > When get_block gets called via prepare_write, since my inode (for some > > > reason) does not seem to exist on the disk yet, I cannot step through my > > > on-disk inode list and find the inode given by the 'inode' argument to > > > the get_block function. Should my new inode exist on the disk yet? > > > > I reckon this is a filesystem specic or even filesystem implementation > > specific question. For example, we don't require it, others may. > > > > > In the situation above, what am I supposed to do in get_block?? Should > > > I allocate a block for this file and initialize the bh_result argument > > > to get_block? > > > > Have a look at ext2_get_block. What you need to do is call map_bh if > > the block exists on the disk or you have just allocated it (depending > > on the create parameter - then you also must set its "new" flag). > > If I need to allocate a new block for this file (in get_block), I'll > need to update the on-disk inode because the on-disk inode contains a > list of blocks that make up the file's contents. How can I do this if I > do not have access to the on-disk inode? For example if you have an in memory copy of all necessary structures that you flush to disk at some later time when it is more convenient. E.g. our filesystem is all weird and only checks if there is enough room for the data, it allocates blocks for them no sooner than just before they are actually written to disk. > The ondisk inode actually gets created in write_inode() which is not > called until after get_block() and write_page() are called, which means > when the on-disk inode is created/written for this file, we have no idea > how many blocks it needs? (Goes along with paragraph above) You allocate blocks block by block when they are necessary, for example ext2 uses some sort of preallocation to do it effectively but I haven't studied it. You never have an idea abut how big a file will be when you create it. I reckon that when ext2 finds an inode number for an inode that does not exist on disk yet, it is written to disk so that it does. That way they avoid the problems you describe. Briefly looking at the code... I think they do it in ext2_create_inode in ialloc.c but I have never read the ext2 specific bits. > Taking a look at BFS, EXT2, and Minix I've noticed one particular > similarity in their get_block() implementations. They all use something > like the following line to get an inode_info structure for an inode. > > struct bfs_inode_info *bi = BFS_I(inode); > > BFS_I seems to: > > return list_entry(inode, struct bfs_inode_info, vfs_inode); > > and list_entry is #DEFINE : > > container_of(ptr, type, member) > > It almost looks like the vfs_inode is always wrapped inside of a > bfs_inode_info data structure and the BFS_I function returns a pointer > to the bfs_inode_info structure. Exactly. > But... how can this be??? I thought > that the inode we're looking at has been allocated by the slab layer... Yes and no. You allocate your inodes in alloc_inode super_block_operation (see ext2_alloc_inode) and what almost everybody does is have a slab for allocating BFS_inode_info, ext2_inode_info etc which contains struct inode that you return. HTH Martin -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
