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 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.