In logical resolve, we parse extent_from_logical()'s 'ret' as a kind of flag.
It is possible to lose our errors because
(-E BTRFS_EXTENT_FLAG_TREE_BLOCK) is true.
I'm not sure if it is on purpose, it just looks too hacky if it is.
I'd rather use a real flag and a 'ret' to catch errors.
We already have a helper, iterate_inodes_from_logical(), for logical resolve,
so just use it.
Signed-off-by: Liu Bo bo.li@oracle.com
---
v1-v2: patch -EINVAL to -ENOENT to keep the behaviour, thanks to Jan.
fs/btrfs/ioctl.c | 19 +++
1 files changed, 3 insertions(+), 16
On 2012-08-15 16:45, Johannes Stezenbach wrote:
On Wed, Aug 15, 2012 at 02:02:43PM +0200, Markus F.X.J. Oberhumer wrote:
On 2012-08-14 14:39, Johannes Stezenbach wrote:
On Tue, Aug 14, 2012 at 01:44:02AM +0200, Markus F.X.J. Oberhumer wrote:
On 2012-07-16 20:30, Markus F.X.J. Oberhumer wrote:
To close this thread.
I gave up on the drive after it showed abysmal benchmarking results in
windows too.
I owed everyone an update, which I just finished typing:
For malloc may fail, we should check it before assign
values to the fields of struct btrfs_trans_handle *h.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
transaction.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/transaction.h b/transaction.h
index
On 16.08.2012 09:57, Wang Sheng-Hui wrote:
For malloc may fail, we should check it before assign
values to the fields of struct btrfs_trans_handle *h.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
transaction.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff
On 08/16/12 16:03, Arne Jansen wrote:
On 16.08.2012 09:57, Wang Sheng-Hui wrote:
For malloc may fail, we should check it before assign
values to the fields of struct btrfs_trans_handle *h.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
transaction.h |5 +
1 files changed, 5
On 2012年08月16日 16:55, Jie Liu wrote:
On 08/16/12 16:03, Arne Jansen wrote:
On 16.08.2012 09:57, Wang Sheng-Hui wrote:
For malloc may fail, we should check it before assign
values to the fields of struct btrfs_trans_handle *h.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
Add code indent to the bad styled statements.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
root-tree.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/root-tree.c b/root-tree.c
index 782472c..39cfef6 100644
--- a/root-tree.c
+++ b/root-tree.c
@@ -182,12
On 16.08.2012 15:17, Wang Sheng-Hui wrote:
Add code indent to the bad styled statements.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
root-tree.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/root-tree.c b/root-tree.c
index 782472c..39cfef6
On 2012年08月16日 21:23, Arne Jansen wrote:
On 16.08.2012 15:17, Wang Sheng-Hui wrote:
Add code indent to the bad styled statements.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
root-tree.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/root-tree.c
On 16.08.2012 15:26, Wang Sheng-Hui wrote:
On 2012年08月16日 21:23, Arne Jansen wrote:
On 16.08.2012 15:17, Wang Sheng-Hui wrote:
Add code indent to the bad styled statements.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
root-tree.c | 10 --
1 files changed, 4 insertions(+),
On 2012年08月16日 21:30, Arne Jansen wrote:
On 16.08.2012 15:26, Wang Sheng-Hui wrote:
On 2012年08月16日 21:23, Arne Jansen wrote:
On 16.08.2012 15:17, Wang Sheng-Hui wrote:
Add code indent to the bad styled statements.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
root-tree.c | 10
It should be storing.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/ctree.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 4bab807..f9289db 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -116,7 +116,7 @@
It should be storing.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
ctree.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ctree.h b/ctree.h
index d218b88..8f3cd7e 100644
--- a/ctree.h
+++ b/ctree.h
@@ -86,7 +86,7 @@ struct btrfs_trans_handle;
#define
On Thu, Aug 16, 2012 at 08:27:15AM +0200, Markus F.X.J. Oberhumer wrote:
On 2012-08-15 16:45, Johannes Stezenbach wrote:
I made the attached quick hack userspace code
using ARM kernel headers and barebox unlzop code.
(new == your new code, old == linux-3.5 git, test == new + your
On 08/16/2012 10:53 PM, Wang Sheng-Hui wrote:
It should be storing.
Please cc these typo fixes to triv...@kernel.org.
thanks,
liubo
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/ctree.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 08/16/2012 02:27 AM, Markus F.X.J. Oberhumer wrote:
On 2012-08-15 16:45, Johannes Stezenbach wrote:
On Wed, Aug 15, 2012 at 02:02:43PM +0200, Markus F.X.J. Oberhumer wrote:
On 2012-08-14 14:39, Johannes Stezenbach wrote:
On Tue, Aug 14, 2012 at 01:44:02AM +0200, Markus F.X.J. Oberhumer
If you think a little bit, I bet you could come up with a solution that
operates at cacheline-aligned granularity, something that would be _even
faster_ than simply fixing the code to do aligned accesses.
Cache aligned compression is unlikely to compress anything at all.
Compression
On 08/16/2012 12:20 PM, Andi Kleen wrote:
If you think a little bit, I bet you could come up with a solution that
operates at cacheline-aligned granularity, something that would be _even
faster_ than simply fixing the code to do aligned accesses.
Cache aligned compression is unlikely to
On Thu, Aug 16, 2012 at 12:48:49PM -0400, Jeff Garzik wrote:
On 08/16/2012 12:20 PM, Andi Kleen wrote:
If you think a little bit, I bet you could come up with a solution that
operates at cacheline-aligned granularity, something that would be _even
faster_ than simply fixing the code to do
On Thu, 16 Aug 2012 17:06:47 +0200
Johannes Stezenbach j...@sig21.net wrote:
Well, ~2x speedup on x86 is certainly a good achievement, but there
are more ARM based devices than there are PCs, and I guess many
embedded devices use lzo compressed kernels and file systems
while I'm not convinced
I have locked the Allwinner A10 CPU in my Mele A2000 to 60 MHz using
cpufreq-set,
and ran your test. rnd.lzo is a 9 MB file from /dev/urandom compressed with
lzo.
There doesn't seem to be a significant difference between all three variants.
I found that in compression benchmarks it depends
On Thu, Aug 16, 2012 at 7:52 PM, Andi Kleen a...@firstfloor.org wrote:
I have locked the Allwinner A10 CPU in my Mele A2000 to 60 MHz using
cpufreq-set,
and ran your test. rnd.lzo is a 9 MB file from /dev/urandom compressed with
lzo.
There doesn't seem to be a significant difference between
While working on my fsync patch my fsync tester kept hitting mismatching
md5sums when I would randomly write to a prealloc'ed region, syncfs() and
then write to the prealloced region some more and then fsync() and then
immediately reboot. This is because the tree logging code will skip writing
On 2012年08月16日 23:18, Liu Bo wrote:
On 08/16/2012 10:53 PM, Wang Sheng-Hui wrote:
It should be storing.
Please cc these typo fixes to triv...@kernel.org.
thanks,
liubo
OK.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/ctree.h |2 +-
1 files changed, 1
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen a...@firstfloor.org wrote:
On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
looks like ARM results are inconclusive from a lot of folks without
bandwidth to do a write-up, what about just plain STAGING status for ARM so
the android
On 08/15/2012 06:12 PM, Lluís Batlle i Rossell wrote:
Hello,
some time ago we discussed on #btrfs that the nocow attribute for files wasn't
working (around 3.3 or 3.4 kernels). That was evident by files fragmenting
even
with the attribute set.
Chris mentioned to find a fix quickly for
dunno if this thread is dead, but im inclined to patch in cp --reflink
to fdupes prog. It currently does provide a poor-man's dedupe via
md5sum and hardlink, or delete.
all the better if the distro-kernels can backport cross-snapshot
reflinks sooner than later.
On Sun, Apr 29, 2012 at 1:05 PM,
On Thu, Aug 16, 2012 at 09:20:00PM -0700, james northrup wrote:
dunno if this thread is dead, but im inclined to patch in cp --reflink
to fdupes prog. It currently does provide a poor-man's dedupe via
md5sum and hardlink, or delete.
all the better if the distro-kernels can backport
30 matches
Mail list logo
