[OpenAFS-devel] Fileserver as Masters Thesis

Sven Oehme oehmes@de.ibm.com
Wed, 12 Oct 2005 16:32:52 +0200


This is a multipart message in MIME format.
--=_alternative 004FDED3C1257098_=
Content-Type: text/plain; charset="US-ASCII"

Hi , 

there are a lot of other documents for developers i couldn't find the 
original location, because transarc.com no longer exists , but google 
helps out :-)
---> 
http://www.mirrors.wiretapped.net/security/cryptography/filesystems/arla/prog-afs/shadow/progint/

Sven



Hannes Eriksson <hannes@cs.umu.se> 
Sent by: openafs-devel-admin@openafs.org
10/12/05 03:56 PM

To
openafs-devel@openafs.org
cc

Subject
Re: [OpenAFS-devel] Fileserver as Masters Thesis






(Yes, I'm the "colleague" Niklas mentioned)

On Tue, Sep 27, 2005 at 01:12:20PM -0400, Jeffrey Hutzelman wrote:
> On Monday, September 19, 2005 06:31:54 PM +0200 Frank Bagehorn 
> <FBA@zurich.ibm.com> wrote:
> 
> >- Or you create a virtual layer for the existing fileservers, so that 
you
> >would have a well-defined interface to whatever lies below. (NAMEI or
> >INODE or DB or whatever comes to peoples mind.)
> 
> Actually, we already have that layer.  OpenAFS doesn't have two 
> fileservers; it has one fileserver which can be compiled with any of 
three 
> different backends (inode, namei, and windows).  I'd expect work in this 

> area to involve writing new fileserver backends, not whole new 
fileservers.

I've tried to find that layer for some time now, without success.
I cannot find all the code I'd wish in cvs. There is src/vol/ntops.[ch]
for the windows backend and similar code in src/vol/namei_ops.[ch] but I
have a hard time finding corresponding functionality for the inode
backend. Additionally, there seems to be related code in src/libafs/,
but something tells me that code is client side...

The fscm-ispec.pdf is about the other end of the fileserver, so that
isn't very useful. I haven't found any other dev docs in the CVS or on
the net mentioning the fileserver.

It would be most helpful if someone could give me some rough pointers as
to which parts of the source tree are related to what backend.

> These tools [hostafs tafssrv] are interesting, but they're not the basis 
for a full-service 
> fileserver. 

I will check them out, especially tafssrv, for the ideas it might give,
but I really want to make something that at least I would like to use...

>From the mail discussions and books I've read, a useful fileserver
backend would probably:

*) Be stable by not keeping references to inodes separate from the
   underlying fs (stray inodes make fsck on /vicep? a bad idea, right?)
*) Be reasonably portable without #ifdef or a large number of platform
   specific files (to platforms I can test on, i.e. linux 2.4/2.6, aix
   5.1, sol9/10)
*) Be (or having serious potential at becoming) fast, possibly by
   by-passing existing fs naming layers
*) Not be limited by historic data types for file sizes or number of
   files (other than what RX or the fileserver frontend imposes).

This list makes me think that a good design would start by not trying to
live on top of a pre-existing file system. Of course this would mean
having to implement a fsck and salvage, but they might be combined into
one tool...

/Hannes

-- 
main(){double s=0,n=1;for(;n<2<<23;s+=4/n-4/(n+2),n+=4);printf("%f",s);}
/* hannes@{acc,cs}.umu.se  www.{acc,cs}.umu.se/~hannes  ICQ#27865609  *\
\*         finger hannes@finger.acc.umu.se for my public key          */
[attachment "signature.asc" deleted by Sven Oehme/Germany/IBM] 

--=_alternative 004FDED3C1257098_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi , </font>
<br>
<br><font size=2 face="Arial">there are a lot of other documents for developers
i couldn't find the original location, because transarc.com no longer exists
, but google helps out :-)</font>
<br><font size=2 face="Arial">---&gt; http://www.mirrors.wiretapped.net/security/cryptography/filesystems/arla/prog-afs/shadow/progint/</font>
<br>
<br><font size=2 face="Arial">Sven</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Hannes Eriksson &lt;hannes@cs.umu.se&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: openafs-devel-admin@openafs.org</font>
<p><font size=1 face="sans-serif">10/12/05 03:56 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">openafs-devel@openafs.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [OpenAFS-devel] Fileserver
as Masters Thesis</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>(Yes, I'm the &quot;colleague&quot; Niklas mentioned)<br>
<br>
On Tue, Sep 27, 2005 at 01:12:20PM -0400, Jeffrey Hutzelman wrote:<br>
&gt; On Monday, September 19, 2005 06:31:54 PM +0200 Frank Bagehorn <br>
&gt; &lt;FBA@zurich.ibm.com&gt; wrote:<br>
&gt; <br>
&gt; &gt;- Or you create a virtual layer for the existing fileservers,
so that you<br>
&gt; &gt;would have a well-defined interface to whatever lies below. (NAMEI
or<br>
&gt; &gt;INODE or DB or whatever comes to peoples mind.)<br>
&gt; <br>
&gt; Actually, we already have that layer. &nbsp;OpenAFS doesn't have two
<br>
&gt; fileservers; it has one fileserver which can be compiled with any
of three <br>
&gt; different backends (inode, namei, and windows). &nbsp;I'd expect work
in this <br>
&gt; area to involve writing new fileserver backends, not whole new fileservers.<br>
<br>
I've tried to find that layer for some time now, without success.<br>
I cannot find all the code I'd wish in cvs. There is src/vol/ntops.[ch]<br>
for the windows backend and similar code in src/vol/namei_ops.[ch] but
I<br>
have a hard time finding corresponding functionality for the inode<br>
backend. Additionally, there seems to be related code in src/libafs/,<br>
but something tells me that code is client side...<br>
<br>
The fscm-ispec.pdf is about the other end of the fileserver, so that<br>
isn't very useful. I haven't found any other dev docs in the CVS or on<br>
the net mentioning the fileserver.<br>
<br>
It would be most helpful if someone could give me some rough pointers as<br>
to which parts of the source tree are related to what backend.<br>
<br>
&gt; These tools [hostafs tafssrv] are interesting, but they're not the
basis for a full-service <br>
&gt; fileserver. <br>
<br>
I will check them out, especially tafssrv, for the ideas it might give,<br>
but I really want to make something that at least I would like to use...<br>
<br>
>From the mail discussions and books I've read, a useful fileserver<br>
backend would probably:<br>
<br>
*) Be stable by not keeping references to inodes separate from the<br>
 &nbsp; underlying fs (stray inodes make fsck on /vicep? a bad idea, right?)<br>
*) Be reasonably portable without #ifdef or a large number of platform<br>
 &nbsp; specific files (to platforms I can test on, i.e. linux 2.4/2.6,
aix<br>
 &nbsp; 5.1, sol9/10)<br>
*) Be (or having serious potential at becoming) fast, possibly by<br>
 &nbsp; by-passing existing fs naming layers<br>
*) Not be limited by historic data types for file sizes or number of<br>
 &nbsp; files (other than what RX or the fileserver frontend imposes).<br>
<br>
This list makes me think that a good design would start by not trying to<br>
live on top of a pre-existing file system. Of course this would mean<br>
having to implement a fsck and salvage, but they might be combined into<br>
one tool...<br>
<br>
/Hannes<br>
<br>
-- <br>
main(){double s=0,n=1;for(;n&lt;2&lt;&lt;23;s+=4/n-4/(n+2),n+=4);printf(&quot;%f&quot;,s);}<br>
/* hannes@{acc,cs}.umu.se &nbsp;www.{acc,cs}.umu.se/~hannes &nbsp;ICQ#27865609
&nbsp;*\<br>
\* &nbsp; &nbsp; &nbsp; &nbsp; finger hannes@finger.acc.umu.se for my public
key &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;*/<br>
[attachment &quot;signature.asc&quot; deleted by Sven Oehme/Germany/IBM]
</tt></font>
<br>
--=_alternative 004FDED3C1257098_=--