Bug 117219

Summary: Oracle request for O_DIRECT enhancements
Product: Red Hat Enterprise Linux 3 Reporter: Bryce <root>
Component: coreutilsAssignee: Pete Graner <pgraner>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: laroche
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://oss.oracle.com/projects/ocfs/files/source/RHAT/RHAS3/
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:29:33 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:
Attachments:
Description Flags
Comparison of block size with O_DIRECT use vs normal CP operation
none
O_DIRECT patchs for coreutils-4.5.3-26
none
O_DIRECT patchs to tar-1.3.25-13 (AS3) none

Description Bryce 2004-03-01 18:48:47 UTC
Description of problem:

A while back Seklos ased me to go make the cp/mv/dd/tar and md5sum
programs O_DIRECT aware.

(From recent correspondance):
If you are making a backup of 100gb of data using cp or tar or so, you
flood the pagecache, with odirect=yes you'd not feel anything ,it
might be a tad slower but thats what large blocksizes are for. There
is NO way to backup the database in HOT backup mode if it's on an ocfs
filesystem without these patches, that's because the files are marked
locked on an ocfs filesystem when the DB is up.  Without the patches
the only way to backup is by using rman (which sux).  The patches
don't change default behavior of these utilities, only allows the
setting of O_DIRECT.

Anyway I have here the patchs that I made.
The real attention I gave to cp/mv and they have a vastly more
intelligent way of handling shifting data around.

tar and dd I simply made capable of understanding O_DIRECT, there is
no performance tuning. Likewise with md5sum. It wouldn't be mega
difficult to add,.. just slightly messy but it was outside of my remit
at that time.

Phil
=--=

Patchs and chart to follow.

Comment 1 Bryce 2004-03-01 18:54:26 UTC
Created attachment 98167 [details]
Comparison of block size with O_DIRECT use vs normal CP operation

Comparison of block size with O_DIRECT use vs normal copy (cp) operation.

With O_DIRECT we get a 220% speed boost.
additional testing on an ext2/3 FS shows that there is a speed improvement of
~15-40% depending on system jobs running.

Comment 2 Bryce 2004-03-01 19:36:50 UTC
erm that was unexpected. ok I'm gonna regenerate the patchkit, might
be a wee while... appologies

Phil
=--=

Comment 3 Bryce 2004-03-02 16:49:36 UTC
Created attachment 98197 [details]
O_DIRECT patchs for coreutils-4.5.3-26

This is a set of patchs to provide at LEAST the capability f working when
O_DIRECT is required,..  Note: only cp/mv are actually optimized, the rest are
just tweaked to handle the use of O_DIRECT


tar patchs to follow

Cheers

Phil (aka Bryce)
=--=

Comment 4 Bryce 2004-03-02 17:30:26 UTC
Created attachment 98199 [details]
O_DIRECT patchs to tar-1.3.25-13 (AS3)

These patchs add the --o_direct option to tar

Cheers

Phil (aka Bryce)
=--=

Comment 5 Tim Waugh 2004-03-02 17:57:51 UTC
Thanks.  Please submit new patches, with these things fixed:

o There are a huge number of do-nothing changes, like this:

-  char const* name;
+  char const *name;

  If these are due to files being copied from newer upstream versions,
I would much prefer the patch against the newer upstream version. 
Either way, they make the patch unreadable for the clutter.

o Some #include additions seem not to be needed: 'linux/fs.h', for
instance, seems to be pulled in for no reason in some places.

o Jim Meyering has complained to be before about us including patches
with such things as:

+static void
+parse_o_direct (char *str)
+{
+  if (strstr (str, "yes") != NULL)
+    o_direct_option = 1;
+  if (strstr (str, "y") != NULL)
+    o_direct_option = 1;
+
+  if ((o_direct_option == 0) && (basename(program_name) == ALT_ALIAS))
+    o_direct_option = 1;
+
+  if ((basename(program_name) == ALT_ALIAS) &&
+     ((strstr (str, "n") != NULL) ||
+     (strstr (str, "no") != NULL)))
+    o_direct_option = 0;
+}

The use of strstr here is not really appropriate -- I would expect
'o_direct=yesn' to give an error.  XARGMATCH is written for this purpose.

o Please make sure to update the man pages and info pages with the
additional options.

Comment 6 Bryce 2004-03-02 19:01:12 UTC
Unfortunately noone seems to tidy up their src afterwards through
indent -gnu  which is probably where the " *" -> "* " translations
came from but remember I forward ported that from fileutils from AS2.1
so some of that is expected (if annoying)

The man Pages are updated (in that they are automatically regenerated
 by running <progname> and dumping out the --help text (which is
bizzare but thats how they do it)

I'll check on the info pages

XARGMATCH huh? thats new to me, I'll go have a look at it.


I'm assuming this is a formal rejection of the patchs then. It'll be a
few days before I can rebuild it all in a manner more to your pleasing
(remember I originally built it all as an inhouse change not really
for upstream use)

cheers

Phil
=--=

Comment 11 RHEL Program Management 2007-10-19 19:29:33 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.