All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: David Disseldorp <ddiss@suse.de>
Cc: Jeff Layton <jlayton@kernel.org>, Xiubo Li <xiubli@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH] ceph/005: verify correct statfs behaviour with quotas
Date: Wed, 25 May 2022 15:26:15 +0100	[thread overview]
Message-ID: <87tu9dwuwo.fsf@brahms.olymp> (raw)
In-Reply-To: <20220525123659.65270735@suse.de> (David Disseldorp's message of "Wed, 25 May 2022 12:36:59 +0200")

David Disseldorp <ddiss@suse.de> writes:

> On Wed, 25 May 2022 09:53:53 +0100, Luís Henriques wrote:
>
>> David Disseldorp <ddiss@suse.de> writes:
>> 
>> > Hi Luís,
>> >
>> > It looks like this one is still in need of review...  
>> 
>> Ah! Thanks for reminding me about it, David!
>> 
>> >
>> > On Wed, 27 Apr 2022 15:34:09 +0100, Luís Henriques wrote:
>> >  
>> >> When using a directory with 'max_bytes' quota as a base for a mount,
>> >> statfs shall use that 'max_bytes' value as the total disk size.  That
>> >> value shall be used even when using subdirectory as base for the mount.
>> >> 
>> >> A bug was found where, when this subdirectory also had a 'max_files'
>> >> quota, the real filesystem size would be returned instead of the parent
>> >> 'max_bytes' quota value.  This test case verifies this bug is fixed.
>> >> 
>> >> Signed-off-by: Luís Henriques <lhenriques@suse.de>
>> >> ---
>> >>  tests/ceph/005     | 40 ++++++++++++++++++++++++++++++++++++++++
>> >>  tests/ceph/005.out |  2 ++
>> >>  2 files changed, 42 insertions(+)
>> >>  create mode 100755 tests/ceph/005
>> >>  create mode 100644 tests/ceph/005.out
>> >> 
>> >> diff --git a/tests/ceph/005 b/tests/ceph/005
>> >> new file mode 100755
>> >> index 000000000000..0763a235a677
>> >> --- /dev/null
>> >> +++ b/tests/ceph/005
>> >> @@ -0,0 +1,40 @@
>> >> +#! /bin/bash
>> >> +# SPDX-License-Identifier: GPL-2.0
>> >> +# Copyright (C) 2022 SUSE Linux Products GmbH. All Rights Reserved.
>> >> +#
>> >> +# FS QA Test 005
>> >> +#
>> >> +# Make sure statfs reports correct total size when:
>> >> +# 1. using a directory with 'max_byte' quota as base for a mount
>> >> +# 2. using a subdirectory of the above directory with 'max_files' quota
>> >> +#
>> >> +. ./common/preamble
>> >> +_begin_fstest auto quick quota
>> >> +
>> >> +_supported_fs generic
>> >> +_require_scratch
>> >> +
>> >> +_scratch_mount
>> >> +mkdir -p $SCRATCH_MNT/quota-dir/subdir
>> >> +
>> >> +# set quotas
>> >> +quota=$((1024*10000))
>> >> +$SETFATTR_PROG -n ceph.quota.max_bytes -v $quota $SCRATCH_MNT/quota-dir
>> >> +$SETFATTR_PROG -n ceph.quota.max_files -v $quota $SCRATCH_MNT/quota-dir/subdir
>> >> +_scratch_unmount
>> >> +
>> >> +SCRATCH_DEV=$SCRATCH_DEV/quota-dir _scratch_mount  
>> >
>> > Aside from the standard please-quote-your-variables gripe, I'm a little  
>> 
>> Sure, I'll fix those in next iteration.
>> 
>> > confused with the use of SCRATCH_DEV for this test. Network FSes where
>> > mkfs isn't provided don't generally use it. Is there any way that this
>> > could be run against TEST_DEV, or does the umount / mount complicate
>> > things too much?  
>> 
>> When I looked at other tests doing similar things (i.e. changing the mount
>> device during the test), they all seemed to be using SCRATCH_DEV.  I guess
>> that I could change TEST_DEV instead.  I'll revisit this and see if that
>> works.
>> 
>> Anyway, regarding the usage of SCRATCH_DEV in cephfs, I've used several
>> different approaches:
>> 
>> - Use 2 different filesystems created on the same cluster,
>> - Use 2 volumes on the same filesystem, or
>> - Simply use 2 directories in the same filesystem.
>
> Looking at _scratch_mkfs($FSTYP=ceph) there is support for scratch
> filesystem reinitialization, so I suppose this should be okay. With
> cephfs we could actually go one step further and call "ceph fs rm/new",
> but that's something for another day :-).

Right, that would require a more complex test setup, with user-space tools
on the test box/VM.  It definitely would be desirable to have such an
option for example in teuthology (the ceph testing framework), but for the
simple runs I usually do on VMs, I'd rather keep the default as-is.

Cheers,
-- 
Luís

  reply	other threads:[~2022-05-25 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 14:34 [PATCH] ceph/005: verify correct statfs behaviour with quotas Luís Henriques
2022-05-24 22:11 ` David Disseldorp
2022-05-25  8:53   ` Luís Henriques
2022-05-25 10:36     ` David Disseldorp
2022-05-25 14:26       ` Luís Henriques [this message]
2022-05-25 10:19 ` Zorro Lang
2022-05-25 14:47   ` Luís Henriques

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=87tu9dwuwo.fsf@brahms.olymp \
    --to=lhenriques@suse.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=ddiss@suse.de \
    --cc=fstests@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=xiubli@redhat.com \
    /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.