All of lore.kernel.org
 help / color / mirror / Atom feed
* btrfrs send ... | ... receive ... stores files sparsely?
@ 2016-04-15 22:04 Nicholas D Steeves
  2016-04-18 12:13 ` Austin S. Hemmelgarn
  0 siblings, 1 reply; 2+ messages in thread
From: Nicholas D Steeves @ 2016-04-15 22:04 UTC (permalink / raw)
  To: Btrfs BTRFS

Hi,

I happened to notice this when checking free space of my backup and
primary system.  I'll use an example of a file that won't have any
private or confidential information.  For du -hc
./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache; ls -alh
./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache; sha512sum
./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache

On the sending system:
11M     ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
11M     total
-rw-r--r-- 1 kdm nogroup 11M Apr  2 18:00
./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
0ba53df610f35ef5170fe33fda4304456f4df2e9944447fa06467f8f6cfc89adc7da1698a1882929df56ce6be0e0846380cccfa411b4c7857f10a5c23d7797cb
 ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache

On the receiving system:
64K     ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
64K     total
-rw-r--r-- 1 114 nogroup 11M Apr  2 18:00
./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
0ba53df610f35ef5170fe33fda4304456f4df2e9944447fa06467f8f6cfc89adc7da1698a1882929df56ce6be0e0846380cccfa411b4c7857f10a5c23d7797cb
 ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache

The only thing I can think of is that something in btrfs send ... |
... receive ... is converting to sparse storage.  Is this intentional?
 I suppose with a COW filesystem preallocating empty space to prevent
fragmentation doesn't work, because as soon as that
cache/database/whatever_file changes the filesystem COWs the changes
to a location that will almost certainly require a seek...  That said,
will the way btrfs-progs is doing it cause similar issues with
converting to sparse storage that I've observed with tar and rsync?

Best regards,
Nicholas

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: btrfrs send ... | ... receive ... stores files sparsely?
  2016-04-15 22:04 btrfrs send ... | ... receive ... stores files sparsely? Nicholas D Steeves
@ 2016-04-18 12:13 ` Austin S. Hemmelgarn
  0 siblings, 0 replies; 2+ messages in thread
From: Austin S. Hemmelgarn @ 2016-04-18 12:13 UTC (permalink / raw)
  To: Nicholas D Steeves, Btrfs BTRFS

On 2016-04-15 18:04, Nicholas D Steeves wrote:
> Hi,
>
> I happened to notice this when checking free space of my backup and
> primary system.  I'll use an example of a file that won't have any
> private or confidential information.  For du -hc
> ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache; ls -alh
> ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache; sha512sum
> ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
>
> On the sending system:
> 11M     ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
> 11M     total
> -rw-r--r-- 1 kdm nogroup 11M Apr  2 18:00
> ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
> 0ba53df610f35ef5170fe33fda4304456f4df2e9944447fa06467f8f6cfc89adc7da1698a1882929df56ce6be0e0846380cccfa411b4c7857f10a5c23d7797cb
>   ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
>
> On the receiving system:
> 64K     ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
> 64K     total
> -rw-r--r-- 1 114 nogroup 11M Apr  2 18:00
> ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
> 0ba53df610f35ef5170fe33fda4304456f4df2e9944447fa06467f8f6cfc89adc7da1698a1882929df56ce6be0e0846380cccfa411b4c7857f10a5c23d7797cb
>   ./var/tmp/kdecache-kdmtjNM8H/icon-cache.kcache
>
> The only thing I can think of is that something in btrfs send ... |
> ... receive ... is converting to sparse storage.  Is this intentional?
>   I suppose with a COW filesystem preallocating empty space to prevent
> fragmentation doesn't work, because as soon as that
> cache/database/whatever_file changes the filesystem COWs the changes
> to a location that will almost certainly require a seek...  That said,
> will the way btrfs-progs is doing it cause similar issues with
> converting to sparse storage that I've observed with tar and rsync?
That does appear to be the case, which is slightly surprising to me, as 
I would have expected it to replicate the extent layout also (or at 
least, replicate what parts of the file were allocated and which were 
unwritten extents).

As far as 'similar issues with converting to sparse storage', I'm not 
entirely sure what you might mean, so I can't really say if it will or 
won't cause issues.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-04-18 12:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-15 22:04 btrfrs send ... | ... receive ... stores files sparsely? Nicholas D Steeves
2016-04-18 12:13 ` Austin S. Hemmelgarn

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.