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
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
>
> 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
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 actually allocating space
> >
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 actually allocating space
>> on the file system for the new file.
>
> Well, best to just use the origin
On Wed, Jul 29, 2009 at 12:10:14PM -0400, Chris Mason wrote:
> On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote:
> > Chris Mason wrote:
> > > On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> > >>
> > >> I can't replicate it now, all tests I am doing report that bloc
On Wed, Jul 29, 2009 at 03:14:49PM +0100, Pádraig Brady wrote:
> Chris Mason wrote:
> > On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> >>
> >> I can't replicate it now, all tests I am doing report that blocks used
> >> before and after the clone are the same. Probably yesterd
Chris Mason wrote:
> On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
>>
>> I can't replicate it now, all tests I am doing report that blocks used
>> before and after the clone are the same. Probably yesterday the
>> difference I noticed was in reality the original file flushed t
On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote:
> Hi Pádraig,
>
>
> Pádraig Brady writes:
>
> > How different exactly?
> > OK I tried this myself on F11 with inconclusive results.
>
> I can't replicate it now, all tests I am doing report that blocks used
> before and after t
Hi Pádraig,
Pádraig Brady writes:
> How different exactly?
> OK I tried this myself on F11 with inconclusive results.
I can't replicate it now, all tests I am doing report that blocks used
before and after the clone are the same. Probably yesterday the
difference I noticed was in reality the
Giuseppe Scrivano wrote:
> Jim Meyering writes:
>
>>> Another possible issue with this I can think of is
>>> depending on the modification pattern of the COW files,
>>> the modification processes could fragment the file or
>>> more seriously be given ENOSPC errors.
>> I hope btrfs takes care of t
21 matches
Mail list logo
