Date: Thu, 25 May 2006 16:50:49 -1000 From: Jim Thompson <jim@netgate.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: atrens@nortel.com, current@freebsd.org, phk@phk.freebsd.dk, Alexander@Leidinger.net, small@freebsd.org Subject: Re: FreeBSD's embedded agenda Message-ID: <3BEB3B54-4CAD-477D-B88C-AB32584B7A47@netgate.com> In-Reply-To: <20060525.141012.1683993116.imp@bsdimp.com> References: <3981.1148578569@critter.freebsd.dk> <4475EFC1.1020504@nortel.com> <1148580598.4475f2f677197@imp2-g19.free.fr> <20060525.141012.1683993116.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 25, 2006, at 10:10 AM, M. Warner Losh wrote: > In message: <1148580598.4475f2f677197@imp2-g19.free.fr> > Olivier Gautherot <olivier@gautherot.net> writes: > : Hi Andrew! > : > : > [...] > : > > The reason Flash Adaptation Layers came about in the first place > : > > is that W95 didn't support anything but FAT. > : > > : > > : > Hmm. I was thinking about partitioning the problem actually. > Make flash > : > look like a disk and then you can put any filesystem on it that > you > : > want. Seems a heck of a lot simpler .. and I'm not sure if I > see any > : > drawbacks to doing it that way ... > : > : The drawback is the following: what would happen if you had an > application > : opening-writing-closing a file in /var/log on a regular basis? > The block > : would decay with time, with chances that your log even gets > corrupted. its much worse than you present. superblocks, directory inodes for /var/log, inodes (never mind the blocks for the file) for /var/log/foo (mod/access time updates), etc. > : That's why Flash drivers have to spread write accesses across the > device > : (what FFS doesn't naturally do). Also, there is a constraint > regarding > : the changes allowed: on NAND flash, you can write a 0 on a bit > but have > : to erase the full block to write a 1 back. > : > : Don't forget that Flash doesn't suffer from mechanical delays so > there > : is no harm in fragmenting the filesystem: this would be another > feature. though erasing a sector (for NAND flash) is a relatively slow operation. > There's at least one implementation of a geom_nand layer that tries to > wear average blocks from a pool it keeps. However, it would be far > better if it could get hints from the file system layer when blocks > were freed. Once you get to that level of abstraction, you might as > well just do all the work yourself. It gets kinda hairy to do it > generically for any filesystem. One problem with allowing excess fragmentation is that you might not be able to find a larger contiguous set of sectors, if your file/filesystem geometry requires same. This is why JFFS2 does GC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BEB3B54-4CAD-477D-B88C-AB32584B7A47>