public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: "Kornel Masłowski" <maslow@pf.pl>
Cc: linux-mtd@lists.infradead.org
Subject: Re: jffs2
Date: Tue, 28 Sep 2004 10:34:12 +0400	[thread overview]
Message-ID: <415905E4.1020601@yandex.ru> (raw)
In-Reply-To: <000701c4a4c3$822d6e90$0b0aa8c0@maslow>

Kornel Masłowski wrote:
> I'm not sure how jffs2 works.
> I have jffs2 on  8bit NAND flash (page 512 B).
> I want to append record 32B to the file on flash which current size is 
> 10kB.
> Flash device is almost empty.
> How many pages will be written by jffs2?
> 
> 
It is hard to calculate because of compression. Moreover, if your file 
was created by
seek to "nowhere" it will cosist of only one "hole" node and fit into 
one NAND page only.

If there is no compression, the exact number of pages also depends on 
how your file was created. Also, there is some platform dependency - 
does you platform has 4K RAM pages? - but this is minor since most 
platforms have 4K RAM pages.

If your 10K file was created by one go and there is no compression, the 
file will consist of 3 JFFS2 nodes (4K + 4K + 2K) and fit into 9 + 9 + 5 
= 23 NAND pages (4K data = 4 NAND pages and one is needed for node 
header; the rest of page won't be used since the next node isn't fit to it).

When you append 32 bytes, one more page will be used (24 total). But if 
your append just after 10K file creation (i.e, the JFFS2 write buffer 
hasn't yet been written to the NAND flash media), the 32B appendix node 
will be added to the 23-th page and there will be only 23 used pages.

If the compression is on, there ought to be fewer used NAND pages.

Ok, this is theory (I didn't check) and my own understanding of how 
JFFS2 works. I might make mistakes :-)

You may check this by creating/appending your file and then calculating 
the numbur of used pages. The nanddump utility may be used.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

  reply	other threads:[~2004-09-28  6:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-27 18:55 jffs2 Kornel Masłowski
2004-09-28  6:34 ` Artem B. Bityuckiy [this message]
2004-09-28  6:54   ` [OBORONA-SPAM] jffs2 Artem B. Bityuckiy
2004-09-28 11:22   ` jffs2 Artem B. Bityuckiy
  -- strict thread matches above, loose matches on Subject: below --
2006-08-17 18:52 jffs2 Katey Yu
2006-03-07 19:03 jffs2 trimarchi
2006-03-07 19:12 ` jffs2 Josh Boyer
2006-03-08 12:56   ` jffs2 Michael Trimarchi
2006-03-08 16:08     ` jffs2 Ferenc Havasi
2001-06-06 11:25 jffs2 Kári Davíðsson
2001-06-01 16:12 JFFS2 Herman Oosthuysen
2001-06-01 20:27 ` JFFS2 Vipin Malik
2001-06-01 11:55 jffs2 Kári Davíðsson
2001-06-01 14:55 ` jffs2 Vipin Malik

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=415905E4.1020601@yandex.ru \
    --to=abityuckiy@yandex.ru \
    --cc=linux-mtd@lists.infradead.org \
    --cc=maslow@pf.pl \
    /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