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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.