From: Artem Bityuckiy <dedekind@oktetlabs.ru>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
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 14:56:29 +0400 [thread overview]
Message-ID: <417CDBDD.1010004@oktetlabs.ru> (raw)
In-Reply-To: <417CC91D.6060002@inf.u-szeged.hu>
Hello Ferenc,
> Yes, I think there are three kinds of nodes:
> - type A contains relevant amount of data which is not needed at mount
> time (jffs2_raw_inode)
> - type B is (almost) fully needed at mount time (jffs2_raw_dirent)
> - type C is any other (unkown, developements in the future...)
>
> 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.
The example of JFFS2 change that I consider natural is the introduction
of new node type. It is natural, because of when JFFS2 was designed,
this possibility was foreseen and taken into account. It is relatively
easy to do this. It is possible to do this and do not affect other
things in the JFFS2.
Conversely, the introducing several block types was not foreseen in the
JFFS2 design. And all things in the JFFS2 are coded with the assumption
all the blocks are equivalent.
This is my point view on the issue in general.
Now I will try to illustrate why I think so.
1. In JFFS2 there are several lists of blocks - clean_list, dirty_list,
very_dirty_list?. Are you going to introduce clean_list_typeA,
dirty_list_typeA, very_dirty_list_typeA, clean_list_typeB,
dirty_list_typeB, very_dirty_list_typeB ?
2. Just do 'grep "_list" * | grep -e "\(dirty\)\|\(very\)"' and see how
many places in JFFS2 where these lists are changed. Do you think it is
natural to introduce 3 more lists? I believe not. What if somebody else
will introduce one more type of block?
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.
4. Now the GC just gives one block, and moves all the valid nodes to
another one. In your case (if you have the JFFS2 image which was created
by older code, without your patch, where all node types are mixed),
you will need to move one type of nodes to one block, another to the
another block.
So, I think you will be needed to change many things in JFFS2. You have
a risk to hit on a can of worms.
So, do you agree that this change is *unnatural* ?
===================================================================
>> 4. It seems for me you will need to increase the number of blocks
>> which are reserved for the garbage collection (double ?). This is also
>> minor drawback.
> I don't understand what do you mean here
I mean the sb->resv_blocks_gcmerge and related. You will need to
increase it, which is not very good.
--
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind@oktetlabs.ru, web: http://www.oktetlabs.ru
next prev parent reply other threads:[~2004-10-25 10:56 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 [this message]
2004-10-25 15:30 ` Ferenc Havasi
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=417CDBDD.1010004@oktetlabs.ru \
--to=dedekind@oktetlabs.ru \
--cc=dwmw2@infradead.org \
--cc=havasi@inf.u-szeged.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox