From: Ivan Shmakov <ivan@gray.siamics.net>
To: linux-ext4@vger.kernel.org
Subject: Re: ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG?
Date: Wed, 31 Aug 2011 22:59:22 +0700 [thread overview]
Message-ID: <86y5y9bmhx.fsf@gray.siamics.net> (raw)
In-Reply-To: 20110831152207.GB32582@thunk.org
>>>>> 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
prev parent reply other threads:[~2011-08-31 15:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-31 10:52 ext2fs_block_iterate (e2, EXT2_RESIZE_INO, ...) => EXT2_ET_FILE_TOO_BIG? Ivan Shmakov
2011-08-31 15:22 ` Ted Ts'o
2011-08-31 15:59 ` Ivan Shmakov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y5y9bmhx.fsf@gray.siamics.net \
--to=ivan@gray.siamics.net \
--cc=linux-ext4@vger.kernel.org \
--cc=oneingray@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox