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.
next prev parent 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