All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven <svenjaborek@gmx.de>
To: linux-mtd@lists.infradead.org
Subject: JFFS2: truncated files after power loss scenario
Date: Sun, 06 Feb 2011 15:59:44 +0100	[thread overview]
Message-ID: <1297004384.2084.9.camel@hbox> (raw)

Hi mtd list,

What is the expected behavior for files beeing written on a jffs2 (on
nand) during a power loss? Would an incomplete file exist, or would the journaling do a roll back
because of an incomplete transaction?
Is there a difference with new files created, or existing files beeing modified?

My tests show that on next bootup the file exists, but is truncated. I have not seen any journaling related roll backs.

I took a look at this, because we have seen a truncated configuration file once. I'm not sure what caused this. Perhaps a power loss during write.

What do you think about the following jffs2dump?:
( dwnld.conf was created once by extracting it from an archive,
  it might have been modified afterwards. (fopen "w+"; fprintf; close),
  the file existed afterwards, but was truncated in to 4k,
  then during error analysis the file was renamed "mv dwnld.conf
dwnld.conf.org" and a new file dwnld.conf was created there)

Dirent     node at 0x00346f2c, totlen 0x00000032, #pino    41, version    23, #ino        42, nsize       10, name dwnld.conf
Dirent     node at 0x003e63e8, totlen 0x00000032, #pino    41, version     5, #ino        42, nsize       10, name dwnld.conf
Dirent     node at 0x009c19e0, totlen 0x00000032, #pino    41, version    28, #ino      2484, nsize       10, name dwnld.conf
Dirent     node at 0x009fc398, totlen 0x00000036, #pino    41, version    27, #ino        42, nsize       14, name dwnld.conf.org
Inode      node at 0x003e63a4, totlen 0x00000044, #ino     42, version     1, isize        0, csize        0, dsize        0, offset 0
Inode      node at 0x003e641c, totlen 0x000005d8, #ino     42, version     2, isize     4096, csize     1428, dsize     4096, offset 0
Inode      node at 0x003e69f4, totlen 0x000006f5, #ino     42, version     3, isize     8192, csize     1713, dsize     4096, offset 4096
Inode      node at 0x003e70ec, totlen 0x0000028f, #ino     42, version     4, isize     9445, csize      587, dsize     1253, offset 8192
Inode      node at 0x003e737c, totlen 0x00000044, #ino     42, version     5, isize     9445, csize        0, dsize        0, offset 0
Inode      node at 0x003e73c0, totlen 0x00000044, #ino     42, version     6, isize     9445, csize        0, dsize        0, offset 0
Inode      node at 0x003e7404, totlen 0x00000044, #ino     42, version     7, isize     9445, csize        0, dsize        0, offset 0
Inode      node at 0x009bcba8, totlen 0x000005d8, #ino     42, version     9, isize     4096, csize     1428, dsize     4096, offset 0
Inode      node at 0x00e51ea0, totlen 0x000005d8, #ino     42, version     9, isize     4096, csize     1428, dsize     4096, offset 0

I reproduced a good-case of the actions on the file with a fresh filesystem:
Dirent     node at 0x00364e3c, totlen 0x00000032, #pino    41, version    11, #ino        42, nsize       10, name dwnld.conf
Dirent     node at 0x00553000, totlen 0x00000036, #pino    41, version    12, #ino        42, nsize       14, name dwnld.conf.org
Dirent     node at 0x00553038, totlen 0x00000032, #pino    41, version    13, #ino         0, nsize       10, name dwnld.conf
Dirent     node at 0x00555844, totlen 0x00000032, #pino    41, version    14, #ino      1171, nsize       10, name dwnld.conf
Inode      node at 0x00364e70, totlen 0x00000044, #ino     42, version    10, isize     9445, csize        0, dsize        0, offset 0
Inode      node at 0x00449cb4, totlen 0x000005d8, #ino     42, version     2, isize     4096, csize     1428, dsize     4096, offset 0
Inode      node at 0x0044a2c8, totlen 0x000006f5, #ino     42, version     3, isize     8192, csize     1713, dsize     4096, offset 4096
Inode      node at 0x0044accc, totlen 0x0000028f, #ino     42, version     4, isize     9445, csize      587, dsize     1253, offset 8192
Inode      node at 0x0096e1c4, totlen 0x00000044, #ino     42, version    11, isize        0, csize        0, dsize        0, offset 0
Inode      node at 0x0096e208, totlen 0x000005d8, #ino     42, version    12, isize     4096, csize     1428, dsize     4096, offset 0
Inode      node at 0x0096e7e0, totlen 0x000006f5, #ino     42, version    13, isize     8192, csize     1713, dsize     4096, offset 4096
Inode      node at 0x0096eed8, totlen 0x0000028f, #ino     42, version    14, isize     9445, csize      587, dsize     1253, offset 8192


I wonder about the Inode #42 Version 5 to 9 and about why two Dirent exist(ed) for #ino 42.
Do you think this was caused by a power loss scenario?

The truncated file error happened on a 2.6.18 based kernel.
I have done power loss tests on 2.6.34, which showed truncated files as well.

regards, Sven Jaborek

             reply	other threads:[~2011-02-06 14:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 14:59 Sven [this message]
2011-02-06 15:25 ` JFFS2: truncated files after power loss scenario Artem Bityutskiy
2011-02-06 15:47   ` Sven
2011-02-06 16:03     ` Artem Bityutskiy
2011-02-06 17:12       ` Albrecht Dreß
2011-02-06 17:39         ` Artem Bityutskiy
2011-02-06 18:40           ` Albrecht Dreß
2011-02-11 14:00             ` Artem Bityutskiy

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=1297004384.2084.9.camel@hbox \
    --to=svenjaborek@gmx.de \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.