Ticket #11814 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

ext2 filesystem flush fails with 0 attempt to corrupt superblock or group descriptor

Reported by: Quozl Owned by: Quozl
Priority: normal Milestone: 1.75-firmware
Component: ofw - open firmware Version: Development firmware
Keywords: Cc: wmb@…
Action Needed: no action Verified: no
Deployments affected: Blocked By:


In Open Firmware, if a reasonable amount of data is written to a file on the ext2 filesystem on a USB drive, the close flush fails with a message:

0 attempt to corrupt superblock or group descriptor

Reproducer on a 128MB USB flash drive created using ext2test.sh:

\ OLPC boot script


.( test 0025 space released after delete ) cr

0 value fd
0 value buf
d# 1024 dup * constant /buf
d# 32 value big

: make-big-file  ( "file" -- )
   r/w open-file abort" can't open file" to fd
   /buf alloc-mem to buf
   buf /buf erase
   big 0 do  buf /buf fd fputs  [char] . emit  loop
   buf /buf free-mem
   fd close-file abort" can't close file"

make-big-file u:\big

Q4D11 XO-1.75 os884

Change History

Changed 2 years ago by Quozl

Also occurs on internal eMMC first partition. This time with bbug? set true:

ok make-big-file int:\big
r 5 
r 105 
r 5 
r 4 
r 8 
r 105 
r 2002 
r 6002 
r a002 
r e002 
W e002 
W a002 
W 6002 
W 2002 
W 105 
W 8 
W 4 
r 5 
r 105 
r 8 
r 0 
.0 attempt to corrupt superblock or group descriptor

Changed 2 years ago by Quozl

  • cc wmb@… added
  • next_action changed from never set to diagnose

Reading physical block zero into the blocks cache is a prelude to the problem.

Two call chains result in a read of physical block zero:

  • Callers: d.block j-read-file-block ext2fsfread (of logical block zero) ... set-line-delimiter ... open-file,
  • Callers: d.block write-file-block ext2fsfwrite (of logical block zero) ... fputs.

>pblk-adr has correctly processed logical block zero and returned the address of the inode block list. But >d.pblk# has returned a ( 0 true ) because no blocks are allocated to the inode at the time.

The first call chain can be fixed in ext2fsread by returning zero bytes read when dfile-size shows zero.

The second call chain I'm not sure about, I need help understanding what is going on. Perhaps the solution needs to be deeper.

Changed 2 years ago by Quozl

  • next_action changed from diagnose to review

The writing of zero blocks matters. In write-file-block these are not allocated to filesystem blocks. The inode block list is left empty by design.

The fix is to interpret physical block zero in the inode block list as "there is no physical block for this logical block."

svn 2953 for review.

Changed 2 years ago by wmb@…

I like svn 2953

Changed 2 years ago by Quozl

  • next_action changed from review to add to build


Changed 2 years ago by Quozl

  • status changed from new to closed
  • next_action changed from add to build to no action
  • resolution set to fixed

Is in q4d12.

Note: See TracTickets for help on using tickets.