All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] Use real FS block size in fallocate05
Date: Tue, 7 Jan 2020 17:29:34 +0100	[thread overview]
Message-ID: <20200107162933.GA2193@rei.lan> (raw)
In-Reply-To: <c0d44447-8bd2-8dbe-b865-3323ad6bb5b0@suse.cz>

Hi!
> > Why realloc()? Each filesystem is tested in separately forked process so
> > buf can't be anything but NULL here.
> > 
> > So this should just simply be SAFE_MALLOC() and this piece of code, the
> > part that gets the blocksize and allocates the buffer should be moved
> > into the test setup() function that is executed also once per
> > filesystem. And the free should be in the test cleanup().
> > 
> > That way we would allocate the buffer only once if the test was executed
> > with -i option.
> 
> Where is this control flow documented? When some behavior is not
> documented, I assume it may change without notice and write my code so
> that it will work in every case.

Unfortunately at the moment only in the lib/tst_test.c source code.

I want to write down a design document for the library, that would
explain the more complicated parts and decisions, but I'm not sure when
I will get to that.

> >> -	tst_res(TPASS | TERRNO, "fallocate() on full FS");
> >> +	for (tmp = extsize; tmp > 0; tmp -= TST_RET) {
> >> +		TEST(write(fd, buf, MIN(bufsize, tmp)));
> >>  
> >> -	ret = fallocate(fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, 0, FALLOCATE_SIZE);
> >> -	if (ret == -1) {
> >> -		if (errno == EOPNOTSUPP)
> >> +		if (TST_RET <= 0)
> >> +			tst_brk(TFAIL | TTERRNO, "write() failed unexpectedly");
> > 
> > tst_brk(TFAIL, is not allowed at the moment, see:
> > 
> > https://github.com/linux-test-project/ltp/issues/462
> > 
> > The only current solution is to tst_res() + return
> > 
> > Also shouldn't we check for the write size here as well?
> 
> I'll fix the tst_brk().
> 
> The code above will either fill the extra allocated space to the last
> byte, or hit the tst_brk(). No other result is possible. I don't want to
> pedantically check for short writes because we're not testing write() here.
> 
> I'll implement the rest of your suggestions and resubmit when we get a
> reply from Btrfs devs.

Ok, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz

      reply	other threads:[~2020-01-07 16:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28  9:36 [LTP] [PATCH 0/1] Use real FS block size in fallocate05 Martin Doucha
2019-11-28  9:36 ` [LTP] [PATCH 1/1] " Martin Doucha
2019-11-28 17:47   ` Petr Vorel
2019-11-29  9:54     ` Martin Doucha
2019-11-29 12:01   ` Jan Stancek
2019-11-29 15:25     ` Martin Doucha
2019-11-29 16:17       ` Jan Stancek
2019-12-04 10:38         ` Martin Doucha
2019-12-13 13:40           ` Cyril Hrubis
2019-12-17 13:17             ` [LTP] [PATCH v2] " Martin Doucha
2019-12-17 21:02               ` Jan Stancek
2019-12-18  9:09                 ` Martin Doucha
2019-12-18 10:01                   ` Martin Doucha
2019-12-18 10:07                     ` Jan Stancek
2019-12-18 13:15                       ` [LTP] [PATCH v3] " Martin Doucha
2020-01-02 10:01                         ` Jan Stancek
2020-01-07 15:21                         ` Cyril Hrubis
2020-01-07 15:50                           ` Martin Doucha
2020-01-13 12:16                             ` Martin Doucha
2020-01-13 13:16                               ` Qu WenRuo
2020-01-13 13:25                                 ` Martin Doucha
2020-01-13 13:30                                   ` Qu WenRuo
2020-01-07 16:09                           ` Martin Doucha
2020-01-07 16:29                             ` Cyril Hrubis [this message]

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=20200107162933.GA2193@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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.