public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Newbugreport <newbugreport@protonmail.com>,
	Patrik Lundquist <patrik.lundquist@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Andrei Borzenkov <arvidjaar@gmail.com>
Subject: Re: Btrfs send bloat
Date: Mon, 20 May 2019 07:58:09 -0400	[thread overview]
Message-ID: <56ee6d38-d4a8-a62b-4e0d-7568030cdcad@gmail.com> (raw)
In-Reply-To: <ZBp4TxX3BVubLSjbbtXjztW20HT6YFrXCMMV6IX3xamgZbnpU4KJvO5vs0tcF5po8Ay4KdgGyffZ2DHitm4X4Hm0CFMPCjC2g_HHS9CR51M=@protonmail.com>

On 2019-05-20 07:15, Newbugreport wrote:
> Patrik, thank you. I've enabled the SAMBA module, which may help in the future. Does the GUI file manager (i.e. Nautilus) need special support?
It shouldn't (Windows' default file manager doesn't, and most stuff on 
Linux uses Samba so it shouldn't either, not sure about macOS though).

Keep in mind, however, that server-side copies only work in SMB within a 
single share.  If you're moving files between two independent shares, 
even if they're on the same server (or even the same filesystem on the 
same server) will always translate to a copy+delete because the client 
system has no other way to tell the server to move the file across shares.
> 
> Andrea, thank you for the link. bup is impressive but does it work well with btrfs snapshots? My live drive contains the main volume alongside many snapshots and the associated bloat from moved/deleted files. There's not room for another copy of everything, even if it's deduplicated. Perhaps I could switch one of the backup drives and the cloud to bup, but how well would bup work diffing all those snapshots when the backup drive is plugged in?
Deduplication will almost never increase the total amount of data, and 
it absolutely won't need a second copy of everything.  The initial pass 
will probably be very slow though, as the ioctl that gets used does a 
bytewise comparison of the ranges that get passed in to make sure they 
are actually identical before it merges them.  Once the data is mostly 
deduplicated, this shouldn't be an issue for most tools as they will see 
the existing deduplicated ranges and not try to re-merge them.
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, May 20, 2019 10:34 AM, Patrik Lundquist <patrik.lundquist@gmail.com> wrote:
> 
>> On Mon, 20 May 2019 at 02:36, Andrei Borzenkov arvidjaar@gmail.com wrote:
>>
>>> 19.05.2019 11:11, Newbugreport пишет:
>>>
>>>> I have 3-4 years worth of snapshots I use for backup purposes. I keep
>>>> R-O live snapshots, two local backups, and AWS Glacier Deep Freeze. I
>>>> use both send | receive and send > file. This works well but I get
>>>> massive deltas when files are moved around in a GUI via samba.
>>>
>>> Did you analyze whether it is client or server problem? If client does
>>> file copy (instead of move as you imply) may be the simplest solution
>>> would be to use different tool on client. If problem is on server side,
>>> it is something to discuss with SAMBA folks.
>>
>> Also try the Btrfs module in Samba.
>> https://wiki.samba.org/index.php/Server-Side_Copy#Btrfs_Enhanced_Server-Side_Copy_Offload
> 
> 


  reply	other threads:[~2019-05-20 11:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-19  8:11 Btrfs send bloat Newbugreport
2019-05-19 20:06 ` Andrei Borzenkov
2019-05-20  9:20   ` David Disseldorp
2019-05-20 10:34   ` Patrik Lundquist
2019-05-20 11:15     ` Newbugreport
2019-05-20 11:58       ` Austin S. Hemmelgarn [this message]
2019-05-20 12:14         ` Patrik Lundquist
2019-05-20 12:40           ` Btrfs remote reflink with Samba David Disseldorp
2019-05-20 20:33             ` Patrik Lundquist
2019-05-20 22:50               ` Chris Murphy

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=56ee6d38-d4a8-a62b-4e0d-7568030cdcad@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=arvidjaar@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=newbugreport@protonmail.com \
    --cc=patrik.lundquist@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox