Re: btrfs receive bigger than original snapshot?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Sep 23, 2015 at 09:41:21AM +0100, Filipe David Manana wrote:
> On Tue, Sep 22, 2015 at 9:04 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote:
> > On Tue, Sep 22, 2015 at 09:52:19PM +0200, carlo von lynX wrote:
> >> Hello, it's me again. This time I searched the web to make sure
> >> I'm not making another beginner's mistake. I'm still not on the
> >> list, so please keep me in cc: on replies.
> >>
> >> I have optimized a btrfs subvolume with a script* that reflinks
> >> all files with identical contents, then I did a read-only snap
> >> and fed it to send/receive. The bad news: on the receiving
> >> side the same snapshot grew from 5.5G to 7.1G.
> 
> So that's likely because you have files with holes. Right now when a
> hole exists in a file the send stream will contain an instruction to
> write zeroes into the file instead of a punch hole instruction. So
> imagine a file with a 1Gb hole, the send stream makes the receiver
> write 1Gb of zeroes, wasting a lot of space (and time).
> 
> There's an over an year old patchset to add hole punching support to
> the send stream and a few other features, but it was never picked by
> Josef at the time (when he was maintaining the integration branch) nor
> Chris.
> 

Can you please point to the latest version of the hole punching patchset? 


Thanks,

-- Pasi

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux