[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]distributed fs
From: |
steehf |
Subject: |
Re: [DotGNU]distributed fs |
Date: |
Sun, 5 Aug 2001 16:26:14 +0200 |
ok. so at the moment its about transaction logging/journaling.
but what about managing ressources the same way - in a true fs-manner..
uhm...say e.g. to let the servers know if certain information stored
client-side (like the PIB or something) is available now.
if we'll have to store more than just login information client-side we should
think about how to share & manage those. (however...do we have to?)
because recently i thought (crazy? no i'm simply not sure wheter we can benifit
from it...) that some users computer might be equal an inode being part of a
big dotgnu distributed fs.
in that case it would be interesting to have a look at some fs's from the
design-point-of-view and maybe apply some of the features to dotgnu.
because...it's the same. its about managing clusters of information.
just a thought.
best regards,
stefan
---
On Sun, 5 Aug 2001 10:24:49 +1000
address@hidden (Myrddian) wrote:
>
>
> Oh Oh, somebody has come in and read the previous DRAFT's
> EXCELLENT!!!!!!!!!!! YES
>
> Ok..... the idea is quite simple. IT's a solution for a handling missing
> transactions over a network.
>
> Put it this way if Server A want to Contact Server B they are doing an
> transaction, for some odd reason
> Server A and B cannot communicate with each other anymore.
>
> How can you deal with the issues of Dropped transactions? Remember these are
> critical.
>
> Simple (well in theory) Make the transaction atomic, and repeatable.
>
>
>
> Welll in theory you have the Server-Server communication this is what it's
> based on.
>
> So each Server keeps a log, I use the example of JFS because it's where it's
> based of.
>
> Each server has a log/journal of transactions. If a transaction is fulfilled
> it's flushed of, however
> if it's not it's marked as active and retried until it's fulfilled.
>
> The idea behind this was a Client Connects to Server A, in which case server
> a proxies for it to Server B.
>
> However I think having the client have this is important, if we are going for
> peer-peer model.
>
>
> If you have any specific Questions regardingg this please visit the IRC
> channel (hopefully I should be there
> ) or mail on the mailing list.
>
>
> Thanks
>
>
>
>
> > when i read myrddian's draft "some ideas" and he starts pointing out
> > similarities to (journaling) filesystems a question raised:
> > do we have any idea right now on how to update/synchronize logs and db's?
> > there has to be some client & server sided backend keeping the whole
> > framework of dotgnu servers up-to-date about current transactions etc.
> > to such a backend also fs-specific concepts could be applied.
> > sounds interesting if we can think of a distributed fs.
> > please just let me know whether i've missed some previous discussion's
> > point i've never read! :)
> >
> > best regards,
> > stefan
>
>
> --
> __________________________________________
> Myrddian <myrddian at bigpond.net.au>
> -------------------------------------------
> " Pero el Viento no mas sabe, a donde duerme my viejo
> Con su pena de hombre pobre y dos valas en el pecho. "
>
> Patricio Manns
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers
>
--