All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.