From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: NeilBrown <neilb@suse.de>,
linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v5 5/5] nfs: Run on btrfs, ext4, xfs
Date: Fri, 5 May 2023 00:00:37 +0200 [thread overview]
Message-ID: <20230504220037.GB4244@pevik> (raw)
In-Reply-To: <ZFO6ywouPkmNKtkr@yuki>
> Hi!
> > nfs_get_remote_path()
> > @@ -210,6 +213,7 @@ nfs_cleanup()
> > grep -q "$local_dir" /proc/mounts && umount $local_dir
> > n=$(( n + 1 ))
> > done
> > + sleep 2
> > n=0
> > for i in $VERSION; do
> > @@ -219,12 +223,15 @@ nfs_cleanup()
> > if tst_net_use_netns; then
> > if test -d $remote_dir; then
> > exportfs -u *:$remote_dir
> > + sleep 1
> > rm -rf $remote_dir
> > fi
> > else
> > tst_rhost_run -c "test -d $remote_dir && exportfs -u *:$remote_dir"
> > + sleep 1
> > tst_rhost_run -c "test -d $remote_dir && rm -rf $remote_dir"
> > fi
> > +
> > n=$(( n + 1 ))
> > done
> Generally I'm not happy about the sleeps in the code, the main problem
> is that the test still may fail in a case that something was slower than
> usuall and we decided to proceed after we slept for a pre-defined
> interval. Ideally these should be replaced with a active waiting, i.e.
> loop that checks some condition 10 times in a second or so. Hoewever I'm
> okay with getting this in so that we manage to have these tests in
> before the release and fixing it later on.
I wonder myself what is wrong and if there is a problem with my code (likely) or
with nfsd or with loop device (Christoph Hellwig has been changing
drivers/block/loop.c quite a lot).
Because if first umount is too early, it does not recover (i.e. tst_umount
contain 50 times trying to umount with 100ms, and that does not help).
I also wonder how should I detect it's ready to be umounted.
I'll have look if losetup "fuser -vm /dev/loop0" would help, but instead of
depending on the device, we'd probably want to look into /proc/mounts, right?
Tomorrow I'll test this:
check_umount()
{
local i
local dir="$1"
local type="${2:-lhost}"
local cmd="grep -q $dir /proc/mounts"
for i in $(seq 50); do
if [ "$type" = "lhost" ]; then
$cmd || return
else
tst_rhost_run -c "$cmd" || return
fi
tst_sleep 100ms
tst_res TWARN "failed to umount '$dir'"
done
}
for i in $VERSION; do
local_dir="$(get_local_dir $i $n)"
grep -q "$local_dir" /proc/mounts && umount $local_dir
# instead of 'sleep 2' below check here:
check_umount "$local_dir"
n=$(( n + 1 ))
done
n=0
for i in $VERSION; do
type=$(get_socket_type $n)
remote_dir="$(get_remote_dir $i $type)"
if tst_net_use_netns; then
if test -d $remote_dir; then
exportfs -u *:$remote_dir
check_umount "$remote_dir" # instead of sleep 1
rm -rf $remote_dir
fi
else
tst_rhost_run -c "test -d $remote_dir && exportfs -u *:$remote_dir"
check_umount "$remote_dir" rhost # instead of sleep 1
tst_rhost_run -c "test -d $remote_dir && rm -rf $remote_dir"
fi
n=$(( n + 1 ))
done
[1] https://gitlab.com/psmisc/psmisc/-/blob/master/src/fuser.c
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-05-04 22:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 13:14 [LTP] [PATCH v5 0/5] NFS: test on btrfs, ext4, xfs filesystems Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 1/5] nfs_lib.sh: Cleanup local and remote directories setup Petr Vorel
2023-05-04 13:58 ` Cyril Hrubis
2023-05-04 21:16 ` Petr Vorel
2023-05-05 10:42 ` Cyril Hrubis
2023-05-05 10:44 ` Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 2/5] nfs_lib.sh: Unexport on proper side on netns Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 3/5] nfs05.sh: Lower down the default values Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 4/5] nfs03.sh: " Petr Vorel
2023-05-05 12:56 ` Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 5/5] nfs: Run on btrfs, ext4, xfs Petr Vorel
2023-05-04 14:01 ` Cyril Hrubis
2023-05-04 22:00 ` Petr Vorel [this message]
2023-05-04 22:02 ` Petr Vorel
2023-05-04 23:23 ` Petr Vorel
2023-05-05 11:08 ` Cyril Hrubis
2023-05-05 12:59 ` Petr Vorel
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=20230504220037.GB4244@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=neilb@suse.de \
/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