Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8
- From: Alan Cox <alan lxorguk ukuu org uk>
- To: Jamie McCracken <jamiemcc blueyonder co uk>
- Cc: Mike Hearn <mike navi cx>, Sander Vesik <sander_traveling yahoo co uk>, desktop-devel-list gnome org
- Subject: Re: PROPOSAL: GNOME Volume Manager for GNOME 2.8
- Date: Sat, 26 Jun 2004 01:01:35 +0100
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.
] [Thread Prev