I am testing btrfs on Linux 2.6.31.1 and am repeatedly hitting the
following issue in the btrfs-endio-wri thread:
[ cut here ]
kernel BUG at fs/btrfs/file.c:528!
invalid opcode: [#1] PREEMPT SMP
last sysfs file: /sys/block/dm-0/range
CPU 0
Modules linked in: nls_utf8
On Wednesday 07 October 2009 05:17:54 Chris Mason escribió:
Thanks, I'll try to reproduce. Which raid level did you use for data?
If not raid1, could you try with raid1? ;)
I'm not sure, since the utils won't tell. I mkfs'ed and mounted one of the 3.5GB
files with no special options, and
On Wed, Oct 07, 2009 at 03:51:46PM +0200, Diego Calleja wrote:
On Wednesday 07 October 2009 05:17:54 Chris Mason escribió:
Thanks, I'll try to reproduce. Which raid level did you use for data?
If not raid1, could you try with raid1? ;)
I'm not sure, since the utils won't tell. I mkfs'ed
On Wed, Oct 07, 2009 at 11:34:54AM +0100, Stefan Hajnoczi wrote:
I am testing btrfs on Linux 2.6.31.1 and am repeatedly hitting the
following issue in the btrfs-endio-wri thread:
[ cut here ]
kernel BUG at fs/btrfs/file.c:528!
invalid opcode: [#1] PREEMPT SMP
On Wed, Oct 7, 2009 at 4:25 PM, Chris Mason chris.ma...@oracle.com wrote:
This oops means that we're trying to insert an extent that already
exists. I think it is related to the bug in the file clone ioctl that
Sage recently fixed. The fix is in the master branch of the
btrfs-unstable tree.
On Wed, Oct 07, 2009 at 04:35:37PM +0100, Stefan Hajnoczi wrote:
On Wed, Oct 7, 2009 at 4:25 PM, Chris Mason chris.ma...@oracle.com wrote:
This oops means that we're trying to insert an extent that already
exists. I think it is related to the bug in the file clone ioctl that
Sage recently
my wishlist item is for btrfs to expose to user-space enough
functionality that keeping sqlite databases directly in the file
system instead of through its own abstraction in a file maintained in
the fs will be a matter of replacing sqlite's btree.c file, and
referring to an sqlite database using
On Wednesday 07 October 2009 21:45:29 Chris Mason escribió:
I'm afraid this is good old enospc. Balancing still needs some work to
be completely safe.
I've tried using less data and raid1, but I can't reproduce it.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
By the way, i think it'd be useful if debug-tree would tell which policy
the fs is applying to each chunk. Something like this:
item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 8379826176) itemoff 3495
itemsize 112
chunk length 319881216 owner 2 type 17 (data on RAID1)
On Fri, Sep 25, 2009 at 02:10:14PM -0700, Sage Weil wrote:
Hi everyone,
So, the btrfs user transaction ioctls work like so
ioctl(fd, BTRFS_IOC_TRANS_START);
/* do many operations: write(), setxattr(), rmdir(), whatever. */
ioctl(fd, BTRFS_IOC_TRANS_END);/* or close(fd); */
and
Hi Val!
On Wed, 7 Oct 2009, Valerie Aurora wrote:
On Fri, Sep 25, 2009 at 02:10:14PM -0700, Sage Weil wrote:
Hi everyone,
So, the btrfs user transaction ioctls work like so
ioctl(fd, BTRFS_IOC_TRANS_START);
/* do many operations: write(), setxattr(), rmdir(), whatever. */
11 matches
Mail list logo
