Bug 5893
Summary: | pdflush thread bomb on UDF writes | ||
---|---|---|---|
Product: | File System | Reporter: | Daniel Pouzzner (douzzer) |
Component: | UDF | Assignee: | Ben Fennema (bfennema) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | diegocg, douzzer, fgroups, jack, kernel, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.18-rc4 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Daniel Pouzzner
2006-01-14 18:43:51 UTC
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. |