All of lore.kernel.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 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.