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 18:26:32 +0400	[thread overview]
Message-ID: <41597498.7090704@yandex.ru> (raw)
In-Reply-To: <1096380254.30942.77.camel@hades.cambridge.redhat.com>

David Woodhouse wrote:
> On Tue, 2004-09-28 at 17:57 +0400, Artem B. Bityuckiy wrote:
> 
>>Sorry, I don't understand. Suppose, after unclean reboot the bad last 
>>node appears. Before any write, this last node will be detected *before 
>>write* since the iget() will be called before it. Is it?
> 
> 
> True, but it won't necessarily be _deleted_ so it could still be there
> on the _next_ boot.
Yes, you are right. But we may handle this situation. Suppose we've 
found that the last node is bad. In this can we write new node 
containing the same data area (the area range is known since the header 
CRC is good). Thus, that last bad node will be obsoleted and the new 
last node will be good. If there are will be new unclean reboot, we will 
have two bad nodes at the end.
Only after obsoleting last bad node we allow new writes.

What do you think now? :-)

> 
> You have to make the read/write code capable of dealing with the fact
> that the full rbtree hasn't been built. Possibly you sort through the
> raw nodes and put them into _pools_, each covering something like a
> 256KiB of the file. Then when you get a read or write of any such range,
> you check the CRCs for the nodes in that _range_ and build the full map
> only for that range of the file. It sounds painful, to be honest -- I'd
> rather just tell people not to use such large files on JFFS2 -- split it
> up into multiple files instead.
> 

I'm really going to do such the optimization and your idea is 
complicated enough. I'd like to find easier solution and don't introduce 
additional complicated things to the already complicated file system :-) 
Ok, I'll think on this problem.

For now, the Idea with checking only the last node seems to me better. 
But I didn't think enough about it yet.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

  reply	other threads:[~2004-09-28 14:27 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
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 [this message]
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=41597498.7090704@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