Hi, If original images are ext4 format, this can be done by writing the image to a new device and resizing the new device via resizefs. Yongqiang, Thanks, On Tue, Dec 4, 2012 at 3:46 AM, Darren Hart <dvhart@xxxxxxxxxxxxx> wrote: > On 12/01/2012 11:31 AM, Andreas Dilger wrote: >> On 2012-11-30, at 10:08 PM, Darren Hart wrote: >>> On 11/30/2012 08:23 PM, Andreas Dilger wrote: >>>> On 2012-11-30, at 7:13 PM, Darren Hart wrote: >>>>> 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. >>>> >>>> Maybe some background on what you are trying to do would help us to >>>> understand the problem? >>> >>> Sure, a few are already aware, but I suppose some extra detail for >>> the first post to this list is in order. >>> >>> I work on the Yocto Project, and this particular effort is part of >>> improving our deployment tooling. Specifically, the part of the build >>> process that creates the root filesystem. >>> >>> Most all filesystems have some mechanism to create prepopulated >>> images without the need for root permissions. Many do this through >>> a -r parameter to their corresponding mkfs.* tool. The exceptions to >>> this are ext3 and ext4. Our current tooling relies on genext2fs and >>> flipping some bits to "convert" the ext2 filesystem to ext3 and 4. >>> Not ideal. >>> >>> After exploring options like libguestfs and finding them to be >>> considerably heavy weight for what we are trying to accomplish, I >>> discussed the possibility of adding an argument to mke2fs which would >>> populate a newly formatted filesystem from a specified directory. Ted >>> suggested a clean set of patches implementing this were likely to be >>> accepted. >> >> Hmm, I wonder if libext2fs can itself create extent-mapped files, >> or if these files will be block-mapped? If they are small (< 1MB), >> it is probably not a huge problem, but if your files are large it >> may be that libext2fs also creates "ext2" files internally? >> >> Maybe Ted can confirm whether that is true or not. At least I recall >> that the block allocator inside libext2fs was horrible, and creating >> large files was problematic. > > > Ted, can you confirm? > > >> I guess the other question is why you don't use debugfs to create >> the directory tree and copy the files into your new filesystem? >> It already has "mkdir", "mknod" and "write" commands for use, and >> it is a one-line patch to alias "write" to "cp" for easier use[*]. > > > I just didn't know about it and it didn't come up in my polling :-) > (which would have been more fruitful had I done some of that here). > > >> Then, it just needs a debugfs script to build your directory tree >> and copy files over. Possibly enhancing "cp" to call do_mknod() for >> pipe/block/char devices would make this easier to use. >> >> Something like the following, though it seems there isn't an "ln -s" >> or "symlink" command for debugfs yet, that would need to be written. >> >> #!/bin/bash >> SRCDIR=$1 >> DEVICE=$2 >> >> { >> find $SRCDIR | while read FILE; do >> TGT=${FILE#$SRCDIR} >> case $(stat -c "%F" $FILE) in >> "directory") >> echo "mkdir $TGT" >> ;; >> "regular file") >> echo "write $FILE $TGT" >> ;; >> "symbolic link") >> LINK_TGT=$(ls -l $FILE | sed -e 's/.*-> //') >> echo "symlink $TGT $LINK_TGT" >> ;; >> "block special file") >> DEVNO=$(stat -c "%t %T" $FILE) >> echo "mknod $F $DEVNO $TGT >> ;; >> "character special file") >> DEVNO=$(stat -c "%t %T" $FILE) >> echo "mknod $TYPE $DEVNO $TGT >> ;; >> *) >> echo "Unknown file $FILE" 1>&2 >> ;; >> done >> done >> } | debugfs -w -f /dev/stdin $device > > > This is really promising. I've tweaked it a bit to use the basename and > cd into the directories as they are traversed by find so it doesn't try > and create filenames like "/dir1/hello.txt" in the root directory. > > #!/bin/sh > SRCDIR=$1 > DEVICE=$2 > > { > find $SRCDIR | while read FILE; do > #TGT=${FILE#$SRCDIR} > TGT=$(basename ${FILE#$SRCDIR}) > > # Skip the root dir > if [ -z "$TGT" ]; then > continue > fi > > case $(stat -c "%F" $FILE) in > "directory") > echo "mkdir $TGT" > echo "cd $TGT" > ;; > "regular file") > echo "write $FILE $TGT" > ;; > "symbolic link") > LINK_TGT=$(ls -l $FILE | sed -e 's/.*-> //') > echo "symlink $TGT $LINK_TGT" > ;; > "block special file") > DEVNO=$(stat -c "%t %T" $FILE) > echo "mknod $TGT b $DEVNO" > ;; > "character special file") > DEVNO=$(stat -c "%t %T" $FILE) > echo "mknod $TGT c $DEVNO" > ;; > *) > echo "Unknown file $FILE" 1>&2 > ;; > esac > done > } | debugfs -w -f /dev/stdin $DEVICE > > >> I would guess that implementing "symlink" support in debugfs will >> be orders of magnitude less work, maintenance, and bugs than your >> current patch. > > > It needs symlink as you said, but I can relatively easily migrate my > code for that in mke2fs to debugfs. > > Still needs permissions and such. Is that done with "modify_inode" ? If > so, how do I specify the new contents? > > I need to look into how to detect and support hard links. > > >> This might be turned inside-out and just run a "find $SRCDIR" and >> have the inner loop check the file type and call the appropriate >> operation for it (mkdir, write/cp, mknod, symlink). Note that >> "find" will return the directories first, so this should be OK to >> just consume the lines as they are output by find. > > > Yes, this seems to work just fine. > > >>> I don't have much filesystem experience - most of my experience is >>> with core kernel mechanisms, ipc, locking, etc. - so I'm mostly >>> hacking my way to some basic functionality before refactoring. The >>> libext2fs library documentation gave me a good start, but I >>> occasionally trip over things like the problem described below as >>> there is no documentation for what I'm trying to do specifically >>> (of course) and many of the required functions are only minimally >>> documented, and sometimes only listed in the index. >> >> Definitely, if the documentation is lacking and you've spent cycles >> figuring something out, then a patch to improve the documentation is >> most welcome. > > > I plan to update this as I go... although I'm going to have much less to > do if I use the debugfs approach. ;-) > > I wonder if it would make sense to integrate the debugfs functionality > into libext2fs and enable both debugfs and mke2fs to use the same common > code. I think the "-r initialdir" option would still be nice to have for > mke2fs, and does make it more consistent with other FSs in this feature. > > >> >>> The specific instance below is the result of me trying to format and >>> populate a filesystem image (in a file) from a root directory that looks like this: >>> >>> $ tree rootdir/ >>> rootdir/ >>> |-- dir1 >>> | |-- hello.lnk -> /hello.txt >>> | `-- world.txt >>> |-- hello.lnk -> /hello.txt >>> |-- hello.txt >>> |-- sda >>> `-- ttyS0 >>> >>> $ cat rootdir/hello.txt >>> hello >>> >>> In mke2fs.c I setup the new getopt argument and call nftw() with a >>> callback called init_dir_cb() which checks the file type and takes >>> the appropriate action to duplicate each entry. The exact code is at: >> >> To be honest, ntfw() will drag a bunch of bloat into e2fsprogs that >> doesn't exist today, and isn't really portable. > > > OK, well it could also be done with ftw to be more portable, but I guess > it's still marked obsolete in POSIX.1-2008 :/ > > Similar functionality could be implemented relatively easily. > > >> >>> http://git.infradead.org/users/dvhart/e2fsprogs/blob/refs/heads/initialdir:/misc/mke2fs.c#l2319 >>> >>> As described below, when I update the inode.i_size after the initial >>> write and copying of the file content, the above cat command fails to >>> output anything when run on the loop mounted filesystem. If I just >>> hack in the i_size prior to writing the inode for the first time and >>> don't update it after copying the file content, then the cat command >>> succeeds as above on the loop mounted image. >> >> It probably makes sense to understand what is broken here, whether >> it is the library or the program. We definitely want to make sure >> the API is usable and working correctly in any case. > > > I should be able to compare with debugfs "write" and see what the > difference is. > > >> >>> The commented out inode write is noted here: >>> >>> http://git.infradead.org/users/dvhart/e2fsprogs/blob/refs/heads/initialdir:/misc/mke2fs.c#l2462 >>> >>> Does that help clarify the situation? >>> >>> What I'm looking for is some insight into what it is I am not >>> understanding about the filesystem structures that causes this behavior. >> >> I hate to put a downer on your current work, but I think that you >> are adding something overly complex that only has a very limited >> usefulness, and your time could be better spent elsewhere. > > Not at all! I appreciate the tip. And it hasn't been wasted time, I've > learned quite a bit, and as I said above, perhaps the debugfs copies and > such can be pushed into libext2fs and used in both. ext2fs_mkdir() > exists after all, why not ext2fs_mksymlink(), ext2fs_mknod() and > ext2fs_writefile() ? > > Thanks a lot for the insight, exactly what I needed! > > -- > Darren > >> >> [*] add debugfs "cp" command as an alias to "write": >> >> diff --git a/debugfs/debug_cmds.ct b/debugfs/debug_cmds.ct >> index a799dd7..3789dcd 100644 >> --- a/debugfs/debug_cmds.ct >> +++ b/debugfs/debug_cmds.ct >> @@ -119,7 +119,7 @@ request do_undel, "Undelete file", >> undelete, undel; >> >> request do_write, "Copy a file from your native filesystem", >> - write; >> + write, cp; >> >> request do_dump, "Dump an inode out to a file", >> dump_inode, dump; >> >>> Thanks, >>> >>> Darren >>> >>>> >>>> Cheers, Andreas >>>> >>>>> 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@xxxxxxxxxxxxxxx >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>>> >>>> Cheers, Andreas >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> Cheers, Andreas >> >> >> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Wishes Yongqiang Yang -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html