Bug 159984 - EXT3 in RHEL 4 doesn't support O_DIRECT with data=journal mode
EXT3 in RHEL 4 doesn't support O_DIRECT with data=journal mode
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-09 17:40 EDT by Wendy Cheng
Modified: 2010-10-21 23:03 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-22 14:55:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wendy Cheng 2005-06-09 17:40:43 EDT
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 17:44:32 EDT
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 18:02:54 EDT
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 18:12:20 EDT
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 14:55:25 EST
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.