Andrew Morton <[EMAIL PROTECTED]> writes:

> If filemap_fdatawrite() returns an error, this might be due to some I/O
> problem: dead disk, unplugged cable, etc. Given the generally crappy
> quality of the kernel's handling of such exceptions, there's a good chance
> that the filemap_fdatawait() will get stuck in D state forever.
>
> I don't know how useful that really is - probably not very. Plus, yes, we
> should wait on writeout after a -ENOSPC.
>
> So hum, not sure. My gut feeling is that anything which we can do to help
> the kernel limp along after an I/O error is a good thing, hence the
> don't-wait-after-EIO feature should remain.

I see, thanks for explaining it. Please don't apply patch, I need to
consider it obviously.

./cifs/file.c:
           able to simply do a filemap_fdatawrite/filemap_fdatawait first */
        rc = filemap_fdatawrite(inode->i_mapping);

./cifs/inode.c:
                wbrc = filemap_fdatawrite(direntry->d_inode->i_mapping);

./cifs/cifsfs.c:
                filemap_fdatawrite(inode->i_mapping);
                                rc = filemap_fdatawrite(inode->i_mapping);

./jfs/jfs_txnmgr.c:
                 * on the inode, and calling filemap_fdatawrite on an

./jfs/jfs_logmgr.c:
                write_special_inodes(log, filemap_fdatawrite);
        write_special_inodes(log, filemap_fdatawrite);
                        write_special_inodes(log, filemap_fdatawrite);

./xfs/linux-2.6/xfs_fs_subr.c:
                ret = filemap_fdatawrite(mapping);

./sync.c:
                /* Why? We can still call filemap_fdatawrite */
        ret = filemap_fdatawrite(mapping);
                ret = __filemap_fdatawrite_range(mapping, offset, endbyte,

./ext4/fsync.c:
         * The caller's filemap_fdatawrite()/wait will sync the data.
         * The caller's filemap_fdatawrite() will write the data and
         * filemap_fdatawrite won't do anything (the buffers are clean).

./jbd2/transaction.c:
                ret = filemap_fdatawrite_range(inode->i_vfs_inode->i_mapping,

./ext3/fsync.c:
         * The caller's filemap_fdatawrite()/wait will sync the data.
         * The caller's filemap_fdatawrite() will write the data and
         * filemap_fdatawrite won't do anything (the buffers are clean).

./gfs2/meta_io.c:
        filemap_fdatawrite(mapping);

./gfs2/ops_file.c:
                error = filemap_fdatawrite(inode->i_mapping);
* (hopefully) a no-op due to the VFS having already called filemap_fdatawrite()

./gfs2/glops.c:
                filemap_fdatawrite(metamapping);
                        filemap_fdatawrite(mapping);

./btrfs/transaction.c:
                        filemap_fdatawrite(inode->i_mapping);

./ocfs2/file.c:
        filemap_fdatawrite(inode->i_mapping);

./ocfs2/dlmglue.c:
         * We need this before the filemap_fdatawrite() so that it can
        if (filemap_fdatawrite(mapping)) {

./fs-writeback.c:
                err = filemap_fdatawrite(mapping);

./fat/inode.c:
        * and filemap_fdatawrite is used for the data blocks
               ret = filemap_fdatawrite(mapping);

./nfs/delegation.c:
        filemap_fdatawrite(inode->i_mapping);

./nfsd/vfs.c:
        err = filemap_fdatawrite(inode->i_mapping);

./9p/vfs_super.c:
        filemap_fdatawrite(inode->i_mapping);

/*
* This is exported only for wait_on_page_locked/wait_on_page_writeback.
* Never use this directly!
*/
extern void wait_on_page_bit(struct page *page, int bit_nr);

/*
* Wait for a page to be unlocked.
*
* This must be called with the caller "holding" the page,
* ie with increased "page->count" so that the page won't
* go away during the wait..
*/
static inline void wait_on_page_locked(struct page *page)
{
        if (PageLocked(page))
                wait_on_page_bit(page, PG_locked);
}

/*
* Wait for a page to complete writeback
*/
static inline void wait_on_page_writeback(struct page *page)
{
        if (PageWriteback(page))
                wait_on_page_bit(page, PG_writeback);
}

extern void end_page_writeback(struct page *page);

[linuxkernelnewbies] Linux-Kernel: Re: [PATCH] Fix and add EXPORT_SYMBOL(filemap_write_and_wait)

Reply via email to