Bug 451738

Summary: kcryptd I/O blockage using encrypted filesystem on LVM
Product: [Fedora] Fedora Reporter: Michael Hampton <error>
Component: kernelAssignee: Milan Broz <mbroz>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: pvrabec
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-26 11:13:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Hampton 2008-06-17 01:34:01 UTC
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-17 01:45:54 UTC
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 16:32:29 UTC
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 11:13:14 UTC
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.