All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Christoph Anton Mitterer <calestyo@scientia.net>,
	Duncan <1i5t5.duncan@cox.net>,
	linux-btrfs@vger.kernel.org
Subject: Re: btrfs: poor performance on deleting many large files
Date: Mon, 14 Dec 2015 15:27:11 -0500	[thread overview]
Message-ID: <566F261F.4040705@gmail.com> (raw)
In-Reply-To: <1450121957.6629.41.camel@scientia.net>

On 2015-12-14 14:39, Christoph Anton Mitterer wrote:
> On Mon, 2015-12-14 at 09:24 -0500, Austin S. Hemmelgarn wrote:
>> Unless things have changed very recently, even many modern systems
>> update atime on read-only filesystems, unless the media itself is
>> read-only.
> Seriously? Oh... *sigh*...
> You mean as in Linux, ext*, xfs?
Possibly, I know that Windows 7 does it, and I think OS X and OpenBSD do 
it, but I'm not sure about Linux.
>
>> If you have software that actually depends on atimes, then that
>> software
>> is broken (and yes, I even feel this way about Mutt).
> I don't disagree here :D
>
>> The way atimes
>> are implemented on most systems breaks the semantics that almost
>> everyone expects from them, because they get updated for anything
>> that
>> even looks sideways at the inode from across the room.  Most software
>> that uses them expects them to answer the question 'When were the
>> contents of this file last read?', but they can get updated even for
>> stuff like calculating file sizes, listing directory contents, or
>> modifying the file's metadata.
> Sure... my point here again was, that I try to look every now and then
> at the whole thing from the pure-end-user side:
> For them, the default is relatime, and they likely may not want to
> change that because they have no clue on how much further effects this
> may have (or not).
> So as long as Linux doesn't change it's defaults to noatime, leaving
> things up to broken software (i.e. to get fixed), I think it would be
> nice for the end-user, to have e.g. snapshots be "save" (from the
> write-amplification on read) out of the box.
AFAIUI, the _only_ reason that that is still the default is because of 
Mutt, and that won't change as long as some of the kernel developers are 
using Mutt for e-mail and the Mutt developers don't realize that what 
they are doing is absolutely stupid.

FWIW, both Duncan and I have our own copy of the sources patched to 
default to noatime, and I know a number of embedded Linux developers who 
do likewise, and I've even heard talk in the past of some distributions 
possibly using such patches themselves (although it always ends up not 
happening, because of Mutt).
>
> My idea would be basically, that having a noatime btrfs-property, which
> is perhaps even set automatically, would be an elegant way of doing
> that.
> I just haven't had time to properly write that up and add is as a
> "feature request" to the projects idea wiki page.
I like this idea.
>
>
> Cheers,
> Chris.
>


  reply	other threads:[~2015-12-14 20:27 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23  1:43 btrfs: poor performance on deleting many large files Mitch Fossen
2015-11-23  6:29 ` Duncan
2015-11-25 21:49   ` Mitchell Fossen
2015-11-26 16:52     ` Duncan
2015-11-26 18:25       ` Christoph Anton Mitterer
2015-11-26 23:29         ` Duncan
2015-11-27  0:06           ` Christoph Anton Mitterer
2015-11-27  3:38             ` Duncan
2015-11-28  3:57               ` Christoph Anton Mitterer
2015-11-28  6:49                 ` Duncan
2015-12-12 22:15                   ` Christoph Anton Mitterer
2015-12-13  7:10                     ` Duncan
2015-12-16 22:14                       ` Christoph Anton Mitterer
2015-12-14 14:24                     ` Austin S. Hemmelgarn
2015-12-14 19:39                       ` Christoph Anton Mitterer
2015-12-14 20:27                         ` Austin S. Hemmelgarn [this message]
2015-12-14 21:30                           ` Lionel Bouton
2015-12-14 23:25                             ` Christoph Anton Mitterer
2015-12-15  1:49                               ` Duncan
2015-12-15  2:38                                 ` Lionel Bouton
2015-12-16  8:10                                   ` Duncan
2015-12-14 23:10                           ` Christoph Anton Mitterer
2015-12-14 23:16                           ` project idea: per-object default mount-options / more btrfs-properties / chattr attributes (was: btrfs: poor performance on deleting many large files) Christoph Anton Mitterer
2015-12-15  2:08                           ` btrfs: poor performance on deleting many large files Duncan
2015-12-15  4:05                       ` Chris Murphy
2015-11-27  1:49     ` Qu Wenruo
2015-11-23 12:59 ` Austin S Hemmelgarn
2015-11-26  0:23   ` [auto-]defrag, nodatacow - general suggestions?(was: btrfs: poor performance on deleting many large files?) Christoph Anton Mitterer
2015-11-26  0:33     ` Hugo Mills
2015-12-09  5:43       ` Christoph Anton Mitterer
2015-12-09 13:36         ` Duncan
2015-12-14  2:46           ` Christoph Anton Mitterer
2015-12-14 11:19             ` Duncan
2015-12-16 23:39           ` Kai Krakow
2015-12-14  1:44       ` Christoph Anton Mitterer
2015-12-14 10:51         ` Duncan
2015-12-16 23:55           ` Christoph Anton Mitterer
2015-11-26 23:08     ` Duncan
2015-12-09  5:45       ` Christoph Anton Mitterer
2015-12-09 16:36         ` Duncan
2015-12-16 21:59           ` Christoph Anton Mitterer
2015-12-17  4:06             ` Duncan
2015-12-18  0:21               ` Christoph Anton Mitterer
2015-12-17  4:35             ` Duncan
2015-12-17  5:07             ` Duncan
2015-12-17  5:12             ` Duncan
2015-12-17  6:00             ` Duncan
2015-12-17  6:01             ` Duncan

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=566F261F.4040705@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=1i5t5.duncan@cox.net \
    --cc=calestyo@scientia.net \
    --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 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.