e2fsprogs 1.47.1~rc2-1 is now in Debian Testing. If you need e2fsprogs
built for an older version of Debian/Ubuntu that hasn't done the 64-bit
time_5 transition (e.g., you don't have libext2fs2t64 and just have
libext2fs2 package installed), grab the debian/backports branch from my
e2fsprogs git
n.b. If Ubuntu hasn't taken the 32-bit time_t change (which is in
Debian unstable) I have a commit which backs out this change for
building e2fsprogs on older systems, e.g., for backports.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Today, we don't create the sparse file "with the required size" when it
is first opened. We could try seeking to maximum size of the device
and writing a single byte, and seeing whether or not that fails, and if
it fails, *assume* that this was caused by the target file system not
supporting
If the file system has a limit on the size of the file (for example,
ext4 has a maximum file size of 16TB), then when you do a relative seek
via llseek(fd, offset, SEEK_CURR), the system call will return EINVAL.
This is what is causing the error.
If you want to create a raw image of a very large
If you don't take 1.46.4 for 22.04, you might want to consider at the
very least backporting the fix for:
Fix a regression introduced in 1.64.3 where attempting to create a file
system image using mke2fs into a non-existent file would fail.
(Addresses Debian Bug: #992094)
As this will likely be
Your suggested message presupposes that busybox is used on a particular
distribution. That's not necessarily the case. Remember, e2fsprogs
is designed for all distributions, not just for Ubuntu. If Canonical
wants to make a change like that to e2fsprogs, all distributions are
free to make any
Note that I've just released e2fsprogs 1.46.4-1 for Debian:
E2fsprogs 1.46.4 (August 18, 2021)
==
Updates/Fixes since v1.46.3:
UI and Features
---
The defaults for mke2fs now call for 256 byte inodes for all file
systems (with the exception of file
It doesn't matter whether you store your personal data on the partition
where the OS is located, or elsewhere. Either way, you may need to
know how to run e2fsck on the file system if you want to try to
maximally recover data. If you don't know what you are doing, sure, go
ahead and run fsck
These problems are fixed upstream. See:
commit 225e5d093b519f9dbe9fcaacd995426f0e5194f6
Author: Theodore Ts'o
Date: Wed Jul 28 13:51:13 2021 -0400
e2fsck: fix f_baddotdir failure on big-endian systems
Commit 63f44aafb1f2 ("e2fsck: fix ".." more gracefu
fsck -y isn't *always* the right answer. The reason why the boot
scripts don't just run fsck -y automatically is that sometimes a human
with judgement can do better by manually running fsck instead of just
blindly answering yes to all questions.For "users who are not
competent" (your words,
E2fsprogs has its build dependency set to libfuse-dev for a reason.
The Fuse upstream has minimal instructions on how to do the fuse->fuse3
conversion, and the e2fsprogs upstream (me) doesn't have the time
currently to try to figure it out, and Debian is supplying both fuse and
fuse3 so the debian
If the computer is hanging as you describe, this is a kernel bug,
possibly exacerbated by a hardware bug. It isn't a userspace bug;
e2fsprogs is just reading from the block device. If that is causing the
computer hang, it's by definition not a userspace bug.
So this needs to be a kernel
This relatively simple to change the default inode size in all cases.
Look at /etc/mke2fs.conf, which is in the sources as
misc/mke2fs.conf.in. Find the lines where the inode_size is set to
128, and change it to be 256. (This might or might cause problems on
Hurd; since I'm not sure whether
janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16
uas_eh_abort_handler 0 uas-tag 17 inflight: OUT
UAS is "USB Attached SCSI", and this error indicates some kind of
hardware issue (maybe a loose cable connector?).
If you can't replicate the failure, it might be because it's a one-off
hardware
Hmm... I can't duplicate this on Debian testing, which is using a newer
version of e2fsprogs (1.45.5-2). The e2scrub_reap.service file is
identical with Ubuntu's 1.45.3-4ubuntu2.1, though. And looking at the
service file, I have no idea why systemctl would be trying to paskk for
a password,
Can you provide an exact set of commands to create the file system,
populate the file system, that *anyone* (but especially, the developers
that you are asking to looking at the bug) to replicate this failure?
In particular, how is the file system is created (the exact mke2fs
command) and the set
So if the same procedure (with exactly the same files) reproduces
reliably when using a partition and gpart --- and it does not reproduce
at all, even with multiple attmepts, without gpart, then it is clearly a
gpart bug.
** Package changed: e2fsprogs (Ubuntu) => gpart (Ubuntu)
--
You received
Oh, also please send me the dumpe2fs -h of the partition before you try
to resize it, and please send the output of your reproduction with the
locale set to POSIX, so I can read the output of e2fsprogs in English,
please?
--
You received this bug notification because you are a member of Ubuntu
Can you provide a detailed reproduction instructions --- preferably one
that I can run myself, so I can see exactly is going on?
One thing that would be helpful is whether this can me reproduced
without gpart being part of the mix. That is, can you do something like
this:
mke2fs -t ext4
This is a known bug fixed in Debian and upstream git.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830500
Title:
Issue with
This is fixed by e2fsprogs 1.45.1-3 in Debian, or in the soon to be
released e2fsprogs 1.45.2.
e2fsprogs (1.45.1-3) unstable; urgency=medium
* Fix e2scrub_all cron failures (Closes: #9292870)
-- Theodore Y. Ts'o Mon, 20 May 2019 21:48:40 -0400
e2fsprogs (1.45.1-2) unstable; urgency=medium
This was a regression that was reported at:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288
... a fix has been applied uptream and the fix has been cherry picked
for Ubuntu. See the above bug for details.
--
You received this bug notification because you are a member of
Yep, it looks like it was a regression that was introduced by commit
50d0998cfee ("libext2fs: add ea_inode support to set xattr"). The
following patch should fix things.
** Patch added:
"0001-libext2fs-fix-regression-so-we-are-correctly-transla.patch"
On Mon, Dec 03, 2018 at 08:24:07AM -, Tor Stenvaag wrote:
> The maint branch indeed fixed the problem. Output attached. Thanks for
> your effort.
>
> (There is still a "warning" about "extent tree (at level 1) could be
> narrower. Fix? yes" when running e2fsck after resize. When selecting
>
This looks like a dup of
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1798562
and is fixed by:
commit 4b3038134baf81c6f9bd36dbbf565ea66e46331f
Author: Theodore Ts'o
Date: Sat Oct 20 09:14:48 2018 -0400
resize2fs: update checksums in the extent tree's relocated block
*** This bug is a duplicate of bug 1798562 ***
https://bugs.launchpad.net/bugs/1798562
** This bug has been marked a duplicate of bug 1798562
After a side by side installation, resized filesystem is corrupted
--
You received this bug notification because you are a member of Ubuntu
Bugs,
*** This bug is a duplicate of bug 1798562 ***
https://bugs.launchpad.net/bugs/1798562
** This bug has been marked a duplicate of bug 1798562
After a side by side installation, resized filesystem is corrupted
--
You received this bug notification because you are a member of Ubuntu
Bugs,
.
Addresses-Launchpad-Bug: 1798562
Signed-off-by: Theodore Ts'o
Reported-by: Jean-Baptiste Lallement
I've tested e2fsprogs with this change and it fixes your repro. I also
have a regression test in the subsequent commit which reproduces the
problem with a smaller test file
This is probably not assigned to the right package. It's not an issue
with e2fsprogs, but whatever component is running fsck. This might be
systemd, or upstart, or whatever the heck Ubuntu is using these days.
I lost track a while ago. :-)
I can tell, you as the Debian maintainer of
Note a file system which is significantly shrunk --- which tends to be
the case with resize2fs -M --- is going to have files fragmented which
will have performance implications. It's not clear to me what you are
trying to optimize for --- I assume you're just wanting to save on
download
-off-by: Darrick J. Wong
Signed-off-by: Theodore Ts'o
In the course of fixing the above bug, it means that if there was a need
to grow file system which is nearly full, and the resize is being done
off-line, and there is a need to grow the file system, we will end up
failing as described
This is almost certainly fixed via this patch:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint=b0ec76d623f737a32abc5ab8bb7198bf1d9939a4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Yes, this has been fixed quite a while ago. :-)
Online resize with flex_bg was fixed in 2012 --- call with the v3.10
kernel or so.
Offline resize was fixed around that time (e2fsprogs 1.43), but there
have been some bugs with flex_bg and off-line resizing, so I'd recommend
using at least
OK so it looks like you were trying to shrink a file system from 59G to
30G (using an off-line resize, since on-line resizing only supports
growing a file system).
Hmm are you willing to send me (probably off-line) a metadata-only
dump of the "before" file system? See the e2image page, and
#1 Was this an on-line or off-line resize? That is, was the file
system mounted at the time when you ran resize2fs?
#2 Can you post a copy of dumpe2fs before you started to resize?
#3 How big were you trying to resize the file system to become?
It's great that you have a snapshot of the
Thanks, fixed in upstream e2fsprogs-maint. Will be in next 1.44.x
release of e2fsprogs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1743553
Title:
[Typo] Missing word in Zesty Man Page for
The blog post here:
https://raid6.com.au/posts/fs_ext4_external_journal_caveats/
is not generally true. What journal_async_commit does is convert the
sequence:
1. write journal blocks
2. cache flush
3. write journal commit block
4. cache flush
... to:
1. write journal blocks
2. write
Your system sounds like its thrashing due your processes wanting to you
more memory than is available in your system. (BTW, this has nothing to
do with e2fsprogs).
Some links to pages that might be helpful:
If you are trying to build from the unpacked debian sources for 1.43.x,
you'll need to run the commands:
./debian/rules mrproper
./debian/rules
... to have the build system figure out which antique version of Debian
build infrastructure you are using, and regenerate debian/control from
The Metadata_csum feature is a RO_COMPAT feature. Hence, grub2 and os-
prober shouldn't care about this feature (if properly implemented).
This is because the guarntee is that even if the kernel (or userspace
application directly accessing the file system) doesn't know about a bit
in the
E2fsprogs 1.44.0 now depends on dpkg build-profiles, which means that
getting it backported to 14.04 LTS would require adjusting
debian/control and debian/rules a bit. For 14.04 LTS, I'd urge
consideration of going to e2fsprogs 1.43.9. This will get you most of
the latest bug fixes, including
I recently released e2fsprogs 1.44.0 (currently in Debian Unstable,
should hopefully hit Debian Testing in three more days) which turns on
Metadata Checksums for everyone.
https://packages.debian.org/sid/e2fsprogs
Pulling in 1.44.0 supports two new features, largedir and ea_inode,
(neither
It should be noted that I recently released e2fsprogs 1.44.0 (currently
in Debian Unstable, should hopefully hit Debian Testing in three more
days) which turns on Metadata Checksums for everyone.
https://packages.debian.org/sid/e2fsprogs
Pulling in 1.44.0 into 18.04 LTS would be nice since it
Note that libcomerr2 has been renamed to libcom-err2 to conform with
Debian's packaging naming guidelines. So libcomerr2 is now a
transitional package (arch=all) where previously it was a binary
package.
Why this is failing on Ubuntu is a complete mystery to me. On Debian
Unstable, using
** Summary changed:
- fsck should check before running on an encrypted LUKS partition
+ Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS
partition
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So what happened is the following. There was a previous ext4 file
system on the disk. You ran "cryptsetup luksFormat /dev/sda1" which
wiped out the primary superblock.
You then manually ran fsck.ext4 on the device. It noticed the primary
superblock was non-existent, and then asked permission
Note: I think this should be a low-priority/wishlist/feature request.
But I can't edit the importance.It is a valid feature request
though, so I plan to treat it at that priority.
If someone else thinks it's higher priority, patches are welcome. :-)
** Changed in: cryptsetup (Ubuntu)
The commit is upstream in git now:
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint=c8ca23979fa75df15208922422e81c83cf112320
I will be releasing e2fsprogs 1.43.5 soonish and I plan to do a release
to Debian Unstable/Testing at the same time. So you might just want to
wait for
The errors simply mean that ext4 has detected that its metadata has
gotten corrupted. How and why it happened is going to vary from
situation to situation.
For example, in the case of the original reporter, it was due to him
installing ext2fsd, and trying to access the file system from windows.
You don't need to check with upstream e2fsprogs; I do keep an eye on
Launchpad bugs.
None of UBSAN warnings are actually dangerous assuming sane[1] compilers
and reasonable architecture. (e.g., a compiler that can correctly
compile the Linux kernel and an architecture that run Linux should have
I would recommend doing an on-line resize. That code path should work
for you.
As far as why the off-line resize is hanging, you would need to run it
with debugging symbols under gdb and then stop it and submit a stack
trace so we can see where it is hanging.
--
You received this bug
Was released a ***long*** time ago. Guess Canonical doesn't do this
automatically.
** Changed in: e2fsprogs (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Fix is in e2fsprogs 1.43.4
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1645232
Title:
e2fsprogs - could not preserve
I've committed a complete fix to the master branch of the e2fsprogs git
tree.
One of the reasons why I don't want to commit a partial fix is because
the potential for corruption of production file systems by programs such
as fuse2fs was extremely high. Users of mke2fs -d are generally
embedded
I was hoping you would be interested in further refining the patch which
you put forward. But if you don't have the time or interest, that's
fine, I'll put it on my queue of things on my todo list. (Or maybe
someone from Canonical will be interested in picking this up.)
--
You received this
Thanks for the patch; it definitely helps identify the problem. I don't
think it is a completely correct change, however.
The problem is that it's doing the translation in
write_xattrs_to_buffer(), but it is not making the translation in the
opposite direction in read_xattrs_to_buffer(). This
Is it always the same inode number which is reported as having an
invalid checksum?
Can you attach the output of dumpe2fs -h /dev/hdXX (where hdXX should be
replaced with the block device name of your file system)?
--
You received this bug notification because you are a member of Ubuntu
Bugs,
One bit of context --- metadata_csum is not enabled by default in the
official upstream e2fsprogs.tar.gz file. So with my upstream maintainer
hat, I deliberately decided not to enable it by default, and mentioned
in the release notes that individual distributions should decide whether
they wanted
Known problem, fixed in e2fsprogs 1.42.2 or 1.42.3 in commit:
commit 3d6fc974831a360aee460e54c442538445f3017c
Author: Theodore Ts'o <ty...@mit.edu>
Date: Wed Aug 10 15:49:35 2016 -0400
resize2fs: fix crash when there is an ea block and no blocks to migrate
This fixes
Rolf, can you collect the requested logs? I think this is pointless
since it's pretty clear that there's a commit that just needs to be
backported, but that's between use and the Ubuntu Kernel team to figure
out. Or you can just use the upstream 4.7 kernel. :-)
--
You received this bug
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1619918
This is not an e2fsprogs bug, but a bug in the kernel. The fix is in
mainline as of v4.7, commit id: 4c63c2454eff996. It needs to be ported
to the Ubuntu Trusted (and other Ubuntu LTS) kernels.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Looks like you are using a pre-3.18 kernel with e2fsprogs 1.43.1. I'm
guessing this is because whatever cloud service you are using is using a
very old kernel? (In contrast, Yakkety Yak is using a 4.x kernel.)
What kernel version is this cloud service using, anyway? I want to
make a mental
You may want to recheck the merge, or at least the remaining changes,
since Debian e2fsprogs 1.43.1 now:
a) Uses dh_update_autotools_config to update config.guess / config.guess
b) No longer uses dietlibc
c) Generates dbgsym packages if the underlying package infrastructure supports
them
At
There wasn't actually an *error*. E4defrag doesn't need root prives to
find and print statistics. It doesn't deliberately because the people
who wrote the program decided this was the right thing to do. So it's
not actually hiding the error, it's just doing something weird/stupid.
Which you
Fixed in 2013.
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1186331
Title:
[PATCH] e2fsck hangs up boot process because
this bug was not reproducible in 2011 and could not be reproduced as far
back as Lucid. Might as well close this since there has been no
activity since then.
** Changed in: e2fsprogs (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Has fsck run spit out any errors or output?If you have a completion
output, has it given an percentage output, or some other way of
determining how far along fsck is going?
When e2image wouldn't create an image file, did it report any errors?
--
You received this bug notification because
On Sun, Mar 27, 2016 at 03:25:40AM -, DD Park wrote:
> Hello, I need your help. This bug seemed to have been placed offline due to
> inactivity. It is still a problem as been working on moving things around
> to get a testing platform. I've been getting new hardware, and started
> another
You do realize that e2image doesn't contain any data blocks --- just
file system metadata blocks, right? And if you are concerned about the
directory names being too revealing, e2image has a -s option which will
scramble the directory file names. See the section "RAW IMAGE FILES" in
the e2image
There are plenty of people who *are* able to check file systems larger than
16TB. So talking about it in terms "that problem" doesn't make much sense.
*** This bug is a duplicate of bug 1438405 ***
https://bugs.launchpad.net/bugs/1438405
Can someone make the private bug public, if there is no private
information in that bug report?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
The badblocks program really isn't designed to catch maliciously
designed fake flash FTL's. The bit dropping pages aren't
necessarily constant, which means there might not be a set of block
numbers that you can _put_ in the bad block inode. The bad block inode
is a bad idea in these modern days
It's not e2fsprogs' responsibility to remove the /forcefsck file. It is
the job of initscripts.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229618
Title:
Saucy: /forcefsck not being removed
Changing to invalid, will not fix upsteam.
** Changed in: e2fsprogs (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1415077
Title:
resize2fs -P minimum
):
resize #1 resize #2 resize #3
old resize2fs1117186 45679 43536
new resize2fs 48784 37413 37392
Signed-off-by: Theodore Ts'o ty...@mit.edu
Note that using resize2fs -M multiple times will result in a file system
which is *not* optimized
The file system which I posted in #6 no longer triggers a bug in
1.42.12. It looks like it was fixed as a side effect of commit
9a1d614df217. @bigeel, what version of e2fsck were you using?
Could you try using e2fsprogs 1.42.12 and see if that fixes the problem
for you?
Thanks!!
--
You
To explain the e2fsprogs git branch naming scheme in terms of Debian
releases:
* maint == stable (and currently has a few bug fixes beyond what is in
1.42.12, although it's unlikely we will have a 1.42.13 release unless something
really serious comes up)
* master == testing (and has the inline
Just use the master branch of e2fsprogs; the pu branch is currently not
actually active, and when it is, it has experiments in it that might not
necessarily be ready for primetime.
The master branch should be good enough for both the inline data and
metadata checksum features.
--
You received
Note: if you want to use inline data, please strongly consider using the
upstream kernel; there are a lot of bugs that we're only now shaking
out.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348431
Note that there were bugs found that necessitated format changes for
metadata checksums in 3.18 --- which was released earlier this week.
E2fsprogs 1.43 hasn't been released yet, and e2fsprogs 1.42 has
***no support for metadata checksums.
People who are interested in testing metadata
Please strace the e4defrag process to see if it is spinning in userspace
or in the kernel.If it is spinning in the kernel, then it's a kernel
bug, not an e2fsrpogs problem. And since you're using a non-Ubuntu
kernel, you'll need to take this to the upstream linux-ext4 mailing
list.
If it
If you can see the GPF happen when mkfs.ext3 is writing to a bare
block device (/dev/sdc1 or /dev/sdd1), then it's not involving the
file system code at all, but just the block device or device driver
code. It's clearly not a file system bug at all, nor is it a
e2fsprogs bug, because nothing from
Can you try running memtest86+ for 12-24 hours, and see if that turns
up anything? Sometimes flaky memory can result in very confusing
problems / symptoms --- espeially when it almost but not always works
correctly.
The other thing which I might be suspicious about is if there might be
some
1) e2fsck (which is what fsck.ext[234] is hard linked to) is designed
to be safe when getting interrupted by ^C
2) The all kernel code uses the same address space. So if there is a
wild pointer in the Nvidia driver scribbles on random kernel memory,
literally anything can happen. There is a
You're jumping to conclusions here that the damage was caused by the
lack of -t ext4 to fsck. #1, the fsck program will determine the file
system type based on the file system type found in /etc/fstab. So if
the /etc/fstab file indicates that you were using ext4, then it wlil do
the equivalent
It depends on the version of e2fsprogs in Ubuntu (which is't specified
in this bug report).
The bug appeared in 1.42.9-3, and was fixed in 1.42.11-1. The bigalloc
file system is also notone which is used by default by most users. (and
probably shouldn't be unless you really know what you are
Canonical doesn't employ any ext4 engineers, and as far as I know, no
Ubuntu developers contribute to ext4 development. So the fact the
release notes might get a few things wrong shouldn't be surprising.
Canonical simply doesn't have any file system developers on staff, as
far as I know.
If you
Confirmed on an NTFS file system. It applies for those file systems
that do not support the FIEMAP ioctl, and so filefrag has to fall back
to the legacy (and far more inefficient) FIBMAP ioctl.
** Changed in: e2fsprogs (Ubuntu)
Status: New = Confirmed
--
You received this bug
The extent count calculation works correctly with the FIBMAP ioctl in
verbose (-v) mode, but without the verbose option, the calculation was
broken because we weren't properly updating the fm_ext data structures
in non-verbose mode.
Addresses-Launchpad-Bug: #1356496
Signed-off-by: Theodore Ts'o
Someone has reported what appears to be the same problem on the linux-
ext4 list, and between correlations of the observations from Dennis
(Thermaltaker) and on the linux-ext4 list, I believe we have a fix that
should address this problem:
Unfortunately, what you are requesting isn't possible. E4defrag works
in an online mode -- that it is, it works while the file system is
mounted.
E2fsck -D works off-line; the file system must be unmounted to optimize
the directory. So it simply wouldn't be possible to move the
functionality
I just don't think an adaptive algorithm is going to be worth the
complexity. It will invariably get it wrong for some work load or
another. At which point more people will start kvetching and opening
bug reports.
For one thing, it matters a lot what the average size is of the files
being
If you try to use more than 95% of the storage, performance will
generally suffer -- badly. Now, you may not care for certain use
cases; if you are doing backups, you might not worry about that much
about performance, and you might care a lot more about using the last
few bytes of the disk.
As the file system gets more and more full, the free space gets more and
more fragmented. This results in disastrous performance hits for files
that are written when the file system gets full, and then when you later
try to read them, you will suffer similar disastrous performance hits.
This is
Can you get me the fsck transcript for this run in question? It might
be in /var/log/fsck
Failing that, can you tell me what file system it was checking? Can
you run e2fsck by hand, and try to reproduce the failure, and grab the
e2fsck output when you do re-run it?
--
You received this bug
If someone could try running the following tests, it would be very
useful.
1) strace -o /tmp/resize.strace resize2fs /dev/XXX
2) resize2fs -d 31 /dev/XXX | tee /tmp/resize.debug
And then upload the files of the hanging resize2fs. It's not
something I've been able to reproduce when doing a
Can you send me the output of the following:
debugfs /dev/md/1
debugfs: stat 27528105
debugfs: stat 27528089
debugfs: quit
Thanks!!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1321418
Title:
Right, I didn't notice the first time I read the bug report you had
already deleted the inode to fix the problem. It would have been nice
to have gotten a look at the inode in question so I could really see
what was going on.
The internal error: can't find dup_blk error is one of those this
in: e2fsprogs (Ubuntu)
Status: New = Confirmed
** Changed in: e2fsprogs (Ubuntu)
Assignee: (unassigned) = Theodore Ts'o (tytso)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1321418
Title
1 - 100 of 596 matches
Mail list logo