public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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.

  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