Russell Coker posted on Fri, 23 May 2014 13:54:46 +1000 as excerpted:
Is anyone doing research on how much free disk space is required on
BTRFS for good performance? If a rumor (whether correct or incorrect)
goes around that you need 20% free space on a BTRFS filesystem for
performance then
On Fri, 23 May 2014 05:05:30 +0100, Filipe David Borba Manana wrote:
So that the same check (btrfs cloner program presence) can be reused
by other tests.
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
common/rc | 7 +++
tests/btrfs/035 | 4 +---
2 files
On Fri, 23 May 2014 05:05:31 +0100, Filipe David Borba Manana wrote:
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
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
On Thu, May 22, 2014 at 01:17:50PM -0400, Chris Mason wrote:
On 05/22/2014 11:05 AM, Jeff Mahoney wrote:
- gpg control packet
On 5/22/14, 8:19 AM, Chris Mason wrote:
Can we safely reinit a kobject that has been put in use in sysfs?
Given all the things that can hold refs etc is this
Very often while debugging filesystems with many subvolumes and/or
snapshots, specially when they are large, I want to see only the
content of one of the trees. So this change just adds an option
to btrfs-debug-tree to allow to specify the id of the tree we're
interesting in dumping to stdout.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/23/14, 8:38 AM, David Sterba wrote:
On Thu, May 22, 2014 at 01:17:50PM -0400, Chris Mason wrote:
On 05/22/2014 11:05 AM, Jeff Mahoney wrote:
- gpg control packet On 5/22/14, 8:19 AM, Chris Mason wrote:
Can we safely reinit a kobject that has
On Fri, 16 May 2014 17:36:57 -0400
Austin S Hemmelgarn ahferro...@gmail.com wrote:
It's similar (writes to just one drive, while the other is idle) when
removing (many) snapshots.
Not sure if that's optimal behaviour.
I think, after having looked at some of the code, that I know
I had btrfs send/receive running.
Plugging the power in caused laptop-mode to remount my root partition.
That hung, and in turn all of btrfs hung too.
7668 root btrfs send home_ro.20140523 -
7669 root btrfs receive /mnt/btrfs_po sleep_on_page
12118 root mount /dev/mapper/cryptroot
On Fri, May 23, 2014 at 08:56:06AM -0400, Jeff Mahoney wrote:
Sigh. Yep. kobject_cleanup caches -name before the release function
and ignores the cleared value. It seems the free name if we alloced
it comment in there was leftover from the middle of a patch series
Kay applied in late 2007.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/23/14, 10:32 AM, David Sterba wrote:
On Fri, May 23, 2014 at 08:56:06AM -0400, Jeff Mahoney wrote:
Sigh. Yep. kobject_cleanup caches -name before the release
function and ignores the cleared value. It seems the free name
if we alloced it
On 21/5/2014 3:58 πμ, Chris Murphy wrote:
On May 20, 2014, at 4:56 PM, Konstantinos Skarlatos k.skarla...@gmail.com
wrote:
On 21/5/2014 1:37 πμ, Mark Fasheh wrote:
On Tue, May 20, 2014 at 01:07:50AM +0300, Konstantinos Skarlatos wrote:
Duperemove will be shipping as supported software in a
On May 23, 2014, at 9:48 AM, Konstantinos Skarlatos k.skarla...@gmail.com
wrote:
On 21/5/2014 3:58 πμ, Chris Murphy wrote:
On May 20, 2014, at 4:56 PM, Konstantinos Skarlatos k.skarla...@gmail.com
wrote:
On 21/5/2014 1:37 πμ, Mark Fasheh wrote:
On Tue, May 20, 2014 at 01:07:50AM +0300,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/23/14, 10:34 AM, Jeff Mahoney wrote:
On 5/23/14, 10:32 AM, David Sterba wrote:
On Fri, May 23, 2014 at 08:56:06AM -0400, Jeff Mahoney wrote:
Sigh. Yep. kobject_cleanup caches -name before the release
function and ignores the cleared value.
Due to either bugs in send (kernel) that generate a command against
a wrong path for example, or transient errors on the receiving side,
we stopped processing the send stream immediately and exited with
an error.
It's often desirable to continue processing the send stream even if an
error happens
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
We were limiting the sum of the xattr name and value lengths to PATH_MAX,
which is not correct, specially on filesystems created with btrfs-progs
v3.12 or higher, where the default leaf size is max(16384, PAGE_SIZE), or
systems with page sizes larger than 4096 bytes.
Xattrs have their own
We are currently allocating space_info objects in an array when we
allocate space_info. When a user does something like:
# btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
# btrfs balance start -mconvert=single -dconvert=single /mnt -f
# btrfs balance start -mconvert=raid1 -dconvert=raid1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/23/14, 3:04 PM, Jeff Mahoney wrote:
We are currently allocating space_info objects in an array when we
allocate space_info. When a user does something like:
# btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt # btrfs
balance start
We are currently allocating space_info objects in an array when we
allocate space_info. When a user does something like:
# btrfs balance start -mconvert=raid1 -dconvert=raid1 /mnt
# btrfs balance start -mconvert=single -dconvert=single /mnt -f
# btrfs balance start -mconvert=raid1 -dconvert=raid1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/23/14, 3:41 PM, Jeff Mahoney wrote:
On 5/23/14, 3:04 PM, Jeff Mahoney wrote:
We are currently allocating space_info objects in an array when
we allocate space_info. When a user does something like:
# btrfs balance start -mconvert=raid1
btrfs currently publishes device membership via sysfs based on the devices
present when the file system is mounted. That publishing is not updated
when devices are added or removed while mounted.
This patch handles those events.
Signed-off-by: Jeff Mahoney je...@suse.com
---
fs/btrfs/volumes.c
On 05/23/2014 10:17 AM, Marc MERLIN wrote:
I had btrfs send/receive running.
Plugging the power in caused laptop-mode to remount my root partition.
That hung, and in turn all of btrfs hung too.
7668 root btrfs send home_ro.20140523 -
7669 root btrfs receive /mnt/btrfs_po
On Fri, May 23, 2014 at 04:24:49PM -0400, Chris Mason wrote:
I was able to kill btrfs send and receive, but mencoder is very hung, and
sync does not finish either:
10654 merlin syncsync_inodes_sb
17191 merlin sync
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 # make a playground
mkdir scratch/example
btrfs subvol snap -r scratch
25 matches
Mail list logo
