Hi,
I'm going to receive a new small laptop with a 500 GB 5400 RPM mechanical
ole' rust HD, and I plan ton install BTRFS on it.
It will have a kernel 3.13 for now, until 3.14 gets released.
However I'm still concerned with chronic BTRFS dreadful performance and still
find that BRTFS degrades
Hi folks,
The xfstests repository at git://oss.sgi.com/xfs/cmds/xfstests has
just been updated. Patches often get missed, so please check if your
outstanding patches were in this update. If they have not been in
this update, please resubmit them to x...@oss.sgi.com so they can be
picked up in the
Hi Chris,
On Thu, Jan 30, 2014 at 04:23:56PM +0100, Gerhard Heift wrote:
This patch series first rewrites tree_search to copy found items directly to
userspace and then adds a new ioctl TREE_SEARCH_V2 with which we could store
them in a varying buffer. Now even items larger than 3992 bytes or
On Mon, Mar 31, 2014 at 06:03:25PM +0800, Gui Hecheng wrote:
Originally following cmds will work:
# btrfs fi resize -10A mnt
# btrfs fi resize -10Gaha mnt
Filter the arg by checking the return pointer of memparse.
This should probably also go to stable@
Signed-off-by: Gui
On 2014-04-04 04:02, Swâmi Petaramesh wrote:
Hi,
I'm going to receive a new small laptop with a 500 GB 5400 RPM mechanical
ole' rust HD, and I plan ton install BTRFS on it.
It will have a kernel 3.13 for now, until 3.14 gets released.
However I'm still concerned with chronic BTRFS
On Mon, Mar 31, 2014 at 10:13:56PM +0800, Anand Jain wrote:
From: Anand Jain anand.j...@oracle.com
This fix will ensure all SB copies on the disk is zeroed
when the disk is intentionally removed. This helps to
better manage disks in the user land.
Signed-off-by: Anand Jain
Le vendredi 4 avril 2014 08:33:10 Austin S Hemmelgarn a écrit :
However I'm still concerned with chronic BTRFS dreadful performance and
still find that BRTFS degrades much over time even with periodic defrag
and best practices etc.
I keep hearing this from people, but i personally don't
On Fri, Apr 4, 2014 at 10:03 AM, Dave Chinner da...@fromorbit.com wrote:
Hi folks,
The xfstests repository at git://oss.sgi.com/xfs/cmds/xfstests has
just been updated. Patches often get missed, so please check if your
outstanding patches were in this update. If they have not been in
this
On Wed, Apr 02, 2014 at 05:48:21PM +0800, Anand Jain wrote:
Device list add shouldn't update the list when FS is mounted,
unless the whole loop w.r.t to bringing back the missing disk
is completed. (That is making it to be part of the group profile
and the code for this isn't there yet).
As
On Fri, Apr 04, 2014 at 11:03:16AM +0800, Liu Bo wrote:
On Thu, Apr 03, 2014 at 06:18:40PM +0200, David Sterba wrote:
On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
Commit fae7f21cece9a4c181 (btrfs: Use WARN_ON()'s
On Wed, Apr 02, 2014 at 07:53:32PM +0800, Wang Shilong wrote:
This patch fix a regression caused by the following patch:
Btrfs: don't flush all delalloc inodes when we doesn't get s_umount lock
break while loop will make us call @spin_unlock() without
calling @spin_lock() before, fix it.
On 04/04/2014 09:59 AM, David Sterba wrote:
On Tue, Apr 01, 2014 at 11:53:19PM +0100, Filipe David Borba Manana wrote:
This implements the tmpfile callback of struct inode_operations, introduced
in the linux kernel 3.11 [1], and implemented already by some filesystems.
Nice!
Btw, would be
On Fri, Apr 4, 2014 at 3:12 PM, Chris Mason c...@fb.com wrote:
On 04/04/2014 09:59 AM, David Sterba wrote:
On Tue, Apr 01, 2014 at 11:53:19PM +0100, Filipe David Borba Manana wrote:
This implements the tmpfile callback of struct inode_operations,
introduced
in the linux kernel 3.11 [1],
This new send flag makes send calculate first the amount of new file data (in
bytes)
the send root has relatively to the parent root, or for the case of a
non-incremental
send, the total amount of file data we will send through the send stream. In
other words,
it computes the sum of the lengths
This is a followup to the kernel patch titled:
Btrfs: send, add calculate data size flag to allow for progress estimation
This makes the btrfs send and receive commands aware of the new send flag,
named BTRFS_SEND_C_TOTAL_DATA_SIZE, which tells us the amount of file data
that is new between
On Mon, Mar 31, 2014 at 5:35 PM, Marc MERLIN m...@merlins.org wrote:
On Sat, Mar 29, 2014 at 05:21:23PM -0700, Marc MERLIN wrote:
I had a look at
http://bj0z.wordpress.com/2011/04/27/determining-snapshot-size-in-btrfs/#comment-35
but it's quite old and does not work anymore since userland
Regenerating the asciidoc takes much longer now and makes quick build
tests long. There's separate clean-doc target for that and clean-all
that cleans docs and sources.
Signed-off-by: David Sterba dste...@suse.cz
---
This applies on top of the new asciidoc patches and makes frequent build tests
On 4/4/2014 6:20 μμ, Filipe David Borba Manana wrote:
This new send flag makes send calculate first the amount of new file data (in
bytes)
the send root has relatively to the parent root, or for the case of a
non-incremental
send, the total amount of file data we will send through the send
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/10/14, 12:03 PM, Chris Mason wrote:
On 02/07/2014 08:34 AM, David Sterba wrote:
Introduce a block group type bit for a global reserve and fill
the space info for SPACE_INFO ioctl. This should replace the
newly added ioctl
On Fri, Apr 04, 2014 at 10:02:27AM +0200, Swâmi Petaramesh wrote:
Hi,
I'm going to receive a new small laptop with a 500 GB 5400 RPM mechanical
ole' rust HD, and I plan ton install BTRFS on it.
It will have a kernel 3.13 for now, until 3.14 gets released.
However I'm still concerned
On 2014-04-04 08:48, Swâmi Petaramesh wrote:
Le vendredi 4 avril 2014 08:33:10 Austin S Hemmelgarn a écrit :
However I'm still concerned with chronic BTRFS dreadful performance and
still find that BRTFS degrades much over time even with periodic defrag
and best practices etc.
I keep hearing
On Fri, Apr 04, 2014 at 04:20:41PM +0100, Filipe David Borba Manana wrote:
@@ -4307,6 +4348,22 @@ out:
return num_read;
}
+static int send_total_data_size(struct send_ctx *sctx, u64 data_size)
+{
+ int ret;
+
+ ret = begin_cmd(sctx, BTRFS_SEND_C_TOTAL_DATA_SIZE);
+
On Fri, Apr 4, 2014 at 3:52 PM, Konstantinos Skarlatos
k.skarla...@gmail.com wrote:
On 4/4/2014 6:20 μμ, Filipe David Borba Manana wrote:
This new send flag makes send calculate first the amount of new file data
(in bytes)
the send root has relatively to the parent root, or for the case of a
On Fri, Apr 4, 2014 at 4:53 PM, David Sterba dste...@suse.cz wrote:
On Fri, Apr 04, 2014 at 04:20:41PM +0100, Filipe David Borba Manana wrote:
@@ -4307,6 +4348,22 @@ out:
return num_read;
}
+static int send_total_data_size(struct send_ctx *sctx, u64 data_size)
+{
+ int ret;
+
On 04/03/2014 05:41 PM, Avi Miller wrote:
UUID should work fine on OL6. Can you confirm that you have the UEK3 (3.8.18)
kernel running? If you’ve installed from OL6U5 media, it should be enabled by
default, but older OL6 ISOs only had UEK2 on the media and the UEK3 yum channel
would need to
On Fri, Apr 04, 2014 at 05:01:41PM +0100, Filipe David Manana wrote:
* Send a clone command to user space.
*/
--- a/fs/btrfs/send.h
+++ b/fs/btrfs/send.h
@@ -87,6 +87,7 @@ enum btrfs_send_cmd {
BTRFS_SEND_C_END,
BTRFS_SEND_C_UPDATE_EXTENT,
+
I read recently that you can't send/receive concurrent streams on the
same filesystem, which begs the question of what is meant by a
filesystem. Is that to say that you can't send/receive snapshots on
different subvolumes to the same root filesystem? Or that you can't
send/receive multiple
On Fri, Apr 04, 2014 at 09:50:05AM -0700, Lists wrote:
I read recently that you can't send/receive concurrent streams on the same
filesystem, which begs the question of what is meant by a filesystem. Is
that to say that you can't send/receive snapshots on different subvolumes to
the same root
On Wed, Apr 02, 2014 at 04:29:35PM +0800, Qu Wenruo wrote:
Convert man page for btrfs-zero-log
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Documentation/Makefile | 2 +-
Documentation/btrfs-zero-log.txt | 39 +++
2 files changed, 40
Austin S Hemmelgarn posted on Fri, 04 Apr 2014 08:33:10 -0400 as
excerpted:
On 2014-04-04 04:02, Swâmi Petaramesh wrote:
Hi,
I'm going to receive a new small laptop with a 500 GB 5400 RPM
mechanical ole' rust HD, and I plan ton install BTRFS on it.
Reminds me of my query to the list, some
On Wed, Apr 02, 2014 at 04:29:25PM +0800, Qu Wenruo wrote:
+If the source device is not available anymore, or if the -r option is set,
+the data is built only using the RAID redundancy mechanisms.
+After completion of the operation, the source device is removed from the
+filesystem.
Woudl it
On 03/26/2014 01:01 PM, Jeff Mahoney wrote:
On 3/17/14, 9:05 AM, David Sterba wrote:
On Fri, Mar 14, 2014 at 08:12:16PM -0400, Sasha Levin wrote:
While fuzzing with trinity inside a KVM tools guest running the latest
-next kernel I've stumbled on the following:
[ 788.458756]CPU0
Hi,
On 5 Apr 2014, at 3:26 am, Lists li...@benjamindsmith.com wrote:
On 04/03/2014 05:41 PM, Avi Miller wrote:
UUID should work fine on OL6. Can you confirm that you have the UEK3
(3.8.18) kernel running? If you’ve installed from OL6U5 media, it should be
enabled by default, but older OL6
Le vendredi 4 avril 2014 16:09:06 Hugo Mills a écrit :
We don't have lots of reports of massive slowdowns
after a long period of use, so whatever you're doing, there seems to
be something unusual involved.
It's almost certainly not your fault, but there would appear to be
something in
34 matches
Mail list logo