Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8

[Alan Cox <alan lxorguk ukuu org uk>]

On Sad, 2004-06-26 at 01:51, Jamie McCracken wrote:
> filesystems do not place files contiguously but as B-tree nodes. Theres
> no way they can give you want you want using B-trees (which also gives
> us journalising ability and removes the need to defrag). If you want a
> contiguous filesystem you can always use FAT but I expect performance
> would still be crap!

Ext3 is not btree based, nor if I remember rightly is XFS - in fact
Btree based fs's have really gone out of fashion in the literature
because they are such a pig to put back together on a disk error. Reiser
is but I don't know enough about its innards to comment in detail.

Ext3 is based on FFS/UFS ideas which deal with fragmentation by
a mix of means

- The disk is split into cylinder groups each with some inodes/data
- File starts are placed when possible in a group close to the inode
- New files are created based on the free inode/block heuristics
- When files pass a certain length the next chunks get written into
  a cylinder group with very little data (so it gets long runs)
- Data is preallocated and then freed on close - to avoid interleave.

It works well for sequential writes in almost all cases, it can fail
horrendously (eg bittorrent client without pre-creating the files)

To all intents and purposes if you just open, write a file, close it
will generally be pretty well laid out.

> The best solution to that is to use some ultra fast database to store
> all the settings and gconf data that currently reside in loads of small
> xml files. (xml is also painfully slow to parse and search which

Definitely. I'd like to stress the stuff I've done isn't going to help
gconf just icons/themes however. The database problem with dynamic
fast updates is a *much* harder problem - paradoxically it might 
actually be quicker to dump the entire gconf db into a file each 
changeset than to write a set of changed nodes.