Hello
The upas/fs program, in charge of provinding an fs layout of various mailboxes
(mdir, mbox, pop3, imap), was needing for an update from time ago. The first
major improvement was done by Erik Quanstrom adding the mdir support and
improving the memory managemt and performance to make upas able to deal with
huge mailboxes with mail messages with huge mime attachments.
The main objetive of this project is to allow multiple 9p conversation with
upas/fs, so multiple actions can be done at the same time.
The tasks done up to now have been:
Week 1 Tasks
* Decide what are we going to implement.
- The main objetive is to allow multiple 9p conversations with nupas.
So our efforts will be focused to this goal.
* Read nupas/fs/* code to see all the pieces
- Currently nupas starts various proceses using mailbox shared
structures and locking to manage the data
- Also nupas can handle only one 9p request at a time due to the
fs.c:/^io( implementation, and the way it talks with the other fs pieces (mbuf,
mdata, hbuf, Fcalls, variables in fs.c)
* Decide on the usage of system utilities like libthread and lib9p
- A lib9p based nupas approach could have performacne problems, as upas
had them with its tweaked source to cope with large numbers of fids, as Erik
pointed out in IW9P, and as part of his mentoring.
- A libthread+channels implementation is not trivial, and would require
modify nupas in multiple ways which could end being a mess instead of helping
to make things easier.
Week 2 Tasks
Very busy week, final exams in the school and a lot of work to do at the
office, the tasks done here were more reading of source and manuals,
understanding how fs.c:/^io( works using global Fcalls structures and buffers.
Also some experimenting with the source, identifying the need to sync the
multiple io's which woould be launched, may be using Sape's semaphore
implementation.
io() fork call will be same rfork(RFFDG|RFPROC|RFNAMEG|RFNOTEG|RFREND)) used to
fork the original io(), using a set global vars to communicate.
Week 3 Tasks
* Added a new command line parameter (-P) to specify the numer of io() forks to
do, 2 by default
* Added the type:
typedef struct Iodat Iodat;
struct Iodat {
char *name[3];
uchar mbuf[16*1024 + IOHDRSZ];
uchar mdata[16*1024 + IOHDRSZ];
char hbuf[32*1024];
Fcall rhdr;
Fcall thdr;
};
to glue all the structures needed per io() fork.
* Created initio() which will malloc memory for the per io() structs and will
fork io()s
* Added the global variable iodat as an array of Iodat. One element for each
io() fork. This variable is initilized from initio before the forks.
* All fs functions use a pointer to the correct Iodat element
fsfunc(Iodat*,Fid*), and now work with the Iodat corresponding to each io fork.
* io() use Iodat to save the request, lauch the appropriate fs function and
read the respond
Week 4 Tasks
* Build a couple of automatic tests to ensure the good behaviour of the changes
done to the source code.
* Implement iosync() to make io() procs cooperate
* Identify possible lock problems
Project source:
The source is available via http in:
http://9grid.es/store/gsoc/src/
and via 9p in
% import -A tcp!false.9grid.es!17666 / /n/essources
% cd /n/essources/dist/store/gsoc
Thank you very much to Devon and Erik for their patiente and support.
slds.
gabi
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Plan
9 Google Summer of Code" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/plan9-gsoc?hl=en
-~----------~----~----~----~------~----~------~--~---
