linux-ext4 - [Bug 12603] firefox downloads hang on ext4; fine on ext3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon,  2 Feb 2009 04:33:20 -0800 (PST)
From:	bugme-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 12603] firefox downloads hang on ext4; fine on ext3

http://bugzilla.kernel.org/show_bug.cgi?id=12603

------- Comment #16 from tytso@....edu  2009-02-02 04:33 -------
Unfortunately the strace logs aren't complete because firefox multi-threaded,
and it looks like strace is only tracing one thread.   So we can see that the
thread which writes the downloaded file does a poll(2) for a set of file
descriptors, including fd 18, and then it reads a byte from fd 18, and then
writes a buffer to fd 54, which is the firefox-3.0.5.tar.bz2.part file.   But
it is always writing in 32k chunks, and it's not writing the last 2837 bytes,
as in the good strace.

It looks like the thread which reads from the network isn't signalling that the
last set of bytes isn't there, but why, I have no idea.

It also seems very strange that this is filesystem-specific; whatever it is,
there isn't anything in the file writing thread that would hint at this.   I
also can't duplicate it on my end.   I wonder if it's something stupid like the
writes are returning much faster, and this is triggering a race condition in
firefox.  Maybe some other thread is checking to see when the write is
completing by stat'ing the fd, or something stupid like that.

Something that might be worth trying is to chattr +S your downloads directory,
which will force a sync after every write, and see if that makes a difference
when you download the file from scratch.   You'll want to do a "chattr -S
downloads downloads/*" afterwards, since a sync after every writes does a real
number on performance.   But if that causes firefox to succeed, then it's
probably some wierd timing/race condition problem in firefox.

I'll note that I can't reproduce this on my firefox on my Ubuntu/Hardy system.

BTW, how many CPU's do you have, and which version of Firefox are you running?

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html