All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Doucha <mdoucha@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] Use real FS block size in fallocate05
Date: Mon, 13 Jan 2020 14:25:32 +0100	[thread overview]
Message-ID: <f3211331-b7ec-4d14-7f3b-d8fb5c72c1fe@suse.cz> (raw)
In-Reply-To: <4da4e1ec-d5dc-06e2-bea8-280533f5d022@suse.com>

On 1/13/20 2:16 PM, Qu WenRuo wrote:
> Just a small tip, btrfs defaults to data CoW, and unlike other CoW fs
> (like xfs), btrfs has an extent booking behavior, that even only part of
> a large extent (e.g 128MiB) is referred, the whole extent will not be freed.

I know, I reported the bug where we discussed this.

>>> What's the minimum block device size
>>> where Btrfs will use the same code paths as in real-world use cases?
> 
> Mkfs.btrfs no longer enables --mixed for small fs.
> 
> But btrfs still has a pretty complex minimal device size, it depends on
> profile (-m and -d options).
> 
> If LTP guys want to be safe for single device, it needs 256MiB for
> `mkfs.btrfs -m dup -d dup` to run successfully.
> 
> If only default case (-m dup -d single) is needed, then 128MiB is enough.

Sorry but my question was not about the minimum for mkfs. My question
was about the minimum device size so that the kernel driver will use the
same block allocation logic as on a 100GB+ partition (instead of some
special case allocation logic for tiny block devices).

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

  reply	other threads:[~2020-01-13 13:25 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 [this message]
2020-01-13 13:30                                   ` Qu WenRuo
2020-01-07 16:09                           ` Martin Doucha
2020-01-07 16:29                             ` 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=f3211331-b7ec-4d14-7f3b-d8fb5c72c1fe@suse.cz \
    --to=mdoucha@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.