OpenSolaris

Printable Version Enter a New Search
Bug ID 6723423
Synopsis UFS slow following large file deletion with fix for 6513858 installed
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:ufs
Keywords bopmail-exception | opl-interest | opl-no-ikkaku | rm | rtiq_regression | spbc_s10uX | ufs | umount
Responsible Engineer Viswanathan Kannappan
Reported Against snv_82 , snv_85 , snv_91 , snv_100 , snv_102 , s10u5_01 , s10u6_01 , s9u8_fcs , s10u4_fcs , solaris_10 , solaris_10u6
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_104
Fixed In snv_104
Release Fixed solaris_nevada(snv_104) , solaris_10u7(s10u7_04) (Bug ID:2167453) solaris_9(Bug ID:2167454,)
Related Bugs 6513858 , 6665421 , 6687760 , 6689947 , 6732740 , 6767300 , 6790471 , 6796125 , 6857624
Submit Date 8-July-2008
Last Update Date 5-October-2009
Description 
Following installation of patch 122300-28 (5.9) or 127866-03 (5.10) umount of a UFS file system becomes very slow if a large file has been deleted prior to the umount.

With 127866-02
 
 # timex umount /mnt 

 real        1:53.80 
 user           0.00 
 sys            0.24 
 
With 127866-03
 
 # timex umount /mnt 
 
 real     1:28:11.61 
 user           0.00 
 sys            0.04
Work Around 
- Disable UFS logging.

  This situation occurs in UFS logging code path and disabling logging would relieve
  the system from this problem.

- Remove the patch which fixes CR 6513858.

  As this is a regression which is introduced by fix to CR 6513858, removing this patch
  will relive this issue.
Comments 
N/A