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

RESOLVED DUPLICATE of bug 624806

Status

Thunderbird
Folder and Message Lists
--
major
RESOLVED DUPLICATE of bug 624806
5 years ago
4 years ago

People

(Reporter: Eric Valette, Unassigned)

Tracking

({perf})

31 Branch
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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

4 years ago
could be related to bug 624806. what do you think?
Flags: needinfo?(eric.valette)
(Reporter)

Comment 3

4 years ago
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
Flags: needinfo?(eric.valette)
(Reporter)

Comment 4

4 years ago
I suspect 
EAGAIN is badly handled
(Reporter)

Comment 5

4 years ago
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/Q6KdnavBq8Cc__DPnZ2dnUVZ_gudnZ2d@mozilla.org there are a lot of infos in his thread.
(Reporter)

Updated

4 years ago
Severity: normal → major
Version: 17 → 24
(In reply to Eric Valette from comment #3)
> strace shows message is copiedu using 78 char bouffer

dup of bug 769346.
Summary: Moving message from LDAP https inbox to mounted CIFS drive is awfully slow on Linux → Moving message from IMAP https inbox to mounted CIFS drive is awfully slow on Linux
(Reporter)

Comment 7

4 years ago
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.
(Reporter)

Comment 8

4 years ago
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
Priority: -- → P1
(Reporter)

Updated

4 years ago
Version: 24 → 31

Comment 9

4 years ago
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.
Flags: needinfo?(eric.valette)
Keywords: perf
Priority: P1 → --
Whiteboard: [dupeme]
(Reporter)

Comment 10

4 years ago
What in bug 624806?
Flags: needinfo?(eric.valette)
(Reporter)

Comment 11

4 years ago
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

4 years ago
yeah, I forgot to finish typing bug 624806 comment 14.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Whiteboard: [dupeme]
Duplicate of bug: 624806
You need to log in before you can comment on or make changes to this bug.