Bug 451738 - kcryptd I/O blockage using encrypted filesystem on LVM
kcryptd I/O blockage using encrypted filesystem on LVM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Milan Broz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-16 21:34 EDT by Michael Hampton
Modified: 2013-02-28 23:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-26 07:13:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Hampton 2008-06-16 21:34:01 EDT
Description of problem:
When using an encrypted filesystem on LVM, whether an encrypted PV or LV, the
kernel frequently blocks for long periods of time waiting for I/O. top shows
anywhere from 20% to 100% CPU time waiting for I/O. Affected processes freeze
for several seconds, up to a minute or more, waiting for even small disk
reads/writes.

Version-Release number of selected component (if applicable):
kernel-2.6.25.6-55.fc9.x86_64

How reproducible:
Random

Steps to Reproduce:
1. Install Fedora 9 to encrypted PV.
2. Use moderately disk intensive processes such as firefox, thunderbird or liferea.
  
Actual results:
Some disk operations take dozens of seconds to complete.

Expected results:
Disk operations should complete in a reasonable time.

Additional info:
Issue did not occur with Fedora 8. Help tracking this down would be greatly
appreciated.
Comment 1 Dave Jones 2008-06-16 21:45:54 EDT
this is likely another case of the 'firefox fsyncs too much' bug.  (it calls
fsync every time it updates the history db - ie, each time you view a new page.
unfortunatly fsync on ext3 means 'write everything in memory out to disk, not
just the data from this process'.
Comment 2 Milan Broz 2008-07-04 12:32:29 EDT
There is commit in 2.6.26 kernel (adding cond_resched()) in dmcrypt code, which
should help in this situation.
(System still need wait for io to finish, but other running application should
be more responsible.)
Comment 3 Milan Broz 2008-08-26 07:13:14 EDT
cond_resched() call is in 2.6.26+ kernels, it should help in some situations.

There are still some situations when system will wait for IO - mainly if you have multiple LVs but only one encrypted PV...

closing this rahwide, there is already kernel with this patch.

Note You need to log in before you can comment on or make changes to this bug.