All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Niccolò Belli" <darkbasic@linuxsystems.it>,
	"David Sterba" <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Any chance to get snapshot-aware defragmentation?
Date: Fri, 18 May 2018 13:10:02 -0400	[thread overview]
Message-ID: <de7adf73-ba0b-9154-e3d1-b4e468ad3c96@gmail.com> (raw)
In-Reply-To: <99d57070-a1df-45ef-8f7e-df832bd7ad92@linuxsystems.it>

On 2018-05-18 12:36, Niccolò Belli wrote:
> On venerdì 18 maggio 2018 18:20:51 CEST, David Sterba wrote:
>> Josef started working on that in 2014 and did not finish it. The patches
>> can be still found in his tree. The problem is in excessive memory
>> consumption when there are many snapshots that need to be tracked during
>> the defragmentation, so there are measures to avoid OOM. There's
>> infrastructure ready for use (shrinkers), there are maybe some problems
>> but fundamentally is should work.
>>
>> I'd like to get the snapshot-aware working again too, we'd need to find
>> a volunteer to resume the work on the patchset.
> 
> Yeah I know of Josef's work, but 4 years had passed since then without 
> any news on this front.
> 
> What I would really like to know is why nobody resumed his work: is it 
> because it's impossible to implement snapshot-aware degram without 
> excessive ram usage or is it simply because nobody is interested?
I think it's because nobody who is interested has both the time and the 
coding skills to tackle it.

Personally though, I think the biggest issue with what was done was not 
the memory consumption, but the fact that there was no switch to turn it 
on or off.  Making defrag unconditionally snapshot aware removes one of 
the easiest ways to forcibly unshare data without otherwise altering the 
files (which, as stupid as it sounds, is actually really useful for some 
storage setups), and also forces the people who have ridiculous numbers 
of snapshots to deal with the memory usage or never defrag.


  reply	other threads:[~2018-05-18 17:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 15:22 Any chance to get snapshot-aware defragmentation? Niccolò Belli
2018-05-18 16:20 ` David Sterba
2018-05-18 16:36   ` Niccolò Belli
2018-05-18 17:10     ` Austin S. Hemmelgarn [this message]
2018-05-18 17:18       ` Niccolò Belli
2018-05-18 18:33         ` Austin S. Hemmelgarn
2018-05-18 22:26           ` Chris Murphy
2018-05-18 22:46             ` Omar Sandoval
2018-05-19  8:54           ` Niccolò Belli
2018-05-21 13:15             ` Austin S. Hemmelgarn
2018-05-21 13:42               ` Timofey Titovets
2018-05-21 15:38                 ` Austin S. Hemmelgarn
2018-06-01  3:19                   ` Zygo Blaxell
2018-05-18 23:55       ` Tomasz Pala
2018-05-19  8:56         ` Niccolò Belli
     [not found]           ` <20180520105928.GA17117@polanet.pl>
2018-05-21 13:49             ` Niccolò Belli
2018-05-21 17:43       ` David Sterba
2018-05-21 19:22         ` Austin S. Hemmelgarn

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=de7adf73-ba0b-9154-e3d1-b4e468ad3c96@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=darkbasic@linuxsystems.it \
    --cc=dsterba@suse.cz \
    --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.