From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@kernel.org
Subject: [Bug 194689] New: tune2fs: bugs in handling resize inode/undo file handling
Date: Fri, 24 Feb 2017 07:15:42 +0000 [thread overview]
Message-ID: <bug-194689-13602@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=194689
Bug ID: 194689
Summary: tune2fs: bugs in handling resize inode/undo file
handling
Product: File System
Version: 2.5
Kernel Version: 2.6.37
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
Assignee: fs_ext4@kernel-bugs.osdl.org
Reporter: admin@tho-otto.de
Regression: No
There seem to be some bugs in handling the combination of resizing inodes and
specifying an undo file with the -z option. Before each run, i have created a
test image with the command:
$ mke2fs -F -o Linux -I 128 test.img 512
mke2fs 1.43.5-WIP (17-Feb-2017)
test.img contains a ext2 file system
created on Fri Feb 24 07:54:45 2017
Creating filesystem with 512 1k blocks and 64 inodes
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Then, when running
$ E2FSPROGS_UNDO_DIR=. tune2fs -f -I 256 -z my.e2undo test.img
I get the following output
tune2fs 1.43.5-WIP (17-Feb-2017)
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) <proceeding>
Overwriting existing filesystem; this can be undone using the command:
e2undo ./tune2fs-test.img.e2undo test.img
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) n
./tune2fs-test.img.e2undo: while force-closing undo file
It asked two times. I let the first question timeout, but the second time it
waited forever. Also, the last line looks a bit confusing, apparently it got an
error but does not tell which one.
Next, i tried
$ E2FSPROGS_UNDO_DIR=/nonexisting tune2fs -f -I 256 -z my.e2undo test.img
tune2fs 1.43.5-WIP (17-Feb-2017)
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) y
Setting inode size 256
i.e. it happily proceeded without ever creating an undo file.
And last, when i run
$ E2FSPROGS_UNDO_DIR=. tune2fs -f -I 256 -z my.e2undo test.img
I get
tune2fs 1.43.5-WIP (17-Feb-2017)
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) y
Overwriting existing filesystem; this can be undone using the command:
e2undo ./tune2fs-test.img.e2undo test.img
Resizing inodes could take some time.
Proceed anyway (or wait 5 seconds) ? (y,N) y
Setting inode size 256
It created an undo file, but this is the default, ignoring the commandline
option.
--
You are receiving this mail because:
You are watching the assignee of the bug.
reply other threads:[~2017-02-24 7:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-194689-13602@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=linux-ext4@kernel.org \
/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