I think I'm suffering from the same issue.
I was archiving my home in 1 tar file from 1 disk to another (all EXT4) and
then it got stuck. I had to restart the computer and eventually it proceeded,
but I have to say, after I copy large files, the chances I can't read/open
other large files are
papukaija: could you please update the bug description to point to
pertinent bugs for other kernel versions? I'm seeing what I suspect to
be ext4 corruption on multi-CPU systems (I think all amd64) or various
kernels, on both small and large files. Where and how should I report
this? So far,
@era: Unfortunately I won't edit this bug's title nor reopen it due to
reasosn mentioned in comment 215 which refers to comment 206. You should
report your issue to Launchpad against the linux package. You can do so
by running the following command from a Terminal
The bug should also affect 10.04. I have a fresh install 10.04 AMD64
(with data copy from old harddisk , stored on /home) . The result of
md5sum on ubuntu-9.10-desktop-i386.iso is changing for every time I run
the command:
$ md5sum ubuntu-9.10-desktop-i386.iso
adbe2aa291535c9bfb12f207d25659b5
@Ben (and everyone else who thinks that he/she has reproduced this bug):
No, you haven't reproduced this bug. Lucid is using 2.6.32 while this
bug is about kernel 2.6.31. In addition, did you read comment 206;
especially this:Therefore I can only conclude that the problem was with
faulty hardware,
It's not Transmission's fault. I'm a KDE user (so, I use KTorrent),
and I was affected back when this bug was filed (no problems since
though).
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You
* * * I JUST HIT THIS BUG * * *
Yes, I just did it...
I have bought a new SEAGATE HDD, part number ST3500418AS. Formatted as
ext4, with / (40GB), swap (5GB), /home (220GB) and ntfs (220GB).
I installed ubuntu 10.04 and installed all updates.
Then I downloaded the ISO for 10.04.1 via
@DjznBR: No, you haven't reproduced this bug. Lucid is using 2.6.32
while this bug is about kernel 2.6.31. In addition, did you read comment
206; especially this:Therefore I can only conclude that the problem was
with faulty hardware, exasperated by a kernel issue that was fixed
before karmic was
I believe the bug title has been changed once or twice, but let me re-
quote here what Scott reported:
There are worrying reports of filesystem corruption on ext4 in karmic.
Scott says:
12:36 Keybuk this whole ext4 thing is worrying me
12:36 Keybuk I just downloaded an iso image, md5sum didn't
Seems to have been removed. Thankyou, someone.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Changed in: ubuntu-release-notes
Status: Fix Released = Incomplete
** Changed in: linux (Ubuntu Karmic)
Status: Invalid = Incomplete
** Changed in: linux (Ubuntu)
Status: Invalid = Confirmed
** Changed in: linux (Ubuntu Karmic)
Status: Incomplete = Confirmed
**
do not change the status of this bug.
** Changed in: ubuntu-release-notes
Status: Incomplete = Fix Released
** Changed in: linux (Ubuntu)
Status: Incomplete = Invalid
** Changed in: linux (Ubuntu Karmic)
Status: Confirmed = Invalid
--
in-place corruption of large files
So the warning should be removed from the Release Notes...?
http://www.ubuntu.com/getubuntu/releasenotes/910
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because
I'm going to mark this bug as Invalid (I'm the original reporter)
I've not been able to replicate it on production hardware, and not been
able to replicate it on the hardware where I was originally able to
replicate it with karmic as it existed at release time.
Therefore I can only conclude that
Please use the following safer command to dd:
dd if=iso name of=/mount-point-of-ext4-fs/some file name bs=512MB count=1.
Do avoid using the dev partition, as pointed in #200.
Thanks Jordan :)
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on
@TragicWarrior, can you let me know if you encounter the bug with an iso
image ? Also are you still encountering the bug of a corrupted update on
a (i assume safe) reboot ?
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
I have downloaded the iso and calculated the checksums with the current
(2.6.31-19) and the proposed kernel (2.6.31-20) as well. Both of them
matched.
$ wget http://ubuntu.intergenia.de/releases/karmic/ubuntu-9.10-desktop-i386.iso
$ md5sum ubuntu-9.10-desktop-i386.iso
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Surbhi Palande (csurbhi)
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of
@scott, do you still see this bug ? I tested this by doing both an
upgrade and a fresh install + updates and did not seem to run into it.
The md5sum works just fine. If this is still a problem, then I will post
a debug kernel if you are willing to try ?
--
in-place corruption of large files
Can anyone else confirm that this is still a bug in Karmic which is
reproducible by the following steps mentioned in the original report:
1) download an iso
2) compare the md5sum
Thanks !
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
Also, the result of this quick test from anyone who sees this bug, would
be appreciated. If you have a ext3 fs/any other fs on some partition(or
a sufficiently large file which is formated as a fs other than ext4)
then please do the following:
A) ensure that your blocksize if 4096 bytes by
Also forgot to mention that the above comments apply for the following iso
image:
http://releases.ubuntu.com/karmic/ubuntu-9.10-desktop-i386.iso which originally
has the md5sum as follows:
8790491bfa9d00f283ed9dd2d77b3906 (http://releases.ubuntu.com/karmic/MD5SUMS)
--
in-place corruption of
**WARNING** Do not run the dd command in comment #200 **WARNING**
The command should read dd if=iso name
of=/mountpoint/for/ext4/partition/filename bs=512MB count=1
Pointing of= to anything in /dev is wrong, and you should always be very
careful when using dd. Though unlikely, trying to follow
I can confirm this bug with current karmic kernel:
2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
Steps to reproduce:
Download same file with 2 sources in parallel. I took Opera, and wget.
wget
I've yet to see any feedback about the 2.6.31-18 kernel
(karmic-proposed) in this critical bug report, and I find that rather
strange. The proposed -18-kernel has been out for while now and I count
80+ ext4-fixes in the changelog, including a fix for a data corruption
scenario.
I believe I must withdraw my bug report. I have a test case that
reproduces the problem, but it does not seems to be related to ext4, as
turned out today.
I read about 2.6.31-18 here and updated yesterday. But also with the new
kernel I could reproduce the problem. Wondering about that I created
** Changed in: ubuntu-release-notes
Status: Fix Released = Fix Committed
** Changed in: ubuntu-release-notes
Status: Fix Committed = Fix Released
** Description changed:
There are worrying reports of filesystem corruption on ext4 in karmic.
Scott says:
12:36 Keybuk this
There's a fair amount of ext4-fixes in the latest 2.6.31-18.55-kernel in
karmic-proposed, according to the changelog. I suppose it would be worth
testing with that kernel for the people who experience this bug.
--
in-place corruption of large files *without fsck or reboot* reported with linux
** Changed in: ubuntu-release-notes
Status: Fix Released = Incomplete
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs,
This is not incomplete. The issue is documented in the release notes.
** Changed in: ubuntu-release-notes
Status: Incomplete = Fix Released
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You
This is an unfortunate chicken-and-egg scenario. Assuming the latest
kernel in karimc-proposed does fix the problem, how does one safely
upgrade their system since there is a likelihood the very update itself
will get corrupted? The only certain solution would be to (gasp) re-
master the Karmic
Why would the kernel update get corrupted unless the archive or any of
the files it contains are several hundred megabytes in size?
--
Ryan C. Underwood, neme...@icequake.net
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
Ryan,
I believe the large file aspect of the bug is an incorrect
characterization. If you take a look at comment #184, you will see that
I have reproduced the bug on much smaller files.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
You did not say anything about reproducing the bug on smaller files. To
my knowledge this would be the first report of a file smaller than 100MB
being corrupted by this bug.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
On Wed, Jan 27, 2010 at 07:49:06PM -, TragicWarrior wrote:
I believe the large file aspect of the bug is an incorrect
characterization. If you take a look at comment #184, you will see that
I have reproduced the bug on much smaller files.
No, you have reproduced some *other* corruption
Steve,
The original posting mentions files that are 512MB (comment #53). Later
it is assessed at 300MB (comment #89). Then it was whittled down to
120MB (comment #143). Then it went to 45MB (comment #174). I don't
think it would be ideal to open a new bug since so much data has been
captured
On Wed, Jan 27, 2010 at 08:29:43PM -, TragicWarrior wrote:
Why not just re-characterize the bug to match the collected data?
Because the data is not related to the bug that was reported, and it's not
appropriate to hijack bug reports for unrelated issues.
--
Steve Langasek
Steve, I would hardly call changing the description
from:
in-place corruption of large files *without fsck or reboot* reported with
linux 2.6.31-14.46 on ext4
to:
in-place corruption of files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
hardly constitutes hijacking. it's
I have experienced data corruption on 2 different systems using ext4 on
flash media. One of the drives was an Intel SSD drive and the other was
a SanDisk Cruzer USB flash drive. I reproduced the problem several
times with the both of these drives on two different hardware systems.
Here's how I
@Z149: try Applications-Accessories-Disk Usage Alanyzer, which
also can be run from command line as baobab. Push Scan Filesystem
button to see where the space goes to.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
I am also having problems possibly ext4 related.
After clearing up some big files, the 'free space' reported in my ext4 /
filesystem did not decrease.
Emptying the wastebasket and sensible checks have found no cause.
New files added and then deleted and emptied from the wastebasket used up some
My issue seems to be related not to ext4 or my memory but to my swap. I
tried to download 2 times the same 30 Mb files without swap, and this
time it was the same md5.
In addition, I tried to fill my swap partition with zeros, and I have an
error:
% sudo dd if=/dev/zero of=/dev/sda5 bs=1024
The tests on my partitions don't seem to find any problem:
% sudo smartctl -l selftest /dev/sda5
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure
Am 2009-12-24 01:17, schrieb Goffi:
By the way, I made a cmp of the qtmoko files, I have 2 bytes which
differ:
Excellent! Scott, could you also post a cmp -l of a corrupted vs a good
file?
Now, let's have some binary... (Note that cmp -l output is octal)
% cmp -l
Well, for my case I can exonerate ext4: I made two new DL for australia
map, one on my data partition (encrypted ext4), and one on my root
partitition (ext3), the 2 were corrupted :(.
Michael Lazarev I downloaded my first map before 15, and I think the
version I obtained with my script is OK as I
I ran memtest86+ for 9 hours, 10 pass, and still no error...
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I forgot: fsck is OK, and my corrupted files come from network
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Goffi, I think your problem is related to the network part. I have a bug
report about file corruption using samba:
File corruption after copying files via samba from Karmic to Karmic
https://bugs.launchpad.net/bugs/491288
Maybe your problem is similar?
On Wed, Dec 23, 2009 at 15:26, Goffi
Ernst yes probably, but I don't use Samba at all (I only have my
gnu/linux netbook here), and as the problem described here is really
simillar to mine, I was wondering if ext4 was not implicated (maybe
something different happen when files come from network ?).
--
in-place corruption of large
@Goffi: so, all files in which you noticed corruption, come from
network? If not Samba, how do you actually get them? Rsync? Torrent? I
believe these details could help investigate the problem.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on
I got them by downloading throught wget, firefox and chromium (no error during
download).
I had issues for exemple with qtmoko (~ 90 Mb, I had to download it 3 times
from 3 different server before having the good MD5), or the navit australian
map of cloudmade.com (~45 Mb, downloaded 3 times
By the way, I made a cmp of the qtmoko files, I have 2 bytes which
differ:
% md5sum qtmoko-debian-v15*
5381503d377dc27b7bb669aa8f0cb43e qtmoko-debian-v15.jffs2.clean
80d61c5c70f982f6b531d2eb5d536476 qtmoko-debian-v15.jffs2.old
b353553e93ab08d1e22e05d888de qtmoko-debian-v15.jffs2.old2
% cmp
I tried to reproduce this bug with australia.navit.bin.zip, but I
couldn't.
# I got the first copy with firefox, and the second with wget
wget http://downloads.cloudmade.com/oceania/australia/australia.navit.bin.zip
-O ./australia.navit.bin2.zip
diff -bq australia.navit.bin.zip
I experience the same problem. But when I copy files on local disk (I made a
quick script to copy 100 times a file and check md5sum) everything is fine. But
I have really often corrupted files (bad md5) since a while, and memcheck is OK.
I run karmic with 2.6.31-15-generic kernel, my data
I have not encountered this bug so far, with the latest Karmic updates.
I have tried to reproduce it, making about 20 copies of a file which is ~2 GB,
but all the md5sums matched perfectly. I have also tried with some copies of a
~3.5 GB file, with same results.
--
in-place corruption of large
I forgot to mention that I'm using Ubuntu 64bit and that my ext4
partions were created under Jaunty
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a
** Tags added: 2.6.31.8
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I'd like to know it too.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
i believe not...some recent updates must have corrected the problem. You
guys experiencing any corruption lately?
On Sat, Dec 12, 2009 at 7:41 AM, Desh Danz nicol...@libero.it wrote:
I'd like to know it too.
--
in-place corruption of large files *without fsck or reboot* reported with
the bug was solved ?
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I believe I might have hit this bug. I copied a 3GB iso file from NFS to
a local EXT4 partition and noticed that the sha1sum is off (I only
checked because the burned dvd behaved strange). I copied the file again
and then it got the correct sum.
I still have both files and will keep them for a
i wonder if some of the problems people are experiencing are due to a
documentation bug.
http://www.ubuntu.com/getubuntu/releasenotes/910#Switching%20to%20ext4%20requires%20manually%20updating%20grub
makes reference to the ext4 wiki
I have not installed those packages, and I really doubt Scott has either since
I think he maintains them.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because
I don't know if this is related or not: from a conversation I had
before, ext4 divide the files into chunks with power of two size to
prevent long term free space fragmentation, so a 800 MB files would be
written as a 512mb chunk, then 256mb chunk and so on...
--
in-place corruption of large
I've not been able to reproduce this with the most recent kernel
packages
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs,
well, and andy kernel
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
i just installed karmic on a 1TB sataand my flash drive 16GB...lets see
how it goes! both EXT4..if it lets me down, then yall got sum serious
problems..
On Wed, Nov 18, 2009 at 1:13 AM, Nicky Gillette
nickygille...@gmail.comwrote:
I meant that it happens with or without encryption on 9.10
and yes i am doing large transfers of files over 16GBhow do you check
the checksums?
On Wed, Nov 18, 2009 at 2:50 AM, Ram'on McNally ram...@gmail.com
wrote:
i just installed karmic on a 1TB sataand my flash drive 16GB...lets
see how it goes! both EXT4..if it lets me down, then yall
@Ramon
md5sum filename
or
sha256sum filename
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
for checking whole drive and a lot of files I use md5deep:
md5deep -lrk ./* data.md5
sort -k 2 data.md5 data.md5.sort
diff data.md5.sort data.md5.sort.old
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
The different checksums affects me too, I'm using the final release
version of 9.10 on an Intel Celeron on a laptop.
I did RAM tests with a live copy of 8.04, for many hours with no errors, so I
don't think it's bad memory.
8.04 works (with default ext3), 8.04 alt w/ full disk encryption works,
I meant that it happens with or without encryption on 9.10 in the
comment above, if it was unclear.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because you are a
@Ramon
If you use Karmic you can check your whole hard disk with SMART. Check the bad
sector count after an extended test. If there are some it is more likely that
this was the cause then Karmic.
I guess this should be done by everyone who have problems and have
already run memtest.
--
The tool to check S.M.A.R.T in Karmic is called Disk Utility (gnome-
disk-utility) and it is also possible before with the smartmontools.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received
That's what I had use to know I got a bad sector in the first place. I tried
runing the short test and the other one that wasn't extended. All failed
before they could complete bout 90%. Tried just awhile ago and it failed to
continue runing after 10sec, saying cannot read. I jus ran a memtest,
So it looks like your hard disc is defective if even the SMART tests
fail. Only the extended tests checks every sector so it should be
preferred. This has nothing to do with this bug if the hardware fails.
--
in-place corruption of large files *without fsck or reboot* reported with linux
I think I actually *have* seen this...
My setup:
Fileserver, 1.5TB array on JFS bunch of big files (videos mostly, some ISO's
and the like - but none of these files *ever* change)
one client with 400GB internal SATA HDD on ext4, running Karmic with
2.6.31-15-generic AMD64 kernel
one client with
more info from my setup:
i have done memtest on all boxes, everything is fine
network is a wired network (not thinking it should matter, SSH would barf if
packets were coming in with errors,)
the smallest file for which i saw corruption was about 120MB,
the incidence seemed to be about 6 corrupt
oh yes, one more thing,
all fs's were created formatted by the Karmic installer, using the release
media
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
You received this bug notification because
Wow now that's a test!!! I think karmic corrupted my windows7 and two data
partitions. I installed karmic on a brand new 21days old 500GB hard drive.
Been transfering files for 2 weeks from my failing 320GB. After that was
done I tried booting back into windows7, failed. Karmic crashes
Er...this is only for ext4. Win7 does not run on ext4. Sounds like that bad
sector is to blame. Just because it's new doesn't mean it's not broken.
--
in-place corruption of large files *without fsck or reboot* reported with linux
2.6.31-14.46 on ext4
https://bugs.launchpad.net/bugs/453579
I used Karmic to create the partitions, 2 NTFS, SWAP an EXT4. The bad
sector didn't show up until I was doing copying files...so far it says One
bad sector. It just seems ironic this corruption problem is here then this
happens.
On Thu, Nov 12, 2009 at 1:39 AM, Mackenzie Morgan maco...@gmail.com
I see there's a lot of discussion going on about this bug, I'll just
drop in my 5c:
I cleanly installed/updated a x64 Karmic w/ext4 filesystems on my MacBook 5,1
(no other OSes installed).
Due to the nature of my work I downloaded over a dozen ISO's of different
HTTP/FTPs, none of which failed
I am running Karmic 9.10 on a old Pentium 4 computer with PATA drives. I
copied a 2.6 GByte file from an ext4 partition to another ext4
partition, then to a ext2, then to the original ext4. No problem. All
files have the same md5.
--
in-place corruption of large files *without fsck or reboot*
Improperly rebooting runs the risk of breaking your system on *any*
filesystem.
Sorry, but this is not true imho. I have never had a similar problem with ext3.
Yes, there are some file systems like XFS which just deletes the data of a
whole file if the computer crashes or is restarted but I
85 matches
Mail list logo
