bug-coreutils
[Top][All Lists]
Advanced

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

Re: BTRFS file clone support for cp


From: Joel Becker
Subject: Re: BTRFS file clone support for cp
Date: Wed, 29 Jul 2009 17:57:03 -0700
User-agent: Mutt/1.5.20 (2009-06-14)

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
> >> on the file system for the new file.
> >
> > Well, best to just use the original cp code.  I was talking with
> > Giuseppe about this as well, I think we should the option to do regular
> > cp via a flag.
> 
> Right. Well we can turn off this cloning by doing --sparse={never,always}
> but that has side effects. If we need an option then maybe we should have
> it turn on cloning rather than restore default cp behaviour?
> The side effects I thought of earlier, of COW without corresponding allocation
> were possible fragmentation on write or unexpected/mishandled ENOSPC.
> Also for endangered mechanical disks, subsequent processing could
> be slowed as the head seeks between the old and new data to be copied.
> Perhaps these are a small price to pay, especially considering that
> solid state disks will only be affected by the write()=ENOSPC issue.
> 
> 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={soft,hard,cow}
> for symlink(), link() and reflink() respectively?
> I.E. link to the name, inode or extents respectively.

        I've cooked up 'ln -r' for reflinks, which works for ln(1) but
not for cp(1).  I have a git tree with the (in-flux) code on
oss.oracle.com:

[View]
http://oss.oracle.com/git/?p=jlbec/reflink.git;a=summary
[Pull]
git://oss.oracle.com/git/jlbec/reflink.git master

        This repository isn't designed to be an authorative patch for
coreutils.  Instead it provides a reflink(1) program that is actually ln
-r in disguise.  Later work would be to get coreutils updated
"properly".

Joel

-- 

"This is the end, beautiful friend.
 This is the end, my only friend the end
 Of our elaborate plans, the end
 Of everything that stands, the end
 No safety or surprise, the end
 I'll never look into your eyes again."

Joel Becker
Principal Software Developer
Oracle
E-mail: address@hidden
Phone: (650) 506-8127




reply via email to

[Prev in Thread] Current Thread [Next in Thread]