Bug 158350 - o_direct does not work with mdadm(/dev/md) devices
o_direct does not work with mdadm(/dev/md) devices
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mdadm (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-20 15:33 EDT by Joseph Salisbury
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:01:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joseph Salisbury 2005-05-20 15:33:14 EDT
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 Product and Program Management 2007-10-19 15:01:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.