Joel Becker wrote:
> In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees
> enabled, or any other CoW-ish filesystem is a tacit approval of the
> delayed ENOSPC. The same can be said of "thin provisioning" LUNs.
> However, the other concerns are still valid. A user invoking vanill
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 (b
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 stall
Hi Pádraig,
thanks for the comments.
Pádraig Brady 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)"
> # FIXME: us
Ric Wheeler wrote:
> I think that doing reflink by default would be a horrible idea - one
> good reason to copy a file is to increase your level of fault
> tolerance and reflink magically avoids that :-)
Good point.
This would constitute another user-visible semantic change in cp:
a disk fault tha
On 07/30/2009 04:40 AM, Pádraig Brady wrote:
Jim Meyering wrote:
Joel Becker wrote:
On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote:
At the moment we have these linking options:
cp -l, --link #for hardlinks
cp -s, --symbolic-link #for symlinks
So perhaps we s
The extent allocation tree is recursive, it may change after
update_cowonly_root is called. So we shouldn't update extent
tree's commit_root directly in update_cowonly_root.
Signed-off-by: Yan Zheng
---
diff -urp 1/fs/btrfs/ctree.h 2/fs/btrfs/ctree.h
--- 1/fs/btrfs/ctree.h 2009-07-29 10:03:04
>
> 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 that then depends on being able to modify
> that file in-
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 being
Andi Kleen wrote:
> Jim Meyering 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 extend t
Andi Kleen wrote:
> Jim Meyering 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 extend that
Jim Meyering 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 extend that too.
> Besides, putting
Jim Meyering wrote:
> Joel Becker wrote:
>
>> On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote:
>>>
>>> At the moment we have these linking options:
>>>
>>> cp -l, --link #for hardlinks
>>> cp -s, --symbolic-link #for symlinks
>>>
>>> So perhaps we should support:
>>>
>>> cp --link={s
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 th
Joel Becker wrote:
> On Wed, Jul 29, 2009 at 07:14:37PM +0100, Pádraig Brady wrote:
>> Chris Mason wrote:
>> > On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote:
>> >>
>> >> We may need to play around with fallocate()
>> >> if we want to get back to the original
>> >> cp semantics of a
15 matches
Mail list logo
