From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs filesystem keeps allocating new chunks for no apparent reason
Date: Mon, 10 Apr 2017 20:18:42 +0200 [thread overview]
Message-ID: <20170410201842.216893be@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 7ea65b63-d399-c049-d466-681c1df2d025@gmail.com
Am Mon, 10 Apr 2017 13:13:39 -0400
schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:
> On 2017-04-10 12:54, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 18:44:44 +0200
> > schrieb Kai Krakow <hurikhan77@gmail.com>:
> >
> >> Am Mon, 10 Apr 2017 08:51:38 -0400
> >> schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:
> >>
> [...]
> [...]
> >> [...]
> [...]
> [...]
> >>
> >> Did you put it in /etc/fstab only for the rootfs? If yes, it
> >> probably has no effect. You would need to give it as rootflags on
> >> the kernel cmdline.
> >
> > I did a "fgrep lazytime /usr/src/linux -ir" and it reveals only ext4
> > and f2fs know the flag. Kernel 4.10.
> >
> > So probably you're seeing a placebo effect. If you put lazytime for
> > rootfs just only into fstab, it won't have an effect because on
> > initial mount this file cannot be opened (for obvious reasons), and
> > on remount, btrfs seems to happily accept lazytime but it has no
> > effect. It won't show up in /proc/mounts. Try using it in rootflags
> > kernel cmdline and you should see that the kernel won't accept the
> > flag lazytime.
> The command-line also rejects a number of perfectly legitimate
> arguments that BTRFS does understand too though, so that's not much
> of a test.
Which are those? I didn't encounter any...
> I've just finished some quick testing though, and it looks
> like you're right, BTRFS does not support this, which means I now
> need to figure out what the hell was causing the IOPS counters in
> collectd to change in rough correlation with remounting (especially
> since it appears to happen mostly independent of the options being
> changed).
I think that noatime (which I remember you also used?), lazytime, and
relatime are mutually exclusive: they all handle the inode updates.
Maybe that is the effect you see?
> This is somewhat disappointing though, as supporting this would
> probably help with the write-amplification issues inherent in COW
> filesystems. --
Well, relatime is mostly the same thus not perfectly resembling the
POSIX standard. I think the only software that relies on atime is
mutt...
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2017-04-10 18:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 21:28 btrfs filesystem keeps allocating new chunks for no apparent reason Hans van Kranenburg
2016-05-30 11:07 ` Hans van Kranenburg
2016-05-30 19:55 ` Duncan
2016-05-30 21:18 ` Hans van Kranenburg
2016-05-30 21:55 ` Duncan
2016-05-31 1:36 ` Qu Wenruo
2016-06-08 23:10 ` Hans van Kranenburg
2016-06-09 8:52 ` Marc Haber
2016-06-09 10:37 ` Hans van Kranenburg
2016-06-09 15:41 ` Duncan
2016-06-10 17:07 ` Henk Slager
2016-06-11 15:23 ` Hans van Kranenburg
2016-06-09 18:07 ` Chris Murphy
2017-04-07 21:25 ` Hans van Kranenburg
2017-04-07 23:56 ` Peter Grandi
2017-04-08 7:09 ` Duncan
2017-04-08 11:16 ` Hans van Kranenburg
2017-04-08 11:35 ` Hans van Kranenburg
2017-04-09 23:23 ` Hans van Kranenburg
2017-04-10 12:39 ` Austin S. Hemmelgarn
2017-04-10 12:45 ` Kai Krakow
2017-04-10 12:51 ` Austin S. Hemmelgarn
2017-04-10 16:53 ` Kai Krakow
[not found] ` <20170410184444.08ced097@jupiter.sol.local>
2017-04-10 16:54 ` Kai Krakow
2017-04-10 17:13 ` Austin S. Hemmelgarn
2017-04-10 18:18 ` Kai Krakow [this message]
2017-04-10 19:43 ` Austin S. Hemmelgarn
2017-04-10 22:21 ` Adam Borowski
2017-04-11 4:01 ` Kai Krakow
2017-04-11 9:55 ` Adam Borowski
2017-04-11 11:16 ` Austin S. Hemmelgarn
2017-04-10 23:45 ` Janos Toth F.
2017-04-11 3:56 ` Kai Krakow
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=20170410201842.216893be@jupiter.sol.kaishome.de \
--to=hurikhan77@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).