From: Sergei Poselenov <sposelenov@emcraft.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS: file data corruption during the power cut-off test
Date: Sun, 09 Jun 2019 11:18:03 +0300 [thread overview]
Message-ID: <a43eb232a51b7d0c95623de9403158c290163237.camel@emcraft.com> (raw)
In-Reply-To: <766367078.85018.1559983598342.JavaMail.zimbra@nod.at>
Hello Richard,
Thank you for your patience. OK, I'll try to describe my real test case
once again, below.
1. On my system, /mnt/data1 is a UBI partition mounted with the "sync"
option on NAND device.
2. Initially, the partition is empty.
3. I do:
/mnt/data1 # for i in `seq 0 99`; do
> dd if=/bin/busybox of=test${i}; done
4. I do a power cut-off during the loop above.
5. After restoring the power, the system reboots and recovers the UBI
partition successfully. Here is what I have there now:
~ # ls -l /mnt/data1
-rw-r--r-- 1 root root 430519 Jan 1 00:00 test0
-rw-r--r-- 1 root root 430519 Jan 1 00:04 test1
-rw-r--r-- 1 root root 430519 Jan 1 00:04 test2
-rw-r--r-- 1 root root 430519 Jan 1 00:04 test3
-rw-r--r-- 1 root root 286720 Jan 1 00:04 test4
6. The test0-test3 files above are exact replicas of the initial image
/bin/busybox. "test4" is incompletely written, as expected.
7. Let's check the data at the end of the last partially written file
test4:
# hexdump test4.hex
...
0045dd0 0004 e1a0 81f0 e8bd 9ba0 0007 3014 e59f
0045de0 4010 e92d 4000 e593 0008 e594 ffa9 ebff
0045df0 0008 e584 8010 e8bd 9ba0 0007 0000 e151
0045e00 0000 0000 0000 0000 0000 0000 0000 0000
*
0046000
#
As you can see, the last 512 bytes starting from 0x0045e00 are zeroes.
Let's check the data by this offset in the original file /bin/busybox:
0045dd0 0004 e1a0 81f0 e8bd 9ba0 0007 3014 e59f
0045de0 4010 e92d 4000 e593 0008 e594 ffa9 ebff
0045df0 0008 e584 8010 e8bd 9ba0 0007 0000 e151
-> 0045e00 40f8 e92d 3000 31a0 4000 e1a0 4001 31a0
0045e10 1003 31a0 0001 e1a0 ff8d ebff 3044 e59f
0045e20 5000 e3a0 6000 e593 7000 e1a0 0007 e154
0045e30 000a 8a00 3004 e596 3001 e243 0003 e154
0045e40 0006 8a00 0004 e1a0 ff81 ebff 3000 e5d0
0045e50 4001 e280 000a e353 5001 0285 fff2 eaff
0045e60 0005 e1a0 80f8 e8bd 9ba0 0007 3000 e3e0
0045e70 40f7 e92d 5001 e1a0 3000 e581 1000 e5d0
0045e80 4000 e1a0 002e e351 3130 059f 4001 0280
...
Now, the question: why are these 512 bytes of zeros in test4?
Extrapolating to a real use case, consider a system writing a log file
to the UBI partition. Power cutoff, recovery, and we have a garbage at
the end of the log file. Is this expected?
Thanks!
Regards,
Sergei
On Sat, 2019-06-08 at 10:46 +0200, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Not actually, I'm afraid. I don't see how overwriting a file is
> > relevant here. Definitely, I don't do power cut during "dd if=test2
> > of=test0 conv=notrunc". At the moment of power cut-off, test2 has
> > been
> > created from scratch and has some data written to it, with more
> > writes in
> > progress.
>
> I'm sorry, but I'm really confused now.
>
> Please share your real test case, with real results and what you
> expect.
> No guesswork, no simplified pseudo code. :-)
>
> Otherwise we have little chance to sort this out.
> Also read what Steve wrote.
>
> Thanks,
> //richard
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-06-09 8:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 9:10 UBIFS: file data corruption during the power cut-off test Sergei Poselenov
2019-06-06 14:55 ` Richard Weinberger
2019-06-06 18:08 ` Sergei Poselenov
2019-06-06 18:13 ` Richard Weinberger
2019-06-07 14:23 ` Sergei Poselenov
2019-06-07 16:01 ` Steve deRosier
2019-06-09 8:32 ` Sergei Poselenov
2019-06-09 15:25 ` Steve deRosier
2019-06-07 16:02 ` Richard Weinberger
2019-06-08 6:42 ` Sergei Poselenov
2019-06-08 8:46 ` Richard Weinberger
2019-06-09 8:18 ` Sergei Poselenov [this message]
2019-06-09 8:53 ` Richard Weinberger
2019-06-09 9:59 ` Sergei Poselenov
2019-06-09 10:00 ` Richard Weinberger
2019-06-15 7:26 ` Sergei Poselenov
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=a43eb232a51b7d0c95623de9403158c290163237.camel@emcraft.com \
--to=sposelenov@emcraft.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox