FW: reiser4 plugin for maildir

FW: reiser4 plugin for maildir

[Burnes, James]

-----Original Message-----
From: Burnes, James 
Sent: Wednesday, December 03, 2003 1:38 PM
To: 'Hans Reiser'
Subject: RE: reiser4 plugin for maildir



> >I was considering installing qmail recently and upon analyzing the
> >architecture of their queue structure it looked like Dan Bernstein
> expended > >a lot of effort to achieve efficiency when you have 'many
files in the
> same
> >directory'.
> >
> >All the while I was thinking that Hans Reiser has already solved this
> >problem in reiserfs.
> >
> >Has anyone written a reiser4 plugin for qmail that implements this
> queueing
> >structure directly in the file system?
> >
> >
> No, and I'd love to see it happen.

Ok.  At least I'm on the right track.

I was re-reading the reiser4 docs yesterday and specifically the methods
that need to be implemented for each reiser4 plugin/object type.

All very elegant, but what wasn't too clear was the interface between the
new apps that can take advantage of these pluggable objects directly and the
interface between old-style POSIX apps and reiser4 that just want to see
these objects as files.

Since I just joined the reiserfs list, I'll copy/move this discussion there.
I'm sure there are a lot of people thinking about just these types of
issues. That way we can efficiently offload your brain, Hans ;-)

Some use-cases: (man haven't done some of this for a while...)

1. Web application in PHP or something acting as an OGG or MP3 store,
archives and reads audio files.  There is obvious structure in these files
and it seems silly to keep opening and reparsing their contents to extract
various bits of header information or separate forks in the data.

The web app understands this and R/W's the MP3 file using reiser4 into its
constituent components via the MP3 reiser4 plugin.  All interaction between
the app and the MP3 object lives at this layer of OO abstraction.

Meanwhile the host system's backup procedure uses POSIX fopens or whatever
to backup and restore the MP3 files.

Does the plugin have to know how to serially marshall and unmarshall the
object for POSIX programs so that it appears as a 'normal' MP3 file?

2. Someone develops a new mod_dav (mod_reiserDAV?) for Apache, that uses a
special reiser4 plugin to implement all of the DAV structures in reiser4
instead of the current hack that uses a DBM database.  Interesting/cool
features of DAV such as ordered DAV containers and revision control are
implemented directly with the reiser4 plugin.

3. As mentioned before, Dan Berstein's qmail program goes through a *lot* of
gyrations to efficiently implement many files in one directory (as well as
other issues).  I haven't tried a qmail queue on reiser3, but I gather that
they end up fighting each other to achieve the same goals.  Rather than
qmail trying to simulate a better file system, why not hack it to implement
message queuing functions in a reiser4 plugin.

Anyway, I'm just a beginner at kernel level filesystems, but I do have about
20 years systems software background so maybe I should give it a go.  It's
not going to get done tomorrow, but it should be fun.  All I have to loose
is my test partition ;-)

jim burnes
security engineer
great-west, denver

Re: FW: reiser4 plugin for maildir

[Chris Mason]

[reiser4 plugins to make mail delivery faster]

There are a few basic things that slow down mail servers when they talk
to filesystems:

1) multiple threads delivering to the same directory contend for the
directory semaphore for creating new files

2) atomic creation of an entire file

3) high load leads to numerous small synchronous filesystem operations
when multiple threads all try to deliver at once.

#1 is best fixed at the VFS level, basically allowing more fine grained
directory locks (lustre needs this as well I think).  It could be dealt
with entirely inside reiser4, but this is a generic need for linux as a
whole I think.

#2 and #3 could be dealt with in a reiser4 transaction subsystem. 
Basically the mail server would deliver a number of messages and trigger
commits at regular intervals, and reiser4 would make sure the files were
created atomically in the FS.  The mail server would not report the file
as delivered to the smtp client until the commit had completed.

So, I definitely think you could use reiser4 to gain significant mail
delivery performance.  But you probably don't need  a specific plugin
outside the transaction subsystems.  The obvious benefit of only using
the transaction systems is that you won't need to teach mail clients
about the reiser4 plugin.

There's lots of other plugin topics related to teaching the FS about
various file formats.  This may or may not be a good idea in some cases,
but it is a good place for research.  I'd start by looking at the xattr
interfaces and Hans' ideas for FS-as-a-database.

-chris

Re: FW: reiser4 plugin for maildir

[Nikita Danilov]

Chris Mason writes:
 > [reiser4 plugins to make mail delivery faster]
 > 
 > There are a few basic things that slow down mail servers when they talk
 > to filesystems:
 > 
 > 1) multiple threads delivering to the same directory contend for the
 > directory semaphore for creating new files
 > 
 > 2) atomic creation of an entire file
 > 
 > 3) high load leads to numerous small synchronous filesystem operations
 > when multiple threads all try to deliver at once.
 > 
 > #1 is best fixed at the VFS level, basically allowing more fine grained
 > directory locks (lustre needs this as well I think).  It could be dealt
 > with entirely inside reiser4, but this is a generic need for linux as a
 > whole I think.

I don't think that i_sem issue can be resolved within file system
back-end. For one thing, VFS (for example, open_namei()) uses i_sem to
serialize lookups within directory that can be satisfied without going
to the file system at all (from dcache). Releasing i_sem inside of file
system operations will break this serialization.

 > 
 > #2 and #3 could be dealt with in a reiser4 transaction subsystem. 
 > Basically the mail server would deliver a number of messages and trigger
 > commits at regular intervals, and reiser4 would make sure the files were
 > created atomically in the FS.  The mail server would not report the file
 > as delivered to the smtp client until the commit had completed.
 > 
 > So, I definitely think you could use reiser4 to gain significant mail
 > delivery performance.  But you probably don't need  a specific plugin
 > outside the transaction subsystems.  The obvious benefit of only using
 > the transaction systems is that you won't need to teach mail clients
 > about the reiser4 plugin.
 > 
 > There's lots of other plugin topics related to teaching the FS about
 > various file formats.  This may or may not be a good idea in some cases,
 > but it is a good place for research.  I'd start by looking at the xattr
 > interfaces and Hans' ideas for FS-as-a-database.
 > 
 > -chris
 > 

Nikita.

 >