Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

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:

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.