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 158350 - o_direct does not work with mdadm(/dev/md) devices
Summary: o_direct does not work with mdadm(/dev/md) devices
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mdadm
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Doug Ledford
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-20 19:33 UTC by Joseph Salisbury
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 19:01:49 UTC


Attachments (Terms of Use)

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 Product and 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.


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