Keywords: UDF, pdflush Most recent kernel where this bug did not occur: unknown Distribution: gentoo 2005.1 Hardware Environment: dual AMD Opteron 848 on Tyan S2895 Software Environment: not relevant Problem Description: Extracting a large tar archive into a UDF residing on a DVD-RAM results in spawning of many pdflush threads (16 or more) each associated with the same UDF. A given device should have no more than one pdflush thread associated with it, and multiple threads fighting for the same device grossly erodes system responsiveness and results in a grossly inefficient pattern of access to the underlying device over which they fight. Steps to reproduce: See above.
2.6.12 is 7 months old, could you try 2.6.15 to check if it's reproduceable in the lastest version?
I don't have the ability to install 2.6.15 just now, but when I do I'll attempt to replicate this bug. I know from research I did before posting, that pdflush does not itself perform any checks to avert device contention. It relies on the caller to do it. What I don't know is whether the responsibility for the checks is specific to the device abstraction layer (right) or the filesystem layer (not right). The DVD-RAM drive is an ordinary ATAPI device, a Panasonic (Matsushita) SW-9574-C. By the way, shortly after posting the bug, I realized the obvious workaround is to use -o sync,dirsync with the mount. This works perfectly for my purposes (backup to DVD-RAM).
with 2.6.17-r4 on gentoo it also dont work. See please http://forums.gentoo.org/ viewtopic-t-481464-highlight-.html
Frank has reproduced this on clean 2.6.18-rc4 http://bugs.gentoo.org/142007
Has the issue been fixed? Any update on this please. Thanks.
Comment from Daniel Pouzzner: ever since discovering the problem I've just always mounted UDF's sync+dirsync, and haven't had a problem set up that way.