From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 an nodes checking
Date: Tue, 28 Sep 2004 17:17:37 +0400 [thread overview]
Message-ID: <41596471.5020108@yandex.ru> (raw)
In-Reply-To: <1096375038.30942.30.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> Bear in mind that we discard nodes with invalid data_crc. So they do not
> obsolete _older_ nodes which cover the same area. If we don't check the
> CRC we can't build up the red-black tree for the inode in the same way
> we do at the moment, because we don't actually know which nodes are
> valid. We'd have to invent another kind of data structure, in which we
> could keep information about overlapping nodes, some of which may turn
> out not to be valid.
Oh, I missed this aspect! Thanks.
As I understand if we disable the CRC checking at the iget() request, we
will lost the JFFS2 some "logging" capabilities.
For example, if the power is off during the new node write operation, we
don't lost older data since the older node's data will be used. But if
we won't check the data CRC, we will have all zeros in the correspondent
piece of the file (the hole node).
Ok. But what if we check only last node (with the highest version) and
if it is OK, don't check anything more? If it is bad, check previous,
and so on. It seems for me, these checks are enough. We cover the
situation with unexpected power losses.
There are some scenarios, where we will lost some data. For example,
some sector on the flash device becomes bad, and we lost a node which is
situated on this sector. If there is older node for this data range, the
current implementation will use it. But in this case I am not sure that
the data from the older node is better than just zeros. Are such flash
faults JFFS2's business?
What do you think?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-09-28 13:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 12:29 JFFS2 an nodes checking Artem B. Bityuckiy
2004-09-28 12:37 ` David Woodhouse
2004-09-28 13:17 ` Artem B. Bityuckiy [this message]
2004-09-28 13:22 ` David Woodhouse
2004-09-28 13:37 ` Artem B. Bityuckiy
2004-09-28 13:45 ` David Woodhouse
2004-09-28 13:57 ` Artem B. Bityuckiy
2004-09-28 14:04 ` David Woodhouse
2004-09-28 14:26 ` Artem B. Bityuckiy
2004-09-28 14:37 ` David Woodhouse
2004-09-28 14:58 ` Artem B. Bityuckiy
2004-09-28 15:04 ` David Woodhouse
2004-09-28 14:31 ` Josh Boyer
2004-09-28 14:47 ` Artem B. Bityuckiy
2004-09-28 14:58 ` David Woodhouse
2004-09-28 16:48 ` Artem B. Bityuckiy
2004-09-28 16:57 ` Josh Boyer
2004-09-28 16:58 ` David Woodhouse
2004-09-28 17:15 ` Artem B. Bityuckiy
2004-09-28 18:24 ` Josh Boyer
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=41596471.5020108@yandex.ru \
--to=abityuckiy@yandex.ru \
--cc=dwmw2@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox