ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG?

ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG?

[Ivan Shmakov]

	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)

Re: ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG?

[Ted Ts'o]

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().

Re: ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG?

[Ivan Shmakov]

>>>>> Ted Ts'o <tytso@mit.edu> 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)

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html