All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Egholm Nielsen <martin@egholm-nielsen.dk>
To: linux-mtd@lists.infradead.org
Subject: Many small files instead of one large files - writing, wearing, mount-time?
Date: Tue, 08 Mar 2005 09:59:36 +0100	[thread overview]
Message-ID: <d0jphc$re$1@sea.gmane.org> (raw)

Hi there,

I'm about to make a choice of design. I have many many (i.e. O(3) - 
[0-9]*1000) "resources" in an application that need their states flushed 
to NAND-JFFS2 whenever they change - which happens with very different 
frequencies for different resources.

Hence, me initial strategy was to have a file in NAND for each resource. 
However, I noticed that mount-time increased "severely" when many files 
were put on the device, and doing an "ls" first time on the 
device/directory took lots of time as well.

Unfortunately low mount-time is one of the factors giving the user a 
good experience with the system, so I started considering another 
strategy - namely one large file to hold all these states.

However, I'm a bit concerned how fopen( ..., "rw" ) is handled 
underneith when I flush/sync the filedescriptor if I only mess with a 
small part of the file. Is the entire file flushed to NAND once more, or 
does Linux+JFFS2 handle this, and only write the parts (inodes) that are 
affected...

BR,
  Martin

             reply	other threads:[~2005-03-08  8:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-08  8:59 Martin Egholm Nielsen [this message]
2005-03-09 10:58 ` Many small files instead of one large files - writing, wearing, mount-time? Artem B. Bityuckiy
2005-03-09 11:11   ` Martin Egholm Nielsen

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='d0jphc$re$1@sea.gmane.org' \
    --to=martin@egholm-nielsen.dk \
    --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.