Re: [rfc][patch] mm: direct io less aggressive syncs and invalidates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:

> Jeff Moyer wrote:
>> > Index: linux-2.6/mm/filemap.c
>> > ===================================================================
>> > --- linux-2.6.orig/mm/filemap.c	2008-10-03 11:21:31.000000000 +1000
>> > +++ linux-2.6/mm/filemap.c	2008-10-03 12:00:17.000000000 +1000
>> > @@ -1304,11 +1304,8 @@ generic_file_aio_read(struct kiocb *iocb
>> >  			goto out; /* skip atime */
>> >  		size = i_size_read(inode);
>> >  		if (pos < size) {
>> > -			retval = filemap_write_and_wait(mapping);
>> > -			if (!retval) {
>> > -				retval = mapping->a_ops->direct_IO(READ, iocb,
>> > +			retval = mapping->a_ops->direct_IO(READ, iocb,
>> >  							iov, pos, nr_segs);
>> > -			}
>> 
>> So why is it safe to get rid of this?  Can't this result in reading
>> stale data from disk?
>
> It seems that could be easily tested in one of the test suites, by
> writing a page without O_DIRECT to make a dirty page, then reading the
> same page with O_DIRECT.  Do it a few times to be sure.

Sure, are you volunteering to write this? =)  For completeness, it
should probably do this via mmap, too.

> Do the test suites verify O_DIRECT / page-cache coherency?

aio-dio-regress has a couple of targeted tests, but nothing I would call
comprehensive.  I know that during the development of the direct I/O
code, there were some tests kicking around for this.  The small test
cases I can find include:

/*
 * aiodio_sparse - issue async O_DIRECT writes to holes is a file while
 *      concurrently reading the file and checking that the read never reads
 *      uninitailized data.
 */

dio_sparse -- same theme but no async I/O

aiodio_append -- this seems to fork a child which continually seeks to
the end of the file and tries to read data.  Meanwhile, the parent
continually appends zeroed data to the file using async direct I/O.  If
the child ever reads anything other than zeroes, it kicks an error.

dio_truncate -- 
        /*
         * Parent creates a zero file using DIO.
         * Truncates it to zero
         * Create another file with '0xaa'
         */
I have no idea why it creates a different file and fills it with 0xaa.
The child process continually reads the first file, ensuring that all of
the returned data is zeroes.

I'll see about incorporating the above into aio-dio-regress.

Cheers,

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux