All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Chris Murphy <lists@colorremedies.com>,
	Hendrik Friedel <hendrik@friedels.name>
Cc: Tomasz Kusmierz <tom.kusmierz@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	dave@jikos.cz
Subject: Re: Status of SMR with BTRFS
Date: Thu, 21 Jul 2016 08:46:26 -0400	[thread overview]
Message-ID: <bf3f40ff-cb91-d0b3-e60d-27f4e14cbb37@gmail.com> (raw)
In-Reply-To: <CAJCQCtQNt6fBR85opSHfWuKCzH=-2-pF3ctsWsTF-Eb=JwezWQ@mail.gmail.com>

On 2016-07-20 15:58, Chris Murphy wrote:
> On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel <hendrik@friedels.name> wrote:
>
>> Well, btrfs does write data very different to many other file systems. On
>> every write the file is copied to another place, even if just one bit is
>> changed. That's special and I am wondering whether that could cause
>> problems.
>
> It depends on the application. In practice, the program most
> responsible for writing the file often does a faux-COW by writing a
> whole new (temporary) file somewhere, when that operation completes,
> it then deletes the original, and move+renames the temporary one into
> place where the original one, doing fsync in between each of those
> operations. I think some of this is done via VFS also. It's all much
> more metadata centric than what Btrfs would do on its own.
I'm pretty certain that the VFS itself does not do replace by rename 
type stuff.  BTRFS by nature technically does though, it's the same idea 
as a COW update, just at a higher level, so we're technically doing the 
same thing for every single block that changes.  The only issue I can 
think of in this context with a replace by rename is that you end up 
hitting the metadata trees twice.
>
> I'd expect the write pattern of Btrfs to be similar to f2fs, with
> respect to sequentiality of new writes.
Not necessarily, F2FS is log structured, and while not as much like 
traditional log structured filesystems, it still has a similar long-term 
write pattern to stuff like NILFS2 or LFS.  I've not done as much with 
F2FS specifically, but I can say based on comparison to other log 
structured filesystems that outside of WORM write patterns in userspace, 
BTRFS does not have a similar write pattern to a log structured 
filesystem.  We try to pack stuff into existing allocations pretty 
aggressively, so we end up with most of our writes condensed in a small 
area of the disk.  The only cases I've seen where we get long sequential 
writes are when writing out single files one by one, without having 
anything else running at the same time on the FS.


  reply	other threads:[~2016-07-21 12:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 18:29 Status of SMR with BTRFS Hendrik Friedel
2016-07-15 22:15 ` Tomasz Kusmierz
2016-07-16 10:29   ` Hendrik Friedel
2016-07-17  3:09     ` Tomasz Kusmierz
2016-07-17  9:08       ` Hendrik Friedel
2016-07-17 20:48         ` Henk Slager
2016-07-18 11:22         ` Austin S. Hemmelgarn
2016-07-18 18:31           ` Hendrik Friedel
2016-07-18 18:44             ` Austin S. Hemmelgarn
2016-07-18 19:05               ` Hendrik Friedel
2016-07-18 19:30                 ` Austin S. Hemmelgarn
2016-07-18 22:29                   ` Tomasz Kusmierz
2016-07-20 19:58         ` Chris Murphy
2016-07-21 12:46           ` Austin S. Hemmelgarn [this message]
2016-07-21 13:34             ` Chris Murphy
2016-07-21 14:02               ` Andrei Borzenkov
2016-07-21 14:12               ` Austin S. Hemmelgarn
2016-07-21 14:31                 ` Chris Murphy
2016-07-21 15:35               ` Patrik Lundquist
  -- strict thread matches above, loose matches on Subject: below --
2016-07-17  8:26 Matthias Prager
2016-07-17 20:10 ` Henk Slager
2016-07-17 21:44   ` Matthias Prager
2016-07-18 18:49     ` Jukka Larja
2016-07-21 12:22 Matthias Prager

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=bf3f40ff-cb91-d0b3-e60d-27f4e14cbb37@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=dave@jikos.cz \
    --cc=hendrik@friedels.name \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=tom.kusmierz@gmail.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.