nupas status

[gd...@9grid.es]

Hello

The following tasks have been done:

* nupas now forks various io() procs and handle multiple 9p conversations. Two locks have been created to protect the reads and the writes to the 9p pipe, so only one io proc could read or write at a time. The main proc waits until the exit of its childs, this is a change of the original behaviour on which RFNOTEG was used in the rfork call.

* a memory leak was fixed. The bug was in the code responsible to set the name of the proc like 'upas/fs io 0'

cpu% ps -a | grep nupasfs
gdiaz 1636728 0:00 0:00 2972K Await nupasfs [nupasfs -P 5]
gdiaz 1636729 0:00 0:00 2972K Sleep nupasfs [upas/fs plumbing]
gdiaz 1636730 0:00 0:00 2972K Rendez nupasfs [upas/fs io 0]
gdiaz 1636731 0:00 0:01 2972K Rendez nupasfs [upas/fs io 1]
gdiaz 1636733 0:00 0:00 2972K Rendez nupasfs [upas/fs io 2]
gdiaz 1636734 0:00 0:00 2972K Rendez nupasfs [upas/fs io 3]
gdiaz 1636735 0:00 0:00 2972K Pread nupasfs [upas/fs io 4]
gdiaz 1636918 0:00 0:00 156K Pread grep nupasfs
cpu%

* due to the changes of the global buffers used originally, a bug was introduced in the mkstat function. The size of the buffer is now explicit instead of returned by sizeof buff in the readheader() and readinfo() calls within mkstat(). A #define HBUFSZ 32*1024 was introduced instead of the sizeof call.

* When reading an imap mailbox it is usual to see messages like:

user: gdiaz; note: sys: write on closed pipe pc=0x0002641b
user: gdiaz; note: sys: write on closed pipe pc=0x0002641b

but this happen also in the original version. I do not use upas/fs as an imap client, is this expected?

* The following tests have been manually executed with a local mbox (1260 mails) and a remote imap mailbox (70 mails)

- While opening or deleting a message in the imap box, it is possible to open or delete a message on the local mbox message (the local operations finished after the imap ones)
- While executing two du -a commands on two different mailbox (the same setup), a ps -a shows changes on the procs state.
- Reading and managing these two mailboxes behaved normally, and no more leaks or errors have been detected. Also memory usage is simmilar to the original.

The tasks planned to the next week are:

- build automated tests
- test the new upas/fs working with the imap server
- decide the default number of io() forks (now is 2)
- tests it with more complex setup (feedback welcome, so if you have a couple of mailboxes and have the time to try it, will be appreciated)

thanks,

gabi

[Devon H. O'Dell]

Cool, thanks for the update. Just one thing:

> * nupas now forks various io() procs and handle multiple 9p conversations. Two locks have been created to protect the reads and the writes to the 9p pipe, so only one io proc could read or write at a time. The main proc waits until the exit of its childs, this is a change of the original behaviour on which RFNOTEG was used in the rfork call.

Any reason to not use rwlocks to enforce this?

> - tests it with more complex setup (feedback welcome, so if you have a couple of mailboxes and have the time to try it, will be appreciated)

My gmail has thousands of messages; also I can try to get an OK to do
testing from my company (since I work in the email space and my
employment agreement prohibits it in general).

--dho

[gd...@9grid.es]

hello

just after sending the email i hit a bug ☺, i wonder why i have been so lucky to hit it a day after the tests started. . .

i'll check the rwlocks

thanks

gabi

[quanstro]

> * When reading an imap mailbox it is usual to see messages like:
>
>         user: gdiaz; note: sys: write on closed pipe pc=0x0002641b
>         user: gdiaz; note: sys: write on closed pipe pc=0x0002641b
>
> but this happen also in the original version. I do not use upas/fs as an imap client, is this expected?

nope. i never see that. are you sure that you've got the correct
flags on
the rfork? you should be sharing file descriptors.

- erik

[quanstro]

On Jun 29, 9:13 am, gd...@9grid.es wrote:
> - tests it with more complex setup (feedback welcome, so if you have a couple of mailboxes and have the time to try it, will be appreciated)

it should not be hard to open 20 or so mailboxes at the same time.
since upas/fs isn't smart enough to recognize the same mailbox opened
twice, that would be a nifty trick. by the way, making upas/fs
recognize
this case is square in the middle of this project.

- erik

[gd...@9grid.es]

Hello

I'm getting this accessing MobileMe imap server. . . with and without the gsoc modifications.
Also i'm getting other odd behaviour (if i read messages from the webmail, upas mark them as deeleted), so i guess MobileMe is not a very standard imap service.

I'll try with pop3 and other imap services to double check this.

gabi

>> * When reading an imap mailbox it is usual to see messages like:
>>
>>         user: gdiaz; note: sys: write on closed pipe pc=0x0002641b
>>         user: gdiaz; note: sys: write on closed pipe pc=0x0002641b
>>
>> but this happen also in the original version. I do not use upas/fs as an imap client, is this expected?
>