Curiosly enough, ext2fs_block_iterate () returns
EXT2FS_BLOCK_ITERATE for EXT2_RESIZE_INO (the binary in question
is statically linked against libext2fs, 1.41.12 debian 2):
(gdb) print ext2fs_block_iterate (e2, ino, 0, 0, db_add_block, (void *)sp)
$13 = 2133571410
(gdb)
Is it because the blocks belonging to this inode aren't supposed
to belong to the filesystem itself, I wonder?
TIA.
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)
On Wed, Aug 31, 2011 at 05:52:35PM +0700, Ivan Shmakov wrote:
> Curiosly enough, ext2fs_block_iterate () returns
> EXT2FS_BLOCK_ITERATE for EXT2_RESIZE_INO (the binary in question
> is statically linked against libext2fs, 1.41.12 debian 2):
>
> (gdb) print ext2fs_block_iterate (e2, ino, 0, 0, db_add_block, (void *)sp)
> $13 = 2133571410
> (gdb)
>
> Is it because the blocks belonging to this inode aren't supposed
> to belong to the filesystem itself, I wonder?
It returned the error EXT2_ET_FILE_TOO_BIG. From ext2_err.h, which
you can get from the build tree of e2fsprogs, in lib/ext2fs/ext2_err.h
(generated from lib/ext2fs/ext2_err.et):
#define EXT2_ET_FILE_TOO_BIG (2133571410L)
Yeah, the resize inode is a special case. It is specially constructed
to reserve space for new block group descriptor blocks when doing an
online resize. I would suggest for your purposes that you _not_
support the online-resizable file system feature, as it's unneeded
complexity (from what I understand of what you're going to be doing
with the file system).
Regards,
- Ted
P.S. The code to create the reserved inode can be found in
lib/ext2fs/res_gdt.c, in ext2fs_create_resize_inode().
>>>>> Ted Ts'o <[email protected]> writes:
[…]
> Yeah, the resize inode is a special case. It is specially
> constructed to reserve space for new block group descriptor blocks
> when doing an online resize. I would suggest for your purposes that
> you _not_ support the online-resizable file system feature, as it's
> unneeded complexity (from what I understand of what you're going to
> be doing with the file system).
I don't seem to understand why such a support would require a
specific handling of the resizable filesystems (other than that
EXT2_RESIZE_INO is to be ignored by e2dis.)
As I currently have no means of Ext2+ FS non-payload parts
extraction, I'm going to rely on e2image(8). Like:
# tar -C / -jcf image.files.tar.bz2 mnt/
$ /sbin/e2image -r image.ext2 image.e2image
$ e2dis image.index < image.ext2
Then, the image could be restored with:
$ tar -jxf image.files.tar.bz2
$ find mnt/ -type f -print0 \
| (cat < image.e2image && imrt image.index) \
> image.ext2
(Note that imrt is going to lseek(2) its stdout.)
That way, I assume that the resize inode is going to be
preserved thanks to e2image.
The point of the procedure above is that instead of passing a
complete .tar.bz2 archive with all the files, only the new files
may be passed, should it be necessary to produce a new version
of the image (like passing a diff instead of the whole source.)
Moreover, for system images, most of the files would likely to
be available from the regular OS packages' repositories.
> P.S. The code to create the reserved inode can be found in
> lib/ext2fs/res_gdt.c, in ext2fs_create_resize_inode().
ACK. Thanks.
--
FSF associate member #7257 Coming soon: Software Freedom Day
http://mail.sf-day.org/lists/listinfo/ planning-ru (ru), sfd-discuss (en)