2012/3/6 Jacek Luczak difrost.ker...@gmail.com:
Hi All,
I've noticed today below WARN_ON from btrfs. Google shows hits in the
same place ([1] and [2]) but the path is different. It could happen
when svn checout or few rsyncs were running - now I'm not able to put
in correct timings. There's
Hi,
this shown up today. I had to do a hard reboot as graceful hanged on sync().
[ cut here ]
kernel BUG at fs/btrfs/delayed-inode.c:1466!
invalid opcode: [#1] SMP
CPU 10
Modules linked in: btrfs zlib_deflate lzo_compress ipmi_devintf
autofs4 be2iscsi
On Thu, Mar 08, 2012 at 01:10:45PM +0100, Jacek Luczak wrote:
kernel BUG at fs/btrfs/delayed-inode.c:1466!
1461 ret = btrfs_delayed_item_reserve_metadata(trans, root, item);
1462 /*
1463 * we have reserved enough space when we start a new transaction,
1464 * so
On 2/29/2012 11:44 PM, Theodore Tso wrote:
You might try sorting the entries returned by readdir by inode number
before you stat them.This is a long-standing weakness in
ext3/ext4, and it has to do with how we added hashed tree indexes to
directories in (a) a backwards compatible way, that
We spend a lot of time looking up extent buffers from pages when we could just
store the pointer to the eb the page is associated with in page-private. This
patch does just that, and it makes things a little simpler and reduces a bit of
CPU overhead involved with doing metadata IO. Thanks,
Am Tue, 6 Mar 2012 14:50:32 +0100
schrieb Johannes Hirte johannes.hi...@fem.tu-ilmenau.de:
I've backed up the filesystem, deleted the subvolumes, recreated them
and copied the data back. Now everything seems to work again. I've
also a full image of the damaged filesystem for further
2012/3/8 David Sterba d...@jikos.cz:
On Thu, Mar 08, 2012 at 01:10:45PM +0100, Jacek Luczak wrote:
kernel BUG at fs/btrfs/delayed-inode.c:1466!
1461 ret = btrfs_delayed_item_reserve_metadata(trans, root, item);
1462 /*
1463 * we have reserved enough space when we
On 03/09/2012 03:22 AM, Johannes Hirte wrote:
Am Tue, 6 Mar 2012 14:50:32 +0100
schrieb Johannes Hirte johannes.hi...@fem.tu-ilmenau.de:
I've backed up the filesystem, deleted the subvolumes, recreated them
and copied the data back. Now everything seems to work again. I've
also a full image
On 03/09/2012 03:35 AM, Jacek Luczak wrote:
2012/3/8 David Sterba d...@jikos.cz:
On Thu, Mar 08, 2012 at 01:10:45PM +0100, Jacek Luczak wrote:
kernel BUG at fs/btrfs/delayed-inode.c:1466!
1461 ret = btrfs_delayed_item_reserve_metadata(trans, root, item);
1462 /*
1463
When testing out 16KB blocks with direct I/O [1] on 3.3-rc6, we
quickly see btrfs_search_slot returning positive numbers, popping an
assertion [2].
Are 4KB block sizes known broken for now?
Thanks,
Daniel
--- [1]
mkfs.btrfs -m raid1 -d raid1 -l 16k -n 16k /dev/sda /dev/sdb
mount /dev/sda
On 09/03/12 12:31, Liu Bo wrote:
So are these warnings based on the latest upstream of btrfs?
Looks like it was 3.2.7, his oops said:
Pid: 1488, comm: mips-wrs-linux- Tainted: GW3.2.7 #2 HP
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
--
To unsubscribe from
11 matches
Mail list logo