All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russ Dill <Russ.Dill@asu.edu>
To: Abraham vd Merwe <abraham@2d3d.co.za>, linux-mtd@lists.infradead.org
Subject: Re: safe flash filesystem
Date: Fri, 22 Jun 2001 10:23:01 -0700	[thread overview]
Message-ID: <3B337EF5.3030009@asu.edu> (raw)
In-Reply-To: 20010622102154.E1828@crystal.2d3d.co.za

Abraham vd Merwe wrote:

> Hi Russ!
> 
> 
>>If its just a config file, why make all this so complicated?
>>
>>struct node {
>>
>>	u32 magic;
>>	char valid;
>>	u32 version;
>>	u32 data_crc;
>>	u32 hdr_crc;
>>	char data[DATA_SIZE];
>>};
>>
> 
> Yes, this is something in the lines I was thinking of. But what complicates
> things is if you start taking things like avoiding damaged blocks into
> account, wear levelling (this is fairly easy to solve) and keeping the flash
> unfragmented.
> 
> 


if you only eraseblocks when you need to, you always have at least N-1 
eraseblocks of pevious data, (where N is the number of eraseblocks 
used). A CRC can be done after the store to see if the node written is 
ok, if not, write it again (in the next node). since its a small amount 
of data (maybe 4-8k) and written linearly, wear leveling and 
fragmentation is not a problem. Lets say 4 parameter blocks of 16k a 
peice are used, that would be 1 erase cycle per 8 configs written, this 
would allow 800,000 configs to be written on standard flash. If a config 
was written at a rate of once an hour, it would last 93 years. If it 
were on 2 128k standard blocks, then you wolud have 3.2M configs 
written, which at the same rate, would last about 332 years. Remember, 
you are only performing an erase cycle after a block fills up, not for 
every write.

  parent reply	other threads:[~2001-06-22 17:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-21 10:54 safe flash filesystem Abraham vd Merwe
2001-06-21 13:43 ` Vipin Malik
2001-06-21 13:57   ` Abraham vd Merwe
2001-06-21 14:29     ` Vipin Malik
2001-06-21 14:35       ` Abraham vd Merwe
2001-06-21 15:05         ` Vipin Malik
2001-06-21 15:36           ` Chris Read
2001-06-21 15:09         ` Joakim Tjernlund
2001-06-21 15:34           ` Vipin Malik
2001-06-21 19:34             ` Joakim Tjernlund
2001-06-21 19:47             ` Joakim Tjernlund
2001-06-21 15:11         ` Herman Oosthuysen
2001-06-21 17:54           ` Tim Riker
2001-06-21 19:43             ` Vipin Malik
2001-06-21 19:35               ` Tim Riker
2001-06-21 19:56                 ` Vipin Malik
2001-06-21 21:17                   ` Kyle Harris
2001-07-03 23:53                     ` On the "safe filesystem" and write() topic Bjorn Wesen
2001-07-04 14:10                       ` Vipin Malik
2001-07-05 18:16                         ` Bjorn Wesen
2001-07-06 13:40                           ` Vipin Malik
2001-07-07  9:25                             ` Bjorn Wesen
2001-07-07 13:06                               ` Vipin Malik
2001-06-21 21:26         ` safe flash filesystem Russ Dill
2001-06-22  8:22           ` Abraham vd Merwe
     [not found]           ` <20010622102154.E1828@crystal.2d3d.co.za>
2001-06-22 17:23             ` Russ Dill [this message]
2001-06-25  7:45               ` Abraham vd Merwe
2001-06-25  7:59                 ` Russ Dill
2001-06-25 14:11                   ` Vipin Malik
  -- strict thread matches above, loose matches on Subject: below --
2001-06-21 16:05 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=3B337EF5.3030009@asu.edu \
    --to=russ.dill@asu.edu \
    --cc=abraham@2d3d.co.za \
    --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.