public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: waxhead <waxhead@dirtcellar.net>
To: DanglingPointer <danglingpointerexception@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: btrfs-dedupe broken and unsupported but in official wiki
Date: Thu, 18 Jun 2020 22:59:10 +0200	[thread overview]
Message-ID: <878f01ec-eb07-e8ba-bd32-143997bce422@dirtcellar.net> (raw)
In-Reply-To: <16bc2efa-8e88-319f-e90e-cf8536460860@gmail.com>

I have pointed this out before , but I would like to use the opportunity 
again. I, as just a regular user of btrfs would feel more comfortable if 
the dedupe tool was part of btrfs such as for example btrfs filesystem 
dedupe -r /somewhere

Regular users that are somewhat technically able may not know that the 
dedupe fuctions are kernel api's that should not destroy anything even 
if the calling program went berserk.

While this may be obvious to btrfs developers, it is not to regular 
users that may be concerned that a particular tool may wreck havoc on 
their filesystem.

DanglingPointer wrote:
> btrfs-dedupe is currently broken and no longer actively supported.
> 
> It no longer builds with current rustc v1.44.0 with cargo
> 
> It is in the official btrfs Deduplication wiki:
> 
>      https://btrfs.wiki.kernel.org/index.php/Deduplication
> 
> There's no real active community and proper QA, reviewing and vetting.
> 
> A poster in the issues area of the projects Github location stated that 
> even if fixed, it may not function correctly due to BTRFS having evolved 
> since the tool was designed created.
> 
> There's just too many unknowns with this BTRFS specific dedupe tool.
> 
> People using your official wiki and trying to use that deduplication 
> program could inadvertently destroy their data through nativity or 
> accident.  Especially if they start trying to fix the code.
> 
> I recommend you remove it from your website or at least put large 
> warnings there that it is broken (which looks ugly, I would rather only 
> stuff that works were there since it isn't your project anyway but some 
> 3rd party).
> 

  parent reply	other threads:[~2020-06-18 20:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18  2:28 btrfs-dedupe broken and unsupported but in official wiki DanglingPointer
2020-06-18 10:31 ` David Sterba
2020-06-18 20:43 ` Zygo Blaxell
2020-06-18 22:05   ` DanglingPointer
2020-06-19  5:04     ` Zygo Blaxell
2020-06-19 13:11       ` David Sterba
2020-06-22 19:49         ` Goffredo Baroncelli
2020-06-22 22:45           ` Zygo Blaxell
2020-07-02  8:27             ` Lakshmipathi.G
2020-07-03  3:16               ` Zygo Blaxell
2020-07-06 10:46                 ` Lakshmipathi.G
2020-07-25  7:24                   ` Lakshmipathi.G
2020-06-18 20:59 ` waxhead [this message]
2020-06-19 13:19   ` David Sterba

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=878f01ec-eb07-e8ba-bd32-143997bce422@dirtcellar.net \
    --to=waxhead@dirtcellar.net \
    --cc=danglingpointerexception@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