From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <e965240da6b755ab9e162e786c998571@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  9 Jun 2009 14:10:11 -0400
To: 9fans@9fans.net
In-Reply-To: <14ec7b180906091027g4c060b5egf0e15265289e5ee6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Different representations of the same file/resource in
	a synthetic FS
Topicbox-Message-UUID: 07e85000-ead5-11e9-9d60-3106f5b1d025

On Tue Jun  9 13:28:55 EDT 2009, mirtchovski@gmail.com wrote:
> I think I've mentioned this before, but on a few of my synthetic file
> systems here I'm using what you describe to slice a database by
> specific orderings. For example, I have a (long) list of resources
> which I'm managing in a particular environment each has an owner,
> type, status and a few static data containers. It's all backed by a
> relational database, but the file server presents different "slices"
> of that to external users, where the directory structure is rigidly
> defined [...]

this is definately a problem for upas/fs.  it would be nice, for example,
for upas/fs to have the option of sorting mailboxes in various ways.
imap4d's requirements are not the same as nedmail's.  by thread,
by date, by order of arrival are all useful sortings.  and of course,
given the ability to manage giant piles of messages reasonably efficiently,
it's tempting to replace the idea of different boxes with different
views of the same giant pile of messages.

how are the resultant files looked up?  it turns out that generating
the file hash table was the single most expensive operation for
upas/fs, given mailboxes with ~10k messages.
(http://9fans.net/archive/2009/05/106)

- erik