All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 1/2] syscalls/sync_file_range: add partial file sync test-case
Date: Wed, 6 Mar 2019 09:54:18 +0100	[thread overview]
Message-ID: <20190306085418.GA14290@rei> (raw)
In-Reply-To: <CAFA6WYOPW0mkmGFbcZRmvhXsOJouUi1d-rcV_-sgKVKpkqSMSA@mail.gmail.com>

Hi!
> > Looking at this the function is nearly the same as the other one, I
> > guess that we may as well define the function as:
> >
> > static void verify_sync_file_range(off64_t off, off64_t size, char byte)
> > {
> >         ...
> > }
> >
> 
> Yeah it could be made common. But we may not be able to reuse it for
> third case you mentioned below.

We may as well add offset and size for the write as well.

> > Also I'm not sure I was clear enough, but I was suggesting to check for
> > upper bound for the synced size as well, which is why I suggested to do
> > full write, sync only part of it, then check that the size was within
> > bounds, i.e. >= size and  <= size + epsilon.
> >
> 
> Do you see any value add of upper bound check? AFAIK, device writes
> continue in back-end and we might not be sure about appropriate value
> for "epsilon".

AFAIK this makes sense as far the file written fits into RAM buffers.
We do write followed by a sync that asks particular range to be written
to the device, so unless we manage to write significant portion of the
file while we are calling the write syscall in a loop we will get quite
close to the expectations. I guess that we can also check how much data
was written right after we finished writing to the file and if that
number is neglectible it would be fairly safe to check for upper bound.
Does that sound reasonable to you?

> > I guess that we can even extend this to call the sync over a range that
> > has been only partially written, but for that we would have to be
> > careful and make sure all the data has been either synced at the end of
> > the test function or use a different file for each test.
> >
> 
> I think using different file for each case looks more appropriate.

Agreed.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2019-03-06  8:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05  7:14 [LTP] [PATCH v2 1/2] syscalls/sync_file_range: add partial file sync test-case Sumit Garg
2019-03-05 14:19 ` Cyril Hrubis
2019-03-06  6:48   ` Sumit Garg
2019-03-06  8:54     ` Cyril Hrubis [this message]
2019-03-07  9:24       ` Sumit Garg

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=20190306085418.GA14290@rei \
    --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.