From: Eric Sandeen <sandeen@sandeen.net>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs_io: fix random pread/pwrite to honor offset
Date: Wed, 09 Apr 2014 15:55:09 -0500 [thread overview]
Message-ID: <5345B3AD.5020805@sandeen.net> (raw)
In-Reply-To: <5345B209.5040906@sgi.com>
On 4/9/14, 3:48 PM, Mark Tinguely wrote:
> On 04/09/14 14:15, Eric Sandeen wrote:
>> xfs_io's pread & pwrite claim to support a random IO mode
>> where it will do random IOs between offset & offset+len.
>>
>> However, offset was ignored, and we did the IOs between 0
>> and len instead.
>>
>> Clang caught this by pointing out that the calculated/normalized
>> "offset" variable was never read.
>>
>> (NB: If the range is larger than RAND_MAX, these functions don't
>> work, but that's always been true, so I'll leave it for another
>> day...)
>>
>> Signed-off-by: Eric Sandeen<sandeen@redhat.com>
>> ---
>>
>> I haven't tested this w/ xfstests but I don't see anyone who calls
>> pread/pwrite with "-R" (and it's not documented in the manpage!)
>>
>> diff --git a/io/pread.c b/io/pread.c
>> index a42baed..465c22b 100644
>> --- a/io/pread.c
>> +++ b/io/pread.c
>> @@ -246,7 +246,7 @@ read_random(
>
> offset can be the end of file offset. Do we care that the read (/write)
> could start or end past the end of file?
It now behaves the same as a normal forward read does if you tell it
to go past EOF:
xfs_io> truncate 1g
xfs_io> pread 1g 1m
read 0/1048576 bytes at offset 1073741824
0.000000 bytes, 0 ops; 0.0000 sec (0.000000 bytes/sec and 0.0000 ops/sec)
xfs_io> pread -R 1g 1m
read 0/1048576 bytes at offset 1073741824
0.000000 bytes, 0 ops; 0.0000 sec (0.000000 bytes/sec and 0.0000 ops/sec)
so I think it's ok?
>>
>> *total = 0;
>> while (count > 0) {
>> - off = ((random() % range) / buffersize) * buffersize;
>> + off = ((offset + (random() % range)) / buffersize) * buffersize;
>> bytes = do_pread(fd, off, buffersize, buffersize);
>> if (bytes == 0)
>> break;
>
> Looks like this was introduced in:
> commit 8fb2237e65555ff540e8b6108ffccfffefe239ac
> Author: Nathan Scott <nathans@sgi.com>
> Date: Fri Nov 11 14:25:18 2005 +0000
>
> Provide further debugging options and tweaks for analysing the read/write paths.
> Merge of master-melb:xfs-cmds:24372a by kenmcd.
>
> ---
>
> If it was broken for 8.5 years, I think it could be removed.
Eh, could, or we could fix it. :) I suppose this means it needs a test... :/
-Eric
> --Mark.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-04-09 20:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 19:15 [PATCH] xfs_io: fix random pread/pwrite to honor offset Eric Sandeen
2014-04-09 20:48 ` Mark Tinguely
2014-04-09 20:55 ` Eric Sandeen [this message]
2014-04-11 4:48 ` Dave Chinner
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=5345B3AD.5020805@sandeen.net \
--to=sandeen@sandeen.net \
--cc=tinguely@sgi.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.