Bug 158350

Summary: o_direct does not work with mdadm(/dev/md) devices
Product: Red Hat Enterprise Linux 3 Reporter: Joseph Salisbury <jts>
Component: mdadmAssignee: Doug Ledford <dledford>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:01:49 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 Joseph Salisbury 2005-05-20 19:33:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
This is a similar issue that is described in bugzilla 131981.  

However, O_DIRECT will not work with an ext3 filesystem built on a mdadm device.  The mdadm device is a RAID0 stripe across 12 spindles.  The device was created with the command:

mdadm -C /dev/md2  -c 64 -l raid0 -n 12 /dev/sdc2 /dev/sdd2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdh2 /dev/sdi2 /dev/sdj2 /dev/sdk2 /dev/sdl2 /dev/sdm2 /dev/sdn2

When attempting to mount oracle, the database cannot open the controlfile with O_DIRECT.  

Strace output:
 stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 20
lseek(20, 0, SEEK_SET)                  = 0
read(20, 0xbfff7a00, 512)               = -1 EINVAL (Invalid argument)
close(20)                               = 0
stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 20
close(20)                               = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 20
fcntl64(20, F_SETFD, FD_CLOEXEC)        = 0
io_submit(0xb6b6a000, 0x1, 0xbfff799c)  = 1
io_getevents(0xb6b6a000, 0x1, 0x1, 0xbfff7da0, 0xbfff792c) = 1
fcntl64(20, F_GETFL)                    = 0xd002 (flags
O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE)
fcntl64(20, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) =
0


The mdadm layer was taken out of the configuration and the filesystem built directly ontop of the /dev/sd device, which is using an adaptec scsi adapter.  Oracle could then open the datafiles with O_DIRECT without any issue:

stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 14
lseek(14, 0, SEEK_SET)                  = 0
read(14, "\0\302\0\0\0\0\300\377\0\0\0\0\0\0\0\0\32\372\0\0\0@\0"...,
512) = 512
close(14)                               = 0
open("/raid0_fs/tpcc_datafiles/control_001",O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 14
fcntl64(14, F_SETFD, FD_CLOEXEC)        = 0
fcntl64(14, F_GETFL)                    = 0xd002
(flagsO_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE)
fcntl64(14, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) =
0
gettimeofday({1116614925, 48725}, NULL) = 0
pread(14, "\25\302\0\0\1\0\0\0\242\4\0\0\377\377\1\4\204S\0\0\0\0"...,
2048, 16384) = 2048
gettimeofday({1116614925, 49578}, NULL) = 0
stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 15
close(15)                          


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create an ext3 filsystem on top of a mdadm device.
2. Try to mount an Oracle database using odirect.


  

Actual Results:  stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 20
lseek(20, 0, SEEK_SET)                  = 0
read(20, 0xbfff7a00, 512)               = -1 EINVAL (Invalid argument)
close(20)                               = 0
stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 20
close(20)                               = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 20
fcntl64(20, F_SETFD, FD_CLOEXEC)        = 0
io_submit(0xb6b6a000, 0x1, 0xbfff799c)  = 1
io_getevents(0xb6b6a000, 0x1, 0x1, 0xbfff7da0, 0xbfff792c) = 1
fcntl64(20, F_GETFL)                    = 0xd002 (flags
O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE)
fcntl64(20, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) =
0

Expected Results:  stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 14
lseek(14, 0, SEEK_SET)                  = 0
read(14, "\0\302\0\0\0\0\300\377\0\0\0\0\0\0\0\0\32\372\0\0\0@\0"...,
512) = 512
close(14)                               = 0
open("/raid0_fs/tpcc_datafiles/control_001",O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 14
fcntl64(14, F_SETFD, FD_CLOEXEC)        = 0
fcntl64(14, F_GETFL)                    = 0xd002
(flagsO_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE)
fcntl64(14, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) =
0
gettimeofday({1116614925, 48725}, NULL) = 0
pread(14, "\25\302\0\0\1\0\0\0\242\4\0\0\377\377\1\4\204S\0\0\0\0"...,
2048, 16384) = 2048
gettimeofday({1116614925, 49578}, NULL) = 0
stat64("/raid0_fs/tpcc_datafiles/control_001", {st_mode=S_IFREG|0644,
st_size=12582912, ...}) = 0
open("/raid0_fs/tpcc_datafiles/control_001",
O_RDONLY|O_DIRECT|O_LARGEFILE) = 15
close(15)                          


Additional info:

Comment 1 RHEL Program Management 2007-10-19 19:01:49 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.