From: Oleg Drokin <green@namesys.com>
To: linux-kernel@vger.kernel.org
Subject: Spurious -EIO when reading a file being written with O_DIRECT?
Date: Wed, 6 Aug 2003 15:08:05 +0400 [thread overview]
Message-ID: <20030806110805.GG14457@namesys.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
Hello!
We were reported a problem where if a file being written in directio mode
and being read at the same time (in "normal/buffered" mode), then reading
process gets -EIO when near the end of file.
Initially I thought this is reiserfs-only problemm and digged in that
direction, but then it turned out reiserfs does everything correctly
and the VFS itself seems to be racey (my current suspiction is directio
process uses get_block() that extends the file <schedule> reading process
gets the buffer and submits io, then waits for page to become uptodate
<schedule> direct io process unmaps buffer's metadata
As a result - that page never becomes uptodate and we get -EIO from do_generic_file_read. )
If I take i_sem around call to do_generic_file_read in generic_file_read (in 2.4.21-pre10),
that of course helps (this is of course not a correct fix, but just a demonstration
that some VFS race is in place).
The same problem can be observed on ext2 in both 2.4.21-pre10 and in 2.6.0-test2
Attached is test_directio.c program, compile it and run with some filename as argument,
immediately start "tail" with same filename and you'd get almost immediate
I/O error from tail on 2.4 and you'd get same I/O error in 2.6 only after some more waiting.
Is this something known and expected (or may be somebody have a fix already? ;) )?
Bye,
Oleg
[-- Attachment #2: test_directio.c --]
[-- Type: text/plain, Size: 633 bytes --]
#include <stdio.h>
#include <fcntl.h>
#include <stdint.h>
#define BLOCK_SIZE (4096)
#warning ARCH DEPENDENT fixup for your arch
#define O_DIRECT 040000 // ARCH DEPENDENT fixup for your arch */
static char buf[128 * BLOCK_SIZE];
int main(int argc, char** argv)
{
int fd;
char* aligned_buf = (char*)(( (uintptr_t)&buf + (BLOCK_SIZE-1)) & ~(BLOCK_SIZE-1));
int aligned_size = sizeof(buf) - BLOCK_SIZE;
if (-1 == ( fd = open (argv[1], O_RDWR | O_CREAT | O_DIRECT))) {
perror("open: ");
return 1;
}
while (1) {
if( aligned_size!=write(fd, aligned_buf, aligned_size)) {
perror("write: ");
return 1;
}
}
}
next reply other threads:[~2003-08-06 11:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-06 11:08 Oleg Drokin [this message]
2003-08-06 21:42 ` Spurious -EIO when reading a file being written with O_DIRECT? Andrew Morton
2003-08-07 5:38 ` Oleg Drokin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030806110805.GG14457@namesys.com \
--to=green@namesys.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox