public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Aaron Williams <Aaron.Williams@cavium.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ext4: massive corruption with ext4write
Date: Mon, 23 Jul 2018 23:15:59 -0700	[thread overview]
Message-ID: <4113746.3VMvQmSOLp@awilliams-suse> (raw)
In-Reply-To: <1567127.EpJHi1tnkl@awilliams-suse>

Hi all,

It looks like after a certain amount of data has been written that all hell 
breaks loose with the ext4 filesystem.

In my case, I have the following files on a 64G USB thumb drive with two 
partitions, a small FAT partition with the rest of the space dedicated to ext4 
created using mkfs.ext4 /dev/sdg2

total 477632 
-rwxr-xr-x 1 root root 152777216 Jul 23 18:11 Image 
drwx------ 2 root root     16384 Jul 23 18:10 lost+found 
-rwxr-xr-x 1 root root  90706976 Dec 31  1969 test.64 
-rwxr-xr-x 1 root root 152777216 Dec 31  1969 test.img 
-rwxr-xr-x 1 root root        50 Dec 31  1969 test.txt 
-rwxr-xr-x 1 root root   1841408 Jul 23 18:12 u-boot-octeon_ebb7304.bin 
-rwxr-xr-x 1 root root  90706976 Jul 23 18:11 vmlinux.64

Everything is fine until I wrote the file test.64, which is basically a copy 
of vmlinux.64.

The first few files were written using my host Linux system, namely Image, u-
boot-octeon_ebb7304.bin and vmlinux.64.

From within U-Boot I performed the following commands:

# ext4load usb 0:2 $loadaddr Image
# ext4write usb 0:2 $fileaddr /test.img $filesize
# tftpboot $loadaddr test.txt
# ext4write usb 0:2 $fileaddr /test.txt $filesize
# ext4load usb 0:2 $loadaddr vmlinux.64
# ext4write usb 0:2 $fileaddr /test.64 $filesize

Everything is fine on the drive until I write test.64. At this point, I get a 
huge list of errors:

# fsck.ext4 -v -n /dev/sdg2 
e2fsck 1.42.11 (09-Jul-2014) 
Group descriptor 0 has invalid unused inodes count 57374.  Fix? no 

/dev/sdg2 contains a file system with errors, check forced. 
Pass 1: Checking inodes, blocks, and sizes 
Deleted inode 130913 has zero dtime.  Fix? no 

Inode 130915 is in use, but has dtime set.  Fix? no 

Inode 130915 has imagic flag set.  Clear? no 

Inode 130915 has a extra size (8223) which is invalid 
Fix? no 

Inode 130916 is in use, but has dtime set.  Fix? no 

Inode 130916 has imagic flag set.  Clear? no 

Inode 130916 has a extra size (8223) which is invalid 
Fix? no

...
Illegal block #11 (2435760161) in inode 131070.  IGNORED. 
Illegal indirect block (4026556192) in inode 131070.  IGNORED. 
Illegal double indirect block (2433138721) in inode 131070.  IGNORED. 
Illegal triple indirect block (2434195456) in inode 131070.  IGNORED. 
Error while iterating over blocks in inode 131070: Illegal triply indirect 
block found


and many many more errors.

Note that I am using the very latest ext4 code from the master branch.  This 
is not a USB problem because I can reproduce this problem with an SD card.  
This problem also occurs on two different platforms, one being aarch64 little 
endian and the other being MIPS64 big endian.  The filesystem code is 
identical since the latest code has been backported to our older MIPS 
bootloader.

My guess is that all hell is breaking loose when a file spans multiple block 
groups.

-Aaron Williams

On Thursday, July 19, 2018 7:35:46 PM PDT Aaron Williams wrote:
> 
> Hi all,
> 
> I am sometimes seeing issues when using ext4write where fsck later
> complains
 that the group descriptor has an invalid number of unused
> inodes. Is this a known problem?
> 
> Also, I think the assert(offset == sizeof(*desc)); in
> ext4fs_checksum_update()
 is invalid since with ext4 the descriptor is
> larger than the offset. When debugging was enabled I'd always hit this
> assert.
> 
> Also, in ext4fs_write, the debug statement should say blocks and not bytes.
> 
> -Aaron
> 
> --
> Aaron Williams
> Senior Software Engineer
> Cavium, Inc.
> (408) 943-7198  (510) 789-8988 (cell)
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

-- 
Aaron Williams
Senior Software Engineer
Cavium, Inc.
(408) 943-7198	(510) 789-8988 (cell)

  reply	other threads:[~2018-07-24  6:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20  2:35 [U-Boot] ext4: Issue with ext4write Aaron Williams
2018-07-24  6:15 ` Aaron Williams [this message]
2018-07-24  6:25   ` [U-Boot] ext4: massive corruption " Aaron Williams
2018-07-24  9:45     ` Marek Vasut
2018-07-25  2:05       ` Aaron Williams
2018-07-25  7:55         ` [U-Boot] Cavium Octeon support for u-boot Chris Packham
2018-08-21  6:07           ` Aaron Williams
2018-08-21 12:57             ` Alexander Graf
2018-08-21 22:00               ` Suneel Garapati
2018-08-22  7:46                 ` Alexander Graf
2018-07-26 13:32         ` [U-Boot] ext4: massive corruption with ext4write Wolfgang Denk
2018-07-24 10:53     ` Aaron Williams

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=4113746.3VMvQmSOLp@awilliams-suse \
    --to=aaron.williams@cavium.com \
    --cc=u-boot@lists.denx.de \
    /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