[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <50B967E2.7090703@infradead.org>
Date: Fri, 30 Nov 2012 18:13:54 -0800
From: Darren Hart <dvhart@...radead.org>
To: linux-ext4 <linux-ext4@...r.kernel.org>
Subject: [e2fsprogs] initdir: Writing inode after the initial write?
I am working on creating some files after creating a filesystem in
mke2fs. This is part of a larger project to add initial directory
support to mke2fs. To make it easy for people to see what I'm working
on, I've pushed my dev tree here:
http://git.infradead.org/users/dvhart/e2fsprogs/shortlog/refs/heads/initialdir
Note: the code is still just in the prototyping state. It is inelegant
to say the least. The git tree will most definitely rebase. I'm trying
to get it functional, once that is understand, I will refactor
appropriately.
I can create a simple directory structure and link in files and fast
symlinks. I'm currently working on copying content from files in the
initial directory. The process I'm using is as follows:
ext2fs_new_inode(&ino)
ext2fs_link()
ext2fs_read_inode(ino, &inode)
/* some initial inode setup */
ext2fs_write_new_inode(ino, &inode)
ext2fs_file_open2(&inode)
ext2fs_write_file()
ext2fs_file_close()
inode.i_size = bytes_written
ext2fs_write_inode()
ext2fs_inode_alloc_stats2(ino)
When I mount the image, the size for the file is correct, by catting it
returns nothing. If I instead hack in the known size during the initial
inode setup and drop the last ext2fs_write_inode() call, then the size
is right and catting the file works as expected.
Is it incorrect to write the inode more than once? If not, am I doing
something that is somehow decoupling the block where the data was
written from the inode associated with the file?
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists