public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: linux-mtd@lists.infradead.org
Subject: Question about JFFS2 space overhead
Date: Wed, 11 Jan 2006 21:12:59 +0000	[thread overview]
Message-ID: <20060111211259.GA27357@mail.shareable.org> (raw)

I have a 1MB partition (on an 8MB chip), on which I'm using JFFS2.
The kernel is 2.4.26-uc0 (uclinux), with patches.

The intention is to store some executables, configuration and scripts
which have to be updated occasionally, and logs which must be updated
regularly.

I'm rather surprised to find it reporting as full sometimes.

According to du, it has 510k of data on it right now.
According to df, it has 916k (108 available, 1024 total).

    # du -s /mnt/flash
    510     /mnt/flash
    # df /mnt/flash
    Filesystem           1k-blocks      Used Available Use% Mounted on
    /dev/mtdblock/2           1024       916       108  89% /mnt/flash

When I try to do little things like touching a file, or even setting
timestamps on existing files, it reports "No space left on device".

Is this due to the space required for garbage collection?

In the JFFS2 paper at
http://sourceware.org/jffs2/jffs2-html/node4.html#SECTION00042000000000000000
it says:

    A major annoyance for users is the amount of space currently required
    to be left spare for garbage collection. It is hoped that a formal
    proof of the amount of required space can be produced, but in the
    meantime a very conservative approach is taken -- five full erase
    blocks must be available for writing before new writes will be
    permitted from user space.

This chip has 64k erase blocks, so that would be 320k of space
consumed for eraseblocks.  Is that why I can't write the smallest
thing when the 1024k filesystem has only 510k of data?  And that
doesn't explain (to me) why the filesystem reports 916k usage.

My most important question is: how much data can I reliably store on a
1MB JFFS2 partition, before I might see write errors?  At the moment,
I don't know how big I need the partition to be, because I don't know
how much space files can effectively take after many writes.  Most of
the time, I have no problem with these files, or indeed larger ones.
It is only occasionally, after several updates, that it gets into this
state.

>From the paper which mentions 5 eraseblocks, I might expect df's
"used" to include those, plus any alignment overhead, and for writes
to stop exactly the point where "available" reaches zero.  But I don't
see that, and I'm surprised that I cannot even fill it to 50% reliably.

Is this to be expected, or is something wrong?  Also, any advice in
picking the most reliable JFFS2 code with 2.4 kernels would be
appreciated, as I saw a number of messages in the archive recently
about data loss problems.

Thanks,
-- Jamie

                 reply	other threads:[~2006-01-11 21:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20060111211259.GA27357@mail.shareable.org \
    --to=jamie@shareable.org \
    --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