Thanks Stefan.
::
About the issue you mentioned, that you need to change the kernel and
the user mode at the same time:
You can keep it compatible. Just do not delete the old kernel interface.
The user mode program could try the new interface first, and if it
fails, fall back to the old
Hello
On my HP Compaq dc5800 with Ubuntu 13.04 and their 3.8.0-19-lowlatency
kernel, I've got quite some kernel traces in the syslog. You can find
them below or at http://pastebin.com/bLXPBX67 (to avoid line breaks…).
These kernel traces all begin with:
WARNING: at
On Fri, Apr 26, 2013 at 03:13:59PM -0400, Josef Bacik wrote:
This test sets up a dm flakey target and then runs my fsync tester I've been
using to verify btrfs's fsync() is working properly. It will create a dm
flakey
device, mount it, run my test, make the flakey device start dropping
Hallo, Alexander,
Du meintest am 30.04.13:
On my HP Compaq dc5800 with Ubuntu 13.04 and their
3.8.0-19-lowlatency kernel, I've got quite some kernel traces in the
syslog.
It's a very good idea to use the newest kernel for btrfs. 3.8.0 is
really old.
Just try kernel 3.8.10.
Viele Gruesse!
On Tue, Apr 30, 2013 at 08:55:00AM +0200, Helmut Hullen wrote:
Hallo, Alexander,
Du meintest am 30.04.13:
On my HP Compaq dc5800 with Ubuntu 13.04 and their
3.8.0-19-lowlatency kernel, I've got quite some kernel traces in the
syslog.
It's a very good idea to use the newest kernel
Hugo Mills hugo at carfax.org.uk writes:
The differences in btrfs between the two are very small, and even
I(*) wouldn't call 3.8.0 very old quite yet, given that 3.9 was only
released yesterday. From memory, there's one btrfs patch in the 3.8
stable series.
Your problem is just a
We can just look up the extent_buffers for the range and free stuff that way.
This makes the cleanup a bit cleaner and we can make sure to evict the
extent_buffers pretty quickly by marking them as stale. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V2-V3: I wanted to use
Thanks for the comments. V2 is out. Here I followed
the choice #1 as review suggested. which is to update
the error code. However I have them in uapi/linux/btrfs.h
(not in errno.h though I meant it to be there in the first
place).
pls do let me know your review comments.
Thanks,
v1-v2:
introduce error codes for the device mgmt usage
v1:
adds a parameter in the ioctl arg struct to carry the error string
Signed-off-by: Anand Jain anand.j...@oracle.com
---
fs/btrfs/ioctl.c | 22 +++---
fs/btrfs/volumes.c | 26 +++---
v1-v2:
introduce error codes for the device mgmt usage
v1:
add another parameter to the ioctl arg structure to carry the error string
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c | 10 --
ioctl.h | 37 +
2 files changed, 45
On Tue, Apr 30, 2013 at 05:51:17AM -0600, Alexander Skwar wrote:
Hugo Mills hugo at carfax.org.uk writes:
The differences in btrfs between the two are very small, and even
I(*) wouldn't call 3.8.0 very old quite yet, given that 3.9 was only
released yesterday. From memory, there's one
On Wed, Jan 09, 2013 at 12:34:45PM +0800, Liu Bo wrote:
Thanks for coding this up, I've checked the code, these messages can
be fixed by the following, please check if it works on your side :)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1b319df..1688669 100644
---
The 'end' value must exactly cover the end of the interval, which means
one byte less than the expected block alignment, or in case of a file
smaller than one block, one byte less than the inode size.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent_io.c | 27
Hello Josef
On Tue, Apr 30, 2013 at 3:58 PM, Josef Bacik jba...@fusionio.com wrote:
So we deal with this case fine, but it really shouldn't be happening, it only
happens if your block groups are way too large, which again shouldn't be
happening. Can you run fsck on this device and see if it
On Tue, Apr 30, 2013 at 04:29:44PM +0200, David Sterba wrote:
The 'end' value must exactly cover the end of the interval, which means
one byte less than the expected block alignment, or in case of a file
smaller than one block, one byte less than the inode size.
If that's actually the case,
The 'end' value must exactly cover the end of the interval, which means
one byte less than the expected block alignment, or in case of a file
smaller than one block, one byte less than the inode size.
Signed-off-by: David Sterba dste...@suse.cz
---
v1-v2: denote that range is inclusive [...]
Hello,
In an effort to be better about helping users with their bugs I've gotten
control over the btrfs component of bugzilla.kernel.org. I'm currently going
through all the bugs in this list and closing out the old ones (which is most of
them). From now on I'd like us to push users who report
I'm running tests with SANITY_CHECKS enabled and saw that the messages
were not printed with a prefix, fixed. And updated a some lines along
the way. Patches are interdependent.
David Sterba (3):
btrfs: add prefix to sanity tests messages
btrfs: move ifdef around sanity checks out of
And change the message level to KERN_INFO.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/free-space-cache.c | 97 ++-
1 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/free-space-cache.c |4 +++-
fs/btrfs/free-space-cache.h |2 --
fs/btrfs/super.c|2 --
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index
We want to know if there are debugging features compiled in, this may
affect performance. The message is printed before the sanity checks.
Also kill version.h file that serves no purpose, we don't use any
version tag for kernel module.
Signed-off-by: David Sterba dste...@suse.cz
---
A user reported a bug where we do sizeof(*ptr * count) instead of sizeof(*ptr) *
count. Fix this.
Reported-by: David Binderman dcb...@hotmail.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/send.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Quota tree has been missing from lockdep annotations, though no warning
has been seen in the wild.
There's currently one entry that does not belong there,
BTRFS_ORPHAN_OBJECTID. No such tree exists, it's probably a copy
paste mistake, the id is defined among tree ids.
Signed-off-by: David
On Tue, Apr 30, 2013 at 08:33:38AM -0600, Alexander Skwar wrote:
Hello Josef
On Tue, Apr 30, 2013 at 3:58 PM, Josef Bacik jba...@fusionio.com wrote:
So we deal with this case fine, but it really shouldn't be happening, it
only
happens if your block groups are way too large, which
24 matches
Mail list logo
