From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] readahead02: Fix on Btrfs
Date: Thu, 6 Oct 2016 05:09:30 -0400 (EDT) [thread overview]
Message-ID: <966408417.764925.1475744970952.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20161006081752.GA9210@rei>
----- Original Message -----
> From: "Cyril Hrubis" <chrubis@suse.cz>
> To: ltp@lists.linux.it
> Cc: "Jan Stancek" <jstancek@redhat.com>
> Sent: Thursday, 6 October, 2016 10:17:52 AM
> Subject: [PATCH] [RFC] readahead02: Fix on Btrfs
>
> The Btrfs uses anonymous block devices for its subvolumes hence
> /sys/dev/block/$major:$minor/ is not created for these.
>
> We have to use ioctl(BTRFS_IOC_FS_INFO, ...) to get fs UUID in order to
> map a path on Btrfs to a sysfs path that contains links to the devices.
>
> TODO: What happens to readahead if there is more than one device backing
> the Btrfs filesystem?
>
> Also this is getting absurdly compliated, maybe we should rethink the
> test assertions so that we don't have to rely on reading the
> read_ahead_kb file, perhaps we can just try to guess the maximal size by
> calling the readahead in a loop with increasing size until it fails
> instead.
Syscall itself won't fail, it will silently make shorter read.
If this patch goes through, then reading read_ahead_kb becomes
useless:
https://lkml.org/lkml/2016/7/25/308
Perhaps, we should stop focusing on max size. We could change it to start
with size of entire file, and for subsequent calls update file offset as
max(MIN_SANE_READAHEAD, cache_increase_since_last_call), where MIN_SANE_READAHEAD
would be some small arbitrary number. So there would be a guarantee
it can eventually finish and any smaller readahead than that number would
be considered a failure.
>
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---
> testcases/kernel/syscalls/readahead/readahead02.c | 57
> ++++++++++++++++++++++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/testcases/kernel/syscalls/readahead/readahead02.c
> b/testcases/kernel/syscalls/readahead/readahead02.c
> index 2517a33..3c06596 100644
> --- a/testcases/kernel/syscalls/readahead/readahead02.c
> +++ b/testcases/kernel/syscalls/readahead/readahead02.c
> @@ -42,6 +42,7 @@
> #include <stdint.h>
> #include <unistd.h>
> #include <fcntl.h>
> +#include <linux/btrfs.h>
This will be an issue on old distros/kernels.
Regards,
Jan
next prev parent reply other threads:[~2016-10-06 9:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 8:17 [LTP] [PATCH] [RFC] readahead02: Fix on Btrfs Cyril Hrubis
2016-10-06 9:09 ` Jan Stancek [this message]
2016-10-06 9:32 ` Cyril Hrubis
2016-10-06 9:56 ` Jan Stancek
2016-10-06 11:16 ` Cyril Hrubis
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=966408417.764925.1475744970952.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--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.