Opened 3 years ago

Closed 3 years ago

#11814 closed defect (fixed)

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@…
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

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

visible
no-page

.( 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" -- )
   parse-word
   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 (6)

comment:1 Changed 3 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
ok

comment:2 Changed 3 years ago by Quozl

  • Action Needed changed from never set to diagnose
  • Cc wmb@… added

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.

comment:3 Changed 3 years ago by Quozl

  • Action Needed 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.

comment:4 Changed 3 years ago by wmb@…

I like svn 2953

comment:5 Changed 3 years ago by Quozl

  • Action Needed changed from review to add to build

Thanks.

comment:6 Changed 3 years ago by Quozl

  • Action Needed changed from add to build to no action
  • Resolution set to fixed
  • Status changed from new to closed

Is in q4d12.

Note: See TracTickets for help on using tickets.