-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi folks,
I'm working on a embedded project and have been cycling through some
tradeoffs wrt using cf cards as disks.
I know these devices support wear-leveling, but I'm not sure how this
could work well without knowledge about the filesystem wrt what is a
free block and what is an 'in-use' block. I suppose the algorithm could
keep track of how many times a block has been written to, and remap with
less used block - maybe using some kind of priority queue data structure
to keep that process relatively efficient.
At least I'm *hoping* that the cf device's wear levelling algo isn't
dependent on using a FAT filesystem or some other horrible hack :(
So that's my primary concern. Toshiba devices are typically good for
10000 multi-cell write/erase cycles (see Kingston website). I'm thinking
if wear levelling works that means that doubling the device size
I use means effectively doubling the device's lifespan. Obviously I'd
like the device I'm working on to last forever, but 7 years is a good
engineering number to use I think. :)
Now, on to filesystems. :) I have a FreeBSD/DragonFly background ('bout
12 years) and am relatively new (<6 months) to OpenBSD.
Wrt LFS .. is it production ready? I know it's seriously bitrotted on
Free/DragonFly.
And finally one last question that applies to both FFS and LFS - file
access/creation/modification metadata updates. Specifically I'm thinking
of atime's. Is there any way to switch off atime updates ? They don't
add much value for me, and I'm worried they might unduly age my flash. :)
Long term I'm planning to run my root fs out of RAM and minimize flash
writes, but I'm a bit time-limited on this project and if I could get
away with treating a CF card as though it were a regular disk it would
simplify my life in more than one way. :)
Thanks for any help, advice, and even justified abuse (hehe if you think
I'm being an idiot and/or missing something obvious) you can provide would
be greatly appreciated.
Cheers,
Andrew.
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDzV9n8It2CaCdeMwRAruQAJ0TksxIT8O3ThiKMuSgUdgD0gDTZgCeJhZi
eh1rCVmU1xR3h7YVuo8C+Ds=
=UO+m
- -----END PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDzWxj8It2CaCdeMwRAoNcAJ98+QpDPOKVtIxY1lsBBhaKnoX2jACffzkL
cwEpIni+R+MCrAJKTj8cZXY=
=Xw2o
-----END PGP SIGNATURE-----
