From: "Darrick J. Wong" <djwong@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: zlang@kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] fsstress: add support for RWF_DONTCACHE
Date: Tue, 7 Jan 2025 09:30:49 -0800 [thread overview]
Message-ID: <20250107173049.GQ6160@frogsfrogsfrogs> (raw)
In-Reply-To: <32edc8e2-f338-44d3-9070-4be4b5fc99a2@kernel.dk>
On Mon, Jan 06, 2025 at 07:16:17PM -0700, Jens Axboe wrote:
> On 1/6/25 7:11 PM, Darrick J. Wong wrote:
> >> +void
> >> +read_dontcache_f(opnum_t opno, long r)
> >> +{
> >> + int e;
> >> + pathname_t f;
> >> + int fd;
> >> + int64_t lr;
> >> + off64_t off;
> >> + struct stat64 stb;
> >> + int v;
> >> + char st[1024];
> >> + struct iovec iov;
> >> + int flags;
> >> +
> >> + init_pathname(&f);
> >> + if (!get_fname(FT_REGFILE, r, &f, NULL, NULL, &v)) {
> >> + if (v)
> >> + printf("%d/%lld: read - no filename\n", procid, opno);
> >> + free_pathname(&f);
> >> + return;
> >> + }
> >> + fd = open_path(&f, O_RDONLY);
> >> + e = fd < 0 ? errno : 0;
> >> + check_cwd();
> >> + if (fd < 0) {
> >> + if (v)
> >> + printf("%d/%lld: read - open %s failed %d\n",
> >> + procid, opno, f.path, e);
> >> + free_pathname(&f);
> >> + return;
> >> + }
> >> + if (fstat64(fd, &stb) < 0) {
> >> + if (v)
> >> + printf("%d/%lld: read - fstat64 %s failed %d\n",
> >> + procid, opno, f.path, errno);
> >> + free_pathname(&f);
> >> + close(fd);
> >> + return;
> >> + }
> >> + inode_info(st, sizeof(st), &stb, v);
> >> + if (stb.st_size == 0) {
> >> + if (v)
> >> + printf("%d/%lld: read - %s%s zero size\n", procid, opno,
> >> + f.path, st);
> >> + free_pathname(&f);
> >> + close(fd);
> >> + return;
> >> + }
> >> + lr = ((int64_t)random() << 32) + random();
> >> + off = (off64_t)(lr % stb.st_size);
> >> + iov.iov_len = (random() % FILELEN_MAX) + 1;
> >> + iov.iov_base = malloc(iov.iov_len);
> >
> > Should there be a check for null iov_base after the allocation?
>
> Nothing else in fsstress seems to bother with malloc() failures, which
> at least on Linux, is probably fair game.
lol ok.
> >> + flags = have_rwf_dontcache ? RWF_DONTCACHE : 0;
> >> + e = preadv2(fd, &iov, 1, off, flags) < 0 ? errno : 0;
> >> + if (have_rwf_dontcache && e == EOPNOTSUPP)
> >
> > ...and should this set have_rwf_dontcache = 0?
>
> I don't think so? If we get EOPNOTSUPP and we don't have dontcache, then
> it's a fatal condition. fsstress defaults to it being available, so we
> may very well run into EOPNOTSUPP and then just do a regular read or
> write for that case. We could probably do:
>
> if (have_rwf_dontcache && e == EOPNOTSUPP) {
> have_rwf_dontcache = 0;
> e = preadv2(fd, &iov, 1, off, 0) < 0 ? errno : 0;
> }
Yep, that's exactly what I was thinking. :)
--D
> here and on the write side, at least then we won't repeatedly try
> RWF_DONTCACHE if we hit EOPNOTSUPP. But in terms of logic, it should be
> correct as-is.
>
> --
> Jens Axboe
>
next prev parent reply other threads:[~2025-01-07 17:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 17:48 [PATCHSET 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-06 17:48 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 2:11 ` Darrick J. Wong
2025-01-07 2:16 ` Jens Axboe
2025-01-07 17:30 ` Darrick J. Wong [this message]
2025-01-06 17:48 ` [PATCH 2/2] fsx: " Jens Axboe
2025-01-07 2:09 ` Darrick J. Wong
2025-01-07 2:12 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2025-01-07 16:05 [PATCHSET v2 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-07 16:05 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 17:31 ` Darrick J. Wong
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=20250107173049.GQ6160@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=axboe@kernel.dk \
--cc=fstests@vger.kernel.org \
--cc=zlang@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