On Thu, Jul 30, 2009 at 09:39:17AM +0200, Jim Meyering wrote:
Joel Becker wrote:
I've cooked up 'ln -r' for reflinks, which works for ln(1) but
not for cp(1).
Thanks. I haven't looked, but after reading about the reflink syscall
[http://lwn.net/Articles/332802/] had come to the same
Andi Kleen wrote:
Jim Meyering j...@meyering.net writes:
Thanks. I haven't looked, but after reading about the reflink syscall
[http://lwn.net/Articles/332802/] had come to the same conclusion:
this feature belongs with ln rather than with cp.
cp already has -l so it would make sense to
Jim Meyering wrote:
With classic cp, if I copy a 1GB non-sparse file and there's less
space than that available, cp fails with ENOSPC.
With this new feature, it succeeds even if there are
just a few blocks available.
Is it good or bad?
Also, consider (buggy!) code that then depends on
Hi Pádraig,
thanks for the comments.
Pádraig Brady p...@draigbrady.com writes:
# 300MB seems to be the minimum size for a btrfs with default
parameters.
Actually, it seems the minimum space required is 256MB. Using a 255MB
image I get: device btrfs.img is too small (must be at least 256 MB)
Hello everyone,
We've added two small incrementals for the btrfs async block group
caching. One fixes a race between the caching thread and transaction
commit. We haven't seen this one triggered in testing, but it still is
a valid fix.
The second patch makes sure the caching threads don't
On Thu, Jul 30, 2009 at 12:54:16PM +0200, Andi Kleen wrote:
With classic cp, if I copy a 1GB non-sparse file and there's less
space than that available, cp fails with ENOSPC.
With this new feature, it succeeds even if there are
just a few blocks available.
Also, consider (buggy!) code
