From: Zhou Bo
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff --git a/254 b/254
index 7b74a02..9c320d0 100755
--- a/
From: Zhou Bo
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff --git a/254 b/254
index 7b74a02..9c320d0 100755
--- a/
Please ignore this...I forgot to CC xfs, sorry.
thanks,
liubo
On 07/19/2012 05:24 PM, Liu Bo wrote:
> From: Zhou Bo
>
> This patch adds more cases in 254 for testing btrfs snapshot.
>
> Signed-off-by: Zhou Bo
> ---
> 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 easil
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 di
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 r
On Thu, Jul 19, 2012 at 7:39 PM, Shavi N 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 use whatever n
+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);
+
+ r
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/ze
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 perf
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba 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 flags ar
Hi!
On Mon, Jul 16, 2012 at 8:30 PM, Markus F.X.J. Oberhumer
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 Linus or linux-next.
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
wrote:
> Am Donnerstag, 19. Juli 2012 schrieb Shavi N:
>> Hi,
>
> Hi Shavi,
>
>> Thanks.
>>
>> This is the output:
On Thu, Jul 19, 2012 at 06:27:07PM +0800, Liu Bo wrote:
> From: Zhou Bo
>
> This patch adds more cases in 254 for testing btrfs snapshot.
>
> Signed-off-by: Zhou Bo
I think it is better to create a new test than modify the old one.
That way it is easy to tell the difference between a new failu
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
>>
>> This patch adds more cases in 254 for testing btrfs snapshot.
>>
>> Signed-off-by: Zhou Bo
>
> I think it is better to create a new test than modify the old one.
> That w
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 is really a race case in practical use
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 sugges
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
18 matches
Mail list logo
