Ticket #11349 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

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

Description

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:

\ OLPC

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

test.sh (3.3 kB) - added by Quozl 3 years ago.
The filesystem was created without -j option, using my earlier script (attached) from which ext2test.sh was derived.

Change History

Changed 3 years ago by wmb@…

I just noticed that the mkfs command in ext2test.sh 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 3 years ago by Quozl

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

Changed 3 years ago by wmb@…

  • owner changed from wmb@… to Quozl
  • next_action changed from diagnose to test in build

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.

Changed 3 years ago by Quozl

  • next_action changed from test in build to no action

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

Changed 3 years ago by Quozl

  • status changed from new to closed
  • resolution set to fixed

Fixed in Q4C12.

Note: See TracTickets for help on using tickets.