public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/fallocate04: Fix on Btrfs
Date: Mon, 29 Aug 2016 14:36:29 +0200	[thread overview]
Message-ID: <20160829123628.GC30021@rei.lan> (raw)
In-Reply-To: <57C42798.3010008@oracle.com>

Hi!
> I understand that the size might be larger and we are allocating in 
> chunks for
> that reason. But here we have "cache" that equals the size of 
> allocation...  it just looks suspicious.

I know that this feels like an workaround, but I've been told that it's
OK. My guess is that it has something to do with the COW, it looks like
the whole write is done to a different set of blocks in this case and
that the preallocated blocks are discarded later when Btrfs figures out
that we do not need these. But that is just a guess, I'm not Btrfs
expert and I do not want to spend a week trying to figure out what
exactly is going on here. If you know somebody who can explain this
better, I would be glad to hear it.

> It's true, it doesn't matter if we have plenty of space and if we are 
> testing writes that shouldn't return ENOSPC.

That is the reason why I proposed this patch.

> > Another interesting testcase would be doing the same on the LTP loopback
> > device that would be filled up after the file has been preallocated.
> > That would likely force different codepath in the FS since there would
> > be no avaialable free space left...
> 
> On btrfs it will be hard to do, I mean filling free space :)

We can write to file(s) in a loop until we get ENOSPC, that should be as
close to real out-of-free-space situation as possible.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2016-08-29 12:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 16:53 [LTP] [PATCH] syscalls/fallocate04: Fix on Btrfs Cyril Hrubis
2016-08-26 11:17 ` Stanislav Kholmanskikh
2016-08-26 12:08   ` Alexey Kodanev
2016-08-29  9:44     ` Cyril Hrubis
2016-08-29 12:16       ` Alexey Kodanev
2016-08-29 12:36         ` Cyril Hrubis [this message]
2016-08-31 14:07 ` 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=20160829123628.GC30021@rei.lan \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox