From: Ferenc Havasi <havasi@inf.u-szeged.hu>
To: dedekind@oktetlabs.ru
Cc: linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
jffs-dev@axis.com
Subject: Re: JFFS2 mount time
Date: Mon, 25 Oct 2004 17:30:20 +0200 [thread overview]
Message-ID: <417D1C0C.7080709@inf.u-szeged.hu> (raw)
In-Reply-To: <417CDBDD.1010004@oktetlabs.ru>
Hi Artem,
> > To achieve as much mount time speed up as possible I think we should
> > distinguish them.
> This is what I really do not like.
>
> Ok, let us discuss now only this topic. Lt I explain why I believe it is
> vad and very *unnatural* to introduce two or more kinds of blocks.
You are right, it can be unnatural in point of the original design of
the JFFS2. But I think in point of the connection of this optimization
and JFFS2 it is more natural than simple store offsets in the summary,
or copy all the information into it.
Our plan was modify wbuf (make a second one) and modify
jffs2_reserve_space to select the right wbuf and generate summary. Never
planded to introduce new clean_*, dirty_*, ... lists, thats really too
difficult.
> 3. There is write buffer in the JFFS2 which is used in case of NAND. Are
> you going to have two wbufs? This is also significant change.
Yes, we started to implement it yesterday and now agree. It is really
not easy, and we don't write to rewrite the NAND handling part of JFFS2
whithout a real NAND device. Maybe at the design of JFFS3 :)
So you convinced me. We will change the design of summary. The inodes
and dirents will be also in the summary. All other nodes will be copied
as itself into the summary and cause a warning. The summary support will
be a required thing for new node types, too.
In the kernel we will have to modify
1. jffs2_scan_eraseblock(), as it is already in our patch
2. jeb struct to store generated the summary dinamically (one plus field)
3. jffs2_reserve_space(), which will have a new parameter (summary
size), which can be JFFS2_SUMMARY_INODE_SIZE or
JFFS2_SUMMARY_DIRENT_SIZE(namelen). It can decide when to generate
summary and it can do this generation.
4. jffs2_flash_writev(), which is used to write info to flash. It can
parse the node (similar to sumtool) and store the summary of it in its jeb.
If it works we'll check the effect of compressing the summary. (size and
speed)
Comments?
Bye,
Ferenc
P.s.: Thanks for this good conversation.
next prev parent reply other threads:[~2004-10-25 15:26 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 14:26 JFFS2 mount time Ferenc Havasi
2004-10-20 15:26 ` [OBORONA-SPAM] " Artem B. Bityuckiy
2004-10-20 15:49 ` Ferenc Havasi
2004-10-20 15:53 ` Artem B. Bityuckiy
2004-10-21 6:29 ` Artem B. Bityuckiy
2004-10-21 6:54 ` Ferenc Havasi
2004-10-21 7:16 ` Artem B. Bityuckiy
2004-10-21 19:50 ` Ferenc Havasi
2004-10-21 7:30 ` JFFS2 mount time - more Artem B. Bityuckiy
[not found] ` <41776351.4040204@yandex.ru>
2004-10-21 7:39 ` JFFS2 mount time - 3 more questions Ferenc Havasi
2004-10-21 12:49 ` JFFS2 mount time Jarkko Lavinen
2004-10-21 19:11 ` Ferenc Havasi
2004-10-22 9:58 ` Ferenc Havasi
2004-10-21 13:24 ` David Woodhouse
2004-10-21 20:05 ` Ferenc Havasi
2004-10-22 12:44 ` Artem Bityuckiy
2004-10-25 9:36 ` Ferenc Havasi
2004-10-25 10:56 ` Artem Bityuckiy
2004-10-25 15:30 ` Ferenc Havasi [this message]
2004-10-26 9:59 ` Artem Bityuckiy
2004-10-26 10:21 ` Ferenc Havasi
2004-10-26 11:05 ` Artem Bityuckiy
2004-10-26 13:52 ` Ferenc Havasi
2004-10-25 11:21 ` Artem Bityuckiy
2004-10-26 9:29 ` Jarkko Lavinen
2004-10-26 10:24 ` Ferenc Havasi
2004-10-26 10:34 ` Artem Bityuckiy
-- strict thread matches above, loose matches on Subject: below --
2004-12-15 23:19 Gareth Bult (Encryptec)
2004-12-16 0:15 ` Josh Boyer
2004-12-16 1:02 ` Gareth Bult (Encryptec)
2004-12-16 12:53 ` Josh Boyer
2004-12-16 21:22 ` Gareth Bult (Encryptec)
2004-12-16 21:28 ` Josh Boyer
2004-12-16 21:47 ` Gareth Bult (Encryptec)
2004-12-17 12:54 ` Josh Boyer
2004-12-17 15:33 ` Gareth Bult (Encryptec)
2004-12-17 16:02 ` Josh Boyer
2004-12-17 16:46 ` Gareth Bult (Encryptec)
2004-12-17 17:08 ` Artem B. Bityuckiy
2004-12-17 17:10 ` Josh Boyer
2004-12-17 17:26 ` Gareth Bult (Encryptec)
2004-12-17 17:35 ` Josh Boyer
2004-12-17 18:09 ` Gareth Bult (Encryptec)
2004-12-17 19:14 ` jasmine
2004-12-17 20:55 ` Gareth Bult (Encryptec)
2004-12-18 16:02 ` Jörn Engel
2004-12-20 16:34 ` Josh Boyer
2004-12-20 17:12 ` Gareth Bult (Encryptec)
2004-12-21 13:09 ` Jörn Engel
2004-12-21 13:24 ` Gareth Bult (Encryptec)
2004-12-21 13:34 ` Jörn Engel
2004-12-18 16:19 ` Jörn Engel
2004-12-18 17:32 ` Gareth Bult (Encryptec)
2004-12-18 17:52 ` Jörn Engel
2004-12-18 18:11 ` Jörn Engel
2004-12-18 20:48 ` Gareth Bult (Encryptec)
2004-12-19 2:44 ` Jörn Engel
2004-12-21 13:30 ` Jörn Engel
2004-12-21 13:40 ` Gareth Bult (Encryptec)
2004-12-21 15:00 ` David Woodhouse
[not found] ` <1103644945.10792.175.camel@squizzey.bult.co.uk>
2004-12-21 16:04 ` Jörn Engel
2004-12-16 13:43 ` Ferenc Havasi
2004-12-20 16:01 ` Gareth Bult (Encryptec)
2004-12-20 16:09 ` Ferenc Havasi
2004-12-20 16:39 ` Gareth Bult (Encryptec)
2004-12-20 17:48 ` Gareth Bult (Encryptec)
2004-01-13 12:50 Jarkko Lavinen (NMP/Helsinki)
2004-01-13 13:19 ` Joakim Tjernlund
2004-01-13 13:39 ` David Woodhouse
2004-01-13 15:25 ` Kenneth Johansson
2004-01-13 15:30 ` David Woodhouse
2004-01-13 16:21 ` Kenneth Johansson
2004-01-13 17:29 ` Jörn Engel
2004-01-13 17:40 ` Kenneth Johansson
2004-01-13 18:43 ` Jörn Engel
2005-01-04 15:00 ` Steven Scholz
2005-01-05 10:45 ` Artem B. Bityuckiy
2005-01-05 11:10 ` Ferenc Havasi
2005-01-05 11:24 ` Steven Scholz
2005-01-05 11:45 ` Artem B. Bityuckiy
2005-01-06 10:50 ` Ferenc Havasi
2005-01-10 15:14 ` Steven Scholz
2005-01-10 15:25 ` Steven Scholz
2005-01-11 8:26 ` Ferenc Havasi
2005-01-11 8:34 ` Steven Scholz
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=417D1C0C.7080709@inf.u-szeged.hu \
--to=havasi@inf.u-szeged.hu \
--cc=dedekind@oktetlabs.ru \
--cc=dwmw2@infradead.org \
--cc=jffs-dev@axis.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.