linux-ext4 - Re: "tune2fs -I 256" runtime---can it be interrupted safely?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 07 Nov 2008 14:16:43 -0700
From:	Andreas Dilger <adilger@....com>
To:	"Michael B. Trausch" <mike@...usch.us>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: "tune2fs -I 256" runtime---can it be interrupted safely?

On Nov 01, 2008  19:46 -0400, Michael B. Trausch wrote:
> On Sat, 1 Nov 2008 15:10:02 -0400
> "Michael B. Trausch" <mike@...usch.us> wrote:
> > I converted my home directory to ext4 without issue and so I
> > (stupidly, I admit) did not take a backup of this 250 GB drive's
> > contents before I started the conversion process.  Oops.  Lesson
> > learned.  My thinking at this point is that it would take _far_ less
> > time to interrupt, backup, and just use mkfs.ext4 on the drive and
> > then restore (about 2 hours instead of an unknown quantity which is
> > already nearing 13 hours).
> 
> At 18:01:34 (after 15 hours and change) I decided to give it up and
> sent tune2fs a SIGINT.  It happily aborted, and fsck appears to have
> fixed whatever inconsistencies were introduced during the tune2fs run
> and the files on the volume appear to be perfectly intact.

That is good news.  I would have worried that interrupting this operation
isn't very safe, because it is moving some core filesystem data around.

> Am going to go the route of simply pulling the data off and using
> mkfs.ext4 to create a new filesystem on the device.  But, I am still
> curious as to why this would run for so long.  Some volume statistics,
> in case they may be of help in trying to determine why this process was
> running for so long; I don't even know how much longer it would have
> run for.

> Inode size:               128

It looks like it did not finish the inode resize operation, for whatever
reason.

If you have time, after the backup is done could you please re-try the
"tune2fs -I 256" operation and let it go for a while, then "ltrace -p {pid}"
on the process from another window to see what it is doing (if anything).
You may need to have the "e2fsprogs-debuginfo" RPM installed to get useful
data there.

After grabbing some of the data with ltrace, also run "strace -p {pid}"
to get disk IO information, and finally "gdb -p {pid}" and grab a
stack trace with "bt", let it continue for a few seconds with "c", and
then CTRL-C again and grab another stack trace with "bt".

I'm assuming the code shouldn't actually have taken 13h to complete, but
is instead confused about something in the filesystem and is looping.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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