From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff
Please ignore this...I forgot to CC xfs, sorry.
thanks,
liubo
On 07/19/2012 05:24 PM, Liu Bo wrote:
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321
Am Donnerstag, 19. Juli 2012 schrieb Marc MERLIN:
On Wed, Jul 18, 2012 at 11:49:36PM +0200, Martin Steigerwald wrote:
I am still not convinced that dm-crypt is the best way to go about
encryption especially for SSDs. But its more of a gut feeling than
anything that I can explain easily.
Hi!
Am Donnerstag, 19. Juli 2012 schrieb Bernhard Redl:
On 07/19/2012 03:42 AM, Shavi N wrote:
Hi,
I have btrfs volume, shared via samba. I have a directory of
documents that I want to backup on my server. win7 reports a
maximum of ~3.10MB/s transfer transferring the same directory on
Hi,
Thanks.
This is the output:
btrfs:
$ dd if=/dev/zero of=/mnt/shared/misc/temp_file bs=1M count=1400
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 1.56841 s, 936 MB/s
ext4:
$ dd if=/dev/zero of=/mnt/500/VirutalBox_VMs/thor/thor-data/temp_file
bs=1M count=1400
1400+0
On Thu, Jul 19, 2012 at 7:39 PM, Shavi N shav...@gmail.com wrote:
So btrfs gives a massive difference locally, but that still doesn't
explain the slow transfer speeds.
Is there a way to test this?
I'd try with real data, not /dev/zero. e.g:
dd_rescue -b 1M -m 1.4G /dev/sda testfile.img
... or
+static int process_link(const char *path, const char *lnk, void *user)
+{
+ int ret;
+ struct btrfs_receive *r = user;
+ char *full_path = path_cat(r-full_subvol_path, path);
+
+ if (g_verbose = 1)
+ fprintf(stderr, link %s - %s\n, path, lnk);
+
+ ret =
Am Donnerstag, 19. Juli 2012 schrieb Shavi N:
Hi,
Hi Shavi,
Thanks.
This is the output:
btrfs:
$ dd if=/dev/zero of=/mnt/shared/misc/temp_file bs=1M count=1400
1400+0 records in
1400+0 records out
1468006400 bytes (1.5 GB) copied, 1.56841 s, 936 MB/s
ext4:
$ dd if=/dev/zero
https://btrfs.wiki.kernel.org/index.php?title=Main_Page advertises Hot
data tracking and moving to faster devices but as far as I could find
(http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15884) the
patches have never been merged. What is known about the future of this
sort of
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba d...@jikos.cz wrote:
On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
I was testing the lz4(hc) patches, and I found the the compression
INCOMPAT flags are not being updated using the method in this patch.
The compression INCOMPAT
Hi!
On Mon, Jul 16, 2012 at 8:30 PM, Markus F.X.J. Oberhumer
mar...@oberhumer.com wrote:
I encourage all compression users to test and benchmark this new version,
and I also would ask some official LZO maintainer to convert the updated
source files into a GIT commit and possibly push it to
Hi,
Yes I read and understood your email. my btrfs volume consists of 11
HDD's. I was very surprised with that result myself...
On Fri, Jul 20, 2012 at 12:19 AM, Martin Steigerwald
mar...@lichtvoll.de wrote:
Am Donnerstag, 19. Juli 2012 schrieb Shavi N:
Hi,
Hi Shavi,
Thanks.
This is the
On Thu, Jul 19, 2012 at 06:27:07PM +0800, Liu Bo wrote:
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
I think it is better to create a new test than modify the old one.
That way it is
On 07/20/2012 08:24 AM, Dave Chinner wrote:
On Thu, Jul 19, 2012 at 06:27:07PM +0800, Liu Bo wrote:
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
I think it is better to create a new
On 07/20/2012 11:36 AM, David Sterba wrote:
On Thu, Jul 19, 2012 at 10:31:05AM +0800, Liu Bo wrote:
128 is too much, this would snip 128 * 8 = 1K off the stack.
That's why I give up 128. :)
It's good as a reference point, nobody says it should stay at 128.
But as Chris suggested, my test
While testing with my buffer read fio jobs[1], I find that btrfs does not
perform well enough.
Here is a scenario in fio jobs:
We have 4 threads, t1 t2 t3 t4, starting to buffer read a same file,
and all of them will race on add_to_page_cache_lru(), and if one thread
successfully puts its page
17 matches
Mail list logo
