Extracting FFS from FreeBSD

[Allan Fields]

Just a few more points to be raised on ffs usage/porting..

On Mon, Oct 18, 2004 at 01:00:45PM +0200, Daniel Gustafsson wrote:
> It?s true that it may be overkill to extract FFS for my needs.
> 
> The functionality that I am after is:
> 1. Read/Write etc.

standard filesystem primitives

> 2. 1 GB Partitions.

non-restrictive disk layout

> 3. Few reads and writes to disk.

i.e. something with an efficient disk layout that's fairly static,
compact inode structures, good clustering and reasonable block i/o
performance on the back end.  Much of this ffs fulfills, but
shouldn't be assumed the only option (look at the alternatives, etc.)

> 4. RAM footprint between 200-800K

Can you count on using a large buffer cache (and the additional
memory this implies) so as to avoid duplicated reads or frequent
writes?  I'd think there is a compromise between 3 and 4.

> 5. Blockbased (blocksize 4-8K).
> 6. Configurable.
> 7. Free.

.. sane ..

> 8. Multi-user (I will integrate the FS with a RTOS)

Might you want even to look way back to a simpler time [tuhs.org]
as a historical starting point? :) It might be useful to consider
/ compare other BSD implementations too such as NetBSD and decide
then if ffs is the appropriate choice.

Does this need to be compatible w/ existing file system layouts?

Do you need anything past a very minimal FS?  (As mentioned there
are very much simplified *nix implementations w/ ffs support but
w/o features such as soft updates and the snapshot code which
are great for servers.)

Do you need full UFS support?  Are you planning on redoing the VFS
layer to suite your needs too?

> ..

Using flash by any chance?  If so, there are various papers/existing
insight into FS using flash memory problem.

On media independence ffs was designed primarily with Winchester
disks in mind, not for instance CD-ROMs or flash cards.  The chapter
on Local Filestores in The Design and Implementation.. has a good
outline of the original design work performed and explains the
rational behind some of the decisions.

> //Daniel

-- 
 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541