similar to: Re: cp --reflink with Btrfs

I am testing a Btrfs root file system with Debian (kernel 2.6.32) under KVM. jason@vrtl:~$ touch testfile jason@vrtl:~$ cp --reflink testfile /tmp cp: failed to clone `/tmp/testfile'': Invalid argument This is with GNU Coreutils 8.0 taken from debian Sid. Is this a Coreutils issue, a Btrfs problem or something in my local configuration? All the other issues that I have encountered so

We need to truncate page cache pages for the clone ioctl target range or else we''ll confuse ourselves to no end. If the old data was cached, we''ll still see it (until remount). If it was dirty we''ll get a mix of old and new data if the page(s) are partially updated. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 4 ++++ 1 files changed,

The CLONE and CLONE_RANGE ioctls round up the range of extents being cloned to the block size when the range to clone extends to the end of file (this is always the case with CLONE). It was then using that offset when extending the destination file''s i_size. Fix this by not setting i_size beyond the originally requested ending offset. This bug was introduced by a22285a6 (2.6.35-rc1).

This check for a user transaction is a bogus: fsync() with an open user transaction is verboten. If the caller is the same process who started a user transaction, and this is a different file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to

It''s been nearly a year since the patches needed to implement a reflinked copy between subvolumes have been posted (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865 ) and I still get "Invalid cross-device link" error with Linux 3.2.4 while I try to do a cp --reflink between subvolumes. This is a *very* useful feature to have (think offline file-level

Hi all, This is an alternative approach to atomic user transactions for btrfs. The old start/end ioctls suffer from some basic limitations, namely - We can''t properly reserve space ahead of time to avoid ENOSPC part way through the transaction, and - The process may die (seg fault, SIGKILL) part way through the transaction. Currently when that happens the partial transaction will

It''s safe and easy to do so, provided the ranges don''t overlap. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> --- fs/btrfs/ioctl.c | 23 ++++++++++++++++------- 1 files changed, 16 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 0b06a5c..8fcd671 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2223,8 +2223,6 @@ static

2011/10/26 Sage Weil <sage@newdream.net>: > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would be >> >> > something like ''journal dio = false''.  If not, can you verify that >> >> > directio shows true when the journal is initialized from your osd log?

Hi Chris- Here''s a simpler version of the patch that drops the unrelated sync_fs stuff. thanks- sage The ''flushoncommit'' mount option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes the committed state a fully consistent view of the file system from the application''s perspective (i.e., it

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

Hi everyone, This patchset is the latest approach I''m using for the Ceph storage daemon to keep track of which data has safely committed to disk. The basic idea is to not use the (problematic) user transaction ioctls at all. Instead, the daemon quiesces its own write requests, initiates an async snapshot, and then continues. The snapshot approach is nice because it provides rollback.

https://bugzilla.samba.org/show_bug.cgi?id=10170 Summary: rsync should support reflink similar to cp --reflink Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: samba at shubin.ca

Hello, This is the second attempt to bring in cross subvolume reflinks into btrfs. The first attempt was NAKed due to missing vfs mount checks and a clear description of what btrfs subvolumes are and probably also why cross subvolume reflinks are ok in the case of btrfs. This version of the patch comes from David and is in SUSE kernels since a long time, so it is tested and working. The patch

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

Add a mount option user_subvol_rm_allowed that allows users to delete a (potentially non-empty!) subvol when they would otherwise we allowed to do an rmdir(2). We duplicate the may_delete() checks from the core VFS code to implement identical security checks (minus the directory size check). Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ctree.h | 1 + fs/btrfs/ioctl.c |

We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether num_writers > 1 or should_grow at the top of the loop. Then, much much later, we wait for that timeout if either num_writers or should_grow is true. However, it''s possible for a racing process (calling btrfs_end_transaction()) to decrement num_writers such that we wait forever instead of for 1. Fix this by

Add missing mnt_drop_write to match the mnt_want_write in btrfs_ioctl_trans_start. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 6228b69..69c4a07 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1059,6 +1059,8 @@ long btrfs_ioctl_trans_end(struct

Hi, The following series of patches implements in btrfs an ioctl to do out-of-band deduplication of file extents. To be clear, this means that the file system is mounted and running, but the dedupe is not done during file writes, but after the fact when some userspace software initiates a dedupe. The primary patch is loosely based off of one sent by Josef Bacik back in January, 2011.

Hi all, Just a quick question but can''t find an obvious answer. Can I create/convert a existing (btrfs) directory into a subvolume? It would be very helpful when transferring ''partitions'' into btrfs. I found a similar question way back in google, but that site is down now generally. Thanks in advance. -- To unsubscribe from this list: send the line

Glück Auf! I know its been discussed more then ones, but as a user I really would like to see the patch for allowing this in the kernel. Some users tested this patch successfully for weeks or months in 2 or 3 kernel versions since then, true? I''d say by creating a snapshot, it''s nothing else in the end. More then one file or tree sharing the same data on disc, or am I wrong?