On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, 9 Aug 2013, Zach Brown wrote:
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
On Wed, Aug 14, 2013 at 10:40 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, 9 Aug 2013, Zach Brown wrote:
On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
Josef Bacik
I added a patch where we started taking the ordered operations mutex when we
waited on ordered extents. We need this because we splice the list and process
it, so if a flusher came in during this scenario it would think the list was
empty and we'd usually get an early ENOSPC. The problem with
make C=2 fs/btrfs/ CF=-D__CHECK_ENDIAN__
I tried to filter out the warnings for which patches have already
been sent to the mailing list, pending for inclusion in btrfs-next.
All these changes should be obviously safe.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
This patch is
hi all,
trying to reproduce [1], i've came across another btrfs bug:
[ 4031.725643] [ cut here ]
[ 4031.725647] kernel BUG at fs/btrfs/file.c:870!
[ 4031.725648] invalid opcode: [#1] PREEMPT SMP
[ 4031.725650] Modules linked in: ecryptfs sha256_generic encrypted_keys
On Wed, 2013-08-14 at 10:56 +0200, Geert Uytterhoeven wrote:
These bring in the 64-bit divisor from somewhere else, so they're less
trivial to fix.
Using div64_u64 or div64_s64 could fix it.
Maybe that could be added to do_div too.
--
To unsubscribe from this list: send the line unsubscribe
I added a patch where we started taking the ordered operations mutex when we
waited on ordered extents. We need this because we splice the list and process
it, so if a flusher came in during this scenario it would think the list was
empty and we'd usually get an early ENOSPC. The problem with
The plan is to have a bunch of unit tests that run when btrfs is loaded when you
build with the appropriate config option. My ultimate goal is to have a test
for every non-static function we have, but at first I'm going to focus on the
things that cause us the most problems. To start out with
On Wed, Aug 14, 2013 at 07:50:05PM +0200, tim wrote:
hi all,
trying to reproduce [1], i've came across another btrfs bug:
You hit the strangest things. I'm going to sit down and write a bunch of unit
tests for this function to verify it is working properly. Thanks,
Josef
--
To
trying to reproduce [1], i've came across another btrfs bug:
You hit the strangest things. I'm going to sit down and write a bunch of unit
tests for this function to verify it is working properly. Thanks,
glad to help. not sure if this is related, but i always have some
warnings about
On 08/12/2013 02:13 PM, Josef Bacik wrote:
This is a regression test for a problem we had where we'd assume we had created
a directory if it only had subvols inside of it. This was happening because
subvols would have lower inode numbers than our current send progress because
their inode
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V2-V3: remove comment and abstract out the subvolid logic as per Eric's
On 8/14/13 3:07 PM, Josef Bacik wrote:
We were allowing users to delete their default subvolume, which is
problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V2-V3: remove comment and
On 08/07/2013 11:15 AM, Josef Bacik wrote:
There was a problem with send trying to overwrite a file that wasn't actually
the same. This is a test to check this particular case where receive fails when
it should succeed properly. I tested this to verify it fails without my fix and
passes with
Cc: Josef Bacik jba...@fusionio.com
Cc: Chris Mason chris.ma...@fusionio.com
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
fs/btrfs/ctree.h | 2 --
fs/btrfs/disk-io.c | 8
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 1 -
fs/btrfs/root-tree.c | 4 ++--
On 07/31/2013 10:52 AM, Stefan Behrens wrote:
This test performs btrfs device replace tests with all possible profiles
(single/dup/mixed/raid0/raid1/raid10), one round with the '-r' option
to 'btrfs replace start' and one round without this option. The
cancelation is tested only once and with
On 07/24/2013 12:01 PM, Stefan Behrens wrote:
Since common/config is executed twice, if SCRATCH_DEV_POOL is configured
via the environment, the current code removes the first device entry twice
which means that you lose the second device for the test.
The fix is to not remove anything from
Hello,
I hope this is the correct mailing list.
I have btrfs running on a 6TB (5.5ish TiB) raid10 array on a 3ware
9750-4i controller. I decided to run a script and a got 5 checksum
errors for the same file (errors from dmesg below).
I deleted the file without any issues, reran scrub, and
Hi gang,
I was a little surprised to see that patch go by recently
which fixed an endian bug. I went to see how sparse
checking looked and it was.. broken. I got it going
again in my Fedora environment.
Most of the patches are just cleanups, but there *were*
three real bugs lurking in all
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-convert.c| 2 +-
btrfs.c| 6 +++---
cmds-dedup.c | 2 +-
crc32c.c | 4 ++--
ctree.c| 4 ++--
free-space-cache.c | 4 ++--
help.c | 2 +-
radix-tree.c | 2 +-
8 files changed, 13
This fixes all the instances of warnings that symbols declared in blocks
shadow symbols with the same name in surrounding scopes:
cmds-device.c:341:22: warning: symbol 'path' shadows an earlier one
cmds-device.c:285:14: originally declared here
I just renamed or removed the risky shadow
These were mostly in option structs but there were a few gross string
pointer arguments given as 0.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-map-logical.c | 2 +-
btrfs.c | 2 +-
cmds-balance.c | 6 +++---
cmds-check.c| 2 +-
cmds-dedup.c| 4 ++--
This silences a sparse warning:
warning: constant 0x4D5F53665248425F is so big it is long
from
commit 52162700bb59663add809a6465ce2769d80b3664
Author: Zach Brown z...@redhat.com
Date: Thu Jan 17 11:54:47 2013 -0800
btrfs-progs: treat super.magic as an le64
High fives,
The _una_ struct's entire job is to pass an argument to le*_to_cpu. So
it's a little embarassing that it uses a native cpu types and generates
endian warnings.
ctree.h:1616:1: warning: incorrect type in assignment (different base types)
ctree.h:1616:1:expected unsigned long long [unsigned]
sparse hates variable length array definitions on the stack:
btrfs-show-super.c:155:21: warning: Variable length array is used.
And it's right to. They're a fragile construct that doesn't handle bad
input well at all.
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-show-super.c | 2 +-
A disk_key was set by hand instead of using the endian helpers.
I *think* the second one is just a typo. The chunk's num_stripes was
already initialized from the record, but it's le16. So we'll set the
item's size based on the record's native num_stripes.
Signed-off-by: Zach Brown
__CHECKER__ is only for the type juggling used to tell sparse which
types need conversion between address spaces. It is not OK to use to
change the code that gets checked to avoid bugs elsewhere in the build
infrastructure. We want to check the code that builds when the checker
isn't enabled.
Extents rebuilt from backrefs can have their objectid mangled. The code
tried to build a disk_key by hand and got the swabbing backwards.
Signed-off-by: Zach Brown z...@redhat.com
---
cmds-check.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/cmds-check.c
qgroup.c:82:23: warning: memcpy with byte count of 0
qgroup.c:83:23: warning: memcpy with byte count of 0
The inheritance wasn't copying qgroups[] because a confused sizeof()
gave 0 byte memcpy()s. It's been like this for the year since it was
merged, so I guess this isn't a very important thing
This silences (reasonable) sparse warnings of the form:
warning: non-ANSI function declaration of ..
Signed-off-by: Zach Brown z...@redhat.com
---
btrfs-find-root.c | 2 +-
btrfs-list.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-find-root.c
There were a few problems that were breaking sparse checking:
- We were defining CHECK_ENDIAN late in the environment, after
linux/fs.h has been included which defines __force and __bitwise in
confusing ways that conflict with ours. Define it up with __CHECKER__
so that linux/fs.h and our
sparse can freak out when linux/fs.h is included because it redefines
approximately a gazillion symbols already found in sys/mount.h:
/usr/include/linux/fs.h:203:9: warning: preprocessor token MS_RDONLY redefined
/usr/include/sys/mount.h:37:9: this was the original definition
Happily, we don't
raid6.c is built without access to the prototypes of functions it
exports.
warning: symbol 'raid6_gen_syndrome' was not declared. Should it be static?
They could be changed and get out of sync of the exported prototypes
without errors. So we add disk-io.h, and its dependency ctree.h, so
Storing fixed-endian values in native cpu types defeats the purpose of
using sparse endian types to find endian conversion bugs.
Signed-off-by: Zach Brown z...@redhat.com
---
print-tree.c | 6 +++---
uuid-tree.c | 5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git
On Wed, Aug 14, 2013 at 8:28 PM, Josef Bacik jba...@fusionio.com wrote:
The plan is to have a bunch of unit tests that run when btrfs is loaded when
you
build with the appropriate config option. My ultimate goal is to have a test
for every non-static function we have, but at first I'm going
35 matches
Mail list logo
