[PATCH 2/2 v3] xfstests: add test for btrfs ioctl clone operation

This is a test to verify that the btrfs ioctl clone operation is able to clone extents of a file to different positions of the file, that is, the source and target files are the same. Existing tests only cover the case where the source and target files are different. Signed-off-by: Filipe David

is it safe to change BTRFS_STRIPE_LEN?

Hi. I'm playing around with (software) raid0 on SSDs and since I remember I read somewhere that intel recommends 128K stripe size for HDD arrays but only 16K stripe size for SSD arrays, I wanted to see how a small(er) stripe size would work on my system. Obviously with btrfs on top of md-raid I

Re: is it safe to change BTRFS_STRIPE_LEN?

On 05/24/2014 12:44 PM, john terragon wrote: Hi. I'm playing around with (software) raid0 on SSDs and since I remember I read somewhere that intel recommends 128K stripe size for HDD arrays but only 16K stripe size for SSD arrays, I wanted to see how a small(er) stripe size would work on my

Re: is it safe to change BTRFS_STRIPE_LEN?

Yes the btrfs-tools would have to be recompiled too ( BTRFS_STRIPE_LEN is defined in a volumes.h in there too). And yes, kernel and tools would certainly kill any raid0 btrfs fs and maybe any other multidevice kind of setting. On Sat, May 24, 2014 at 9:07 PM, Austin S Hemmelgarn

[PATCH v2] xfstests: add test for btrfs send with large xattrs

Verify that btrfs send is able to replicate xattrs larger than PATH_MAX. This is possible if the b+tree leaf size is larger than 4Kb (mkfs.btrfs's default is max(16Kb, PAGE_SIZE) as of btrfs-progs v3.12, and max(4Kb, PAGE_SIZE in older versions). This issue is fixed by the following linux kernel

[PATCH] Btrfs: send, don't error in the presence of subvols/snapshots

If we are doing an incremental send and the base snapshot has a directory with name X that doesn't exist anymore in the second snapshot and a new subvolume/snapshot exists in the second snapshot that has the same name as the directory (name X), the incremental send would fail with -ENOENT error.

[PATCH] Btrfs: set dead flag on the right root when destroying snapshot

We were setting the BTRFS_ROOT_SUBVOL_DEAD flag on the root of the parent of our target snapshot, instead of setting it in the target snapshot's root. This is easy to observe by running the following scenario: mkfs.btrfs -f /dev/sdd mount /dev/sdd /mnt btrfs subvolume create

[PATCH v2] Btrfs: set dead flag on the right root when destroying snapshot

We were setting the BTRFS_ROOT_SUBVOL_DEAD flag on the root of the parent of our target snapshot, instead of setting it in the target snapshot's root. This is easy to observe by running the following scenario: mkfs.btrfs -f /dev/sdd mount /dev/sdd /mnt btrfs subvolume create

[PATCH] xfstests: test for btrfs send when nested subvols/snapshots exist

Regression test for a btrfs incremental send issue where the difference between the snapshots used by the incremental send consists of one of these cases: 1) First snapshot has a directory with name X and in the second snapshot that directory doesn't exist anymore but a subvolume/snapshot with

Re: BUG: Replacing a directory with a subvolume breaks incremental snapshots

On Sat, May 24, 2014 at 3:24 AM, Robert White rwh...@pobox.com wrote: Howdy, If you remove an existing directory and then create a subvolume with the same name the incremental send (btrfs send -p) will die with errno==2 (file not found). Steps to Reproduce: btrfs subvol create scratch #

[PATCH v2] Btrfs: send, don't error in the presence of subvols/snapshots

If we are doing an incremental send and the base snapshot has a directory with name X that doesn't exist anymore in the second snapshot and a new subvolume/snapshot exists in the second snapshot that has the same name as the directory (name X), the incremental send would fail with -ENOENT error.