From: MikeW <mw_phil@yahoo.co.uk>
To: linux-mtd@lists.infradead.org
Subject: Re: Wanted - simple NOR Flash filing system
Date: Tue, 24 Apr 2007 16:03:53 +0000 (UTC) [thread overview]
Message-ID: <loom.20070424T174804-792@post.gmane.org> (raw)
In-Reply-To: 200704240655.37619.manningc2@actrix.gen.nz
Charles Manning <manningc2 <at> actrix.gen.nz> writes:
>
> On Monday 23 April 2007 23:34, MikeW wrote:
> > For storing a few tens/hundreds of bytes of configuration data,
> > in a handful of files (no subdirs), read access 99.99%,
> > write/update once or twice in life of the system.
> > Fits into single erase block ideally, so might need to hold data in RAM
> > pending erase - if ever filled the block !
> >
> > Any suggestions ?
>
> It is far too grand to call this a file system.
> This is a bit more like a linear file store, or even more proimitive than
> that.
>
> I agree with the basic principle: if you don't need a full fs, then why use
> one? You don't need a chainsaw to cut butter!
>
> I have done stuff like this numerous times, but don't have any OSS code to
> release.
>
> The last time I did this, I used a pretty simple system that just used records
> of the form:
>
> Header byte
> 2 byte Length
> Validity byte (0xFF not set up, 0x0F= in use, 0x03 = deleted
> Name
> data (length - (strlen(name) + 1 + 1 + 1))
>
> With this mechanism you could only write a whole "file". No append/overwrite
> etc. Just rewrite the whole record.
>
> To delete a file you just set the validity byte accordingly.
>
> I had two blocks and when the one got full I would do "garbage collection",
> copying the valid "files" through to the new block. With one block you could
> store the stuff in RAM.
>
Thanks - I have certainly thought before about implementing
such a simple scheme,
but I was wondering if there was already an tested 'off-the'shelf'
set of code since it seems to be such a basic requirement if you don't
want or need JFFS2 size, functionality or overhead.
I have had a direct email (imcd) suggesting storing a tar file directly in
the /dev/mtd, but would prefer that any 'driver' was self-sufficient
so it could potentially be used before kernel boot.
"tarfs", anyone ?
>> (from imcd)
Save:
tar cz -f /dev/mtdblock/1 -C dir .
Load:
tar xz -f /dev/mtdblock/1 -C dir
<<
For now I have made do with a single block romfs device created 'offline',
though in principle I could create the required files in /tmp and then
load them into the erased flash block using genromfs.
Regards,
MikeW
next prev parent reply other threads:[~2007-04-24 16:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-23 11:34 Wanted - simple NOR Flash filing system MikeW
2007-04-23 18:55 ` Charles Manning
2007-04-24 16:03 ` MikeW [this message]
2007-04-27 7:49 ` David H. Lynch Jr.
2007-04-26 14:09 ` Wanted - simple NOR Flash filing system - JFFS2 ? MikeW
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=loom.20070424T174804-792@post.gmane.org \
--to=mw_phil@yahoo.co.uk \
--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.