From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: Ferenc Havasi <havasi@inf.u-szeged.hu>
Cc: dwmw2@infradead.org, linux-mtd@lists.infradead.org
Subject: Re: [OBORONA-SPAM] JFFS2 mount time
Date: Wed, 20 Oct 2004 19:26:36 +0400 [thread overview]
Message-ID: <417683AC.6000400@yandex.ru> (raw)
In-Reply-To: <41767593.9030004@inf.u-szeged.hu>
Ferenc,
I didn't investigate your patch well yet, but after 3 minuets of looking
to it I have two questions:
1. Why did you introduce the JFFS2_SUM_MAGIC constant? As I understand,
the node's magic field is needed to identify the *beginning of node*,
*not the node type*. The type of node is defined by the next field,
called 'nodetype'. You use it (JFFS2_NODETYPE_INODE_SUM). So, IMHO, the
JFFS2_SUM_MAGIC constant doesn't fit into the common rules...
2. This is very minor of course, just a remark. IMHO, its better to
avoid too many ifdefs, so, I think it is unnecessary to place the
function prototype under ifdef. I mead:
+#ifdef CONFIG_JFFS2_FS_SUMMARY
+static struct jffs2_inode_cache *jffs2_scan_make_ino_cache(struct
jffs2_sb_info *c, uint32_t ino);
+#endif
Ferenc Havasi wrote:
> Dear All,
>
> Here is the latest version of our mount time improvement.
>
> Using of it:
> - apply this patch on the latest version of MTD
> - compile sumtool (make command in mtd/util)
> - make your JFFS2 image as before (or you can use already created images
> as well)
> - run sumtool to insert summary information, for example:
> ./sumtool -i original.jffs2 -o new.jffs2 -e128KiB
> - recompile your kernel with "JFFS2 inode summary support"
>
> Jarkko made a measurement on a real NAND device: his JFFS2 image was
> 120819928 (115M), after running sumtool the new image was 123338752 (117M).
>
> Using the original mount time was 55 sec, with the new image it is only
> 8.5 sec.
>
> It works very similar as our previous improvement: stores special
> information at the end of the erase blocks, and at mount time if there
> is this kind of information the scaning of the erase block is unneccessary.
>
> New things compared to our previous improvement:
> - it was fully rewritten
> - we separated the user space tool from mkfs. (sumtool)
> - sumtool now not only inserts the summary information but also make
> some node-reordering. There will be two kind of erase blocks: in the
> "first type" there will be only jffs2_raw_inodes, and all other node
> (jffs2_raw_dirent) will be stored in the "second type". It generates
> summary at the end of all "fist type" eraseblock. (the "second type"
> will be scanned as before, because all information is needed in
> jffs_raw_dirent at mount time)
>
> Ceratinly all of these things are optional (as you can see above you
> have to select it from kernel config). The JFFS2 image produced by
> sumtool is also usable with previous kernel because the summary node is
> JFFS2_FEATURE_RWCOMPAT_DELETE.
>
> I think it can be usefull not only for us. David, may I commit it to the
> CVS?
>
> Regards,
> Ferenc
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-10-20 15:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 14:26 JFFS2 mount time Ferenc Havasi
2004-10-20 15:26 ` Artem B. Bityuckiy [this message]
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
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
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=417683AC.6000400@yandex.ru \
--to=abityuckiy@yandex.ru \
--cc=dwmw2@infradead.org \
--cc=havasi@inf.u-szeged.hu \
--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