864763 - Moving message from IMAP https inbox to mounted CIFS drive is awfully slow on Linux

Status: RESOLVED DUPLICATE of bug 624806

(Thunderbird :: Folder and Message Lists, defect)

Description

[Eric Valette]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Iceweasel/20.0
Build ID: 20130402195902

Steps to reproduce:

I move message with attachment from an IMPA inbox account to a local storage on a CIFS mounted drive


Actual results:

It takes ages to complete and sometimes fails by creating ghost message in the destination folder. Doing the same in a  windows VM is  way faster (same inbox, same version of thunderbird, same mounted share)


Expected results:

Be faster than on the VM. Its 50x times slower.

Comment 1

[Wayne Mery (:wsmwk)]

could be related to bug 624806. what do you think?

Comment 2

[Wayne Mery (:wsmwk)]

plus https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&f1=short_desc&list_id=9069765&short_desc=network%20drive%20share&o1=substring&o2=substring&query_format=advanced&f2=keywords&short_desc_type=anywordssubstr&longdesc=share&v1=slow&v2=perf&longdesc_type=allwordssubstr&product=MailNews%20Core&product=Thunderbird

Comment 3

[Eric Valette]

not at work. many informations on newsgroup. relatif to bug on l'on level Linux io.
strace shows message is copiedu using 78 char bouffer

Comment 4

[Eric Valette]

I suspect 
EAGAIN is badly handled

Comment 5

[Eric Valette]

I suspect that
   1) EAGAIN is badly handled in some cases,
   2) clearly the copy buffer size is crasy,
   3) Low level handler of read/write error is quite non robust on Linux,

See : news://news.mozilla.org:119/[e-mail] there are a lot of infos in his thread.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Eric Valette from comment #3)
> strace shows message is copiedu using 78 char bouffer

dup of bug 769346.

Comment 7

[Eric Valette]

Note that when moving grouped message (e.g a thread) with several attached, not only the copy does not finish even waiting for ages but after, the target directory is unreadable. I have to quit thunderbird, restart, repair the folder and at beast it contains a lot of 0 size messages, at worst some message are missing =W> data lost.

The data lost is probably due to bad handling of read/write error code.

Comment 8

[Eric Valette]

I tested 31 beta and the bug is still there. Why the hell is the status unconfirmed when people agree message a re copied using ridiculous small message size.

The problme is that due to timeout, when doing big transfers, the target directory on the CIFS share become corrupted and you may lost your copied messages. Minimum is that you have to quit TB, restart it on make restore operation on folder which usually creates a bunch of 0 size messages

Comment 9

[Wayne Mery (:wsmwk)]

Eric this sounds even more like (at least partly) bug 624806. Does bug 624806 reduce your problem?

n.b. priority is a developer field. Please don't touch.

Comment 10

[Eric Valette]

What in bug 624806?

Comment 11

[Eric Valette]

Copying anything including huge amount of data to the same share in any other apps works like a charm with same setup and the noserverino is set.

Comment 12

[Wayne Mery (:wsmwk)]

yeah, I forgot to finish typing bug 624806 comment 14.