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 159984 - EXT3 in RHEL 4 doesn't support O_DIRECT with data=journal mode
Summary: EXT3 in RHEL 4 doesn't support O_DIRECT with data=journal mode
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-09 21:40 UTC by Wendy Cheng
Modified: 2010-10-22 03:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-22 19:55:25 UTC


Attachments (Terms of Use)

Description Wendy Cheng 2005-06-09 21:40:43 UTC
Description of problem:

The ext3_journalled_aops doesn't define .direct_IO. This causes applications
that have O_DIRECT in their open flags fail universally in any ext3 filesystem
mounted with "data=journal" mode due to the following checking in dentry_open()
called by sys_open -> filp_open route:

        /* NB: we're sure to have correct a_ops only after f_op->open */
        if (f->f_flags & O_DIRECT) {
                if (!f->f_mapping->a_ops || !f->f_mapping->a_ops->direct_IO) {
                        fput(f);
                        f = ERR_PTR(-EINVAL);
                }
        }


static struct address_space_operations ext3_writeback_aops = {
        .readpage       = ext3_readpage,
        .readpages      = ext3_readpages,
        .writepage      = ext3_writeback_writepage,
        .sync_page      = block_sync_page,
        .prepare_write  = ext3_prepare_write,
        .commit_write   = ext3_writeback_commit_write,
        .bmap           = ext3_bmap,
        .invalidatepage = ext3_invalidatepage,
        .releasepage    = ext3_releasepage,
        .direct_IO      = ext3_direct_IO,
};
                                                                                
static struct address_space_operations ext3_journalled_aops = {
        .readpage       = ext3_readpage,
        .readpages      = ext3_readpages,
        .writepage      = ext3_journalled_writepage,
        .sync_page      = block_sync_page,
        .prepare_write  = ext3_prepare_write,
        .commit_write   = ext3_journalled_commit_write,
        .set_page_dirty = ext3_journalled_set_page_dirty,
        .bmap           = ext3_bmap,
        .invalidatepage = ext3_invalidatepage,
        .releasepage    = ext3_releasepage,
};

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


How reproducible:
Each time and everytime.


Steps to Reproduce:
1. Mount the filesystem with data=journal mode.
2. Write a test program with O_DIRECT in its flags.
3. Watch the open call return error with "invalid argument".
  
Actual results:


Expected results:


Additional info:
* I'm not really sure this is an oversignt or intentional.
* AS2.1 and RHEL 3 do not have this restriction.
* Upstream 2.6 kernel does *not* have this functionality either.

Comment 1 Wendy Cheng 2005-06-09 21:44:32 UTC
I vote we support it :) .. Will enable the call to see whether it will break
anything obvious.

Be aware that with this restriction, admin can't freely switch between different
modes of mount options. 

Comment 2 Wendy Cheng 2005-06-09 22:02:54 UTC
Well, the consensus is that this combination (data=journal and O_DIRECT) doesn't
make much sense. We'll work on it if there is really a genuine need. 

TAM, please pass this comment back to the customer. 

Comment 3 Stephen Tweedie 2005-06-09 22:12:20 UTC
To be specific, data=journal says journal all data; O_DIRECT says write data
straight to disk.  They are in direct conflict.

This combination is really an undocumented edge-case between two options.  It's
not clear that there's any obviously correct interpretation for it; it falls
into the undefined grey area between the two options.  


Comment 5 Stephen Tweedie 2006-03-22 19:55:25 UTC
IT has been closed, closing the bug too.



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