public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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.

  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