Opened 5 years ago

Closed 5 years ago

#11349 closed defect (fixed)

XO-1.75 Q4B12ja (svn 2623) leaves an ext2 filesystem inconsistent after a file delete

Reported by: Quozl Owned by: Quozl
Priority: low Milestone: Opportunity
Component: ofw - open firmware Version: Development firmware
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no


After test 0023 glob file copy in the ext2test.fth the filesystem is left in an inconsistent state as reported by e2fsck on build 881:

bash-4.1# e2fsck -f /dev/sda1
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'f.tst' in / (2) has deleted/unused inode 26.  Clear<y>? 

It is the last file deleted in the script that is affected.

Tested on a 128MB and a 2GB USB flash drive.

The minimum reproducer is an olpc.fth file containing:


to-file u:\f.tst cr
del u:\f.tst

Adding a dir u:\ command to the end of the reproducer prevents the symptom. Theory: a cache is flushed.

Entering the commands interactively instead of using \boot\olpc.fth makes no difference to the symptom.

Deleting a pre-existing file does not produce the symptom.

Attachments (1) (3.3 KB) - added by Quozl 5 years ago.
The filesystem was created without -j option, using my earlier script (attached) from which was derived.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 5 years ago by wmb@…

I just noticed that the mkfs command in is using the -j option, thus creating a journal and making it ext3. OFW doesn't support ext3 with dirty journals (I'm working on that feature right now, but existing releases don't do journals). If the journal is dirty, OFW will definitely have problems with the file system.

Changed 5 years ago by Quozl

The filesystem was created without -j option, using my earlier script (attached) from which was derived.

comment:2 Changed 5 years ago by wmb@…

  • Action Needed changed from diagnose to test in build
  • Owner changed from wmb@… to Quozl

Fixed by svn 2795. The problem was actually in the file-system-independent "$delete1" command; it was leaving a handle open, preventing data from being flushed at a much later time.

comment:3 Changed 5 years ago by Quozl

  • Action Needed changed from test in build to no action

Reproduced on Q4C11. Tested fixed in Q4C11ja. Thanks! Closing.

comment:4 Changed 5 years ago by Quozl

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in Q4C12.

Note: See TracTickets for help on using tickets.