Error whilst running "tune2fs -j"
Anyone see this before? This was 2.5.65-mjb2 running on my laptop, at the start of a "tune2fs -j" ....
buffer layer error at fs/buffer.c:395
Pass this trace through ksymoops for reporting
Call Trace: [__buffer_error+51/56] [__find_get_block_slow+126/176] [unmap_underlying_metadata+18/72] [__block_prepare_write+374/
1056] [__block_commit_write+114/156] [block_prepare_write+33/56] [ext2_get_bl ock+0/744] [ext2_prepare_write+25/32] [ext2_get_block+0/744] [generic_file_ai o_write_nolock+1527/2536] [generic_commit_write+51/92] [unlock_page+10/60] [g eneric_file_write_nolock+111/140] [do_lookup+24/148] [link_path_walk+1499/1884 ] [permission+43/56] [may_open+99/376] [open_namei+672/944] [generic_file_wr ite+72/96] [vfs_write+165/268] [sys_write+42/60] [syscall_call+7/11]
Quoted 5 lines · Martin J. Bligh
Anyone see this before? This was 2.5.65-mjb2 running on my laptop, at the start of a "tune2fs -j" ....
buffer layer error at
fs/buffer.c:395
grrr. This means that the block_dev layer somehow managed to get the filesystem softblocksize confused. There is something lurking in there. As usual, if I could reproduce it I could fix it.
Was the fs mounted at the time?
What version of e2fsprogs?
Can you reproduce it?
Thanks.
Quoted 10 lines
Quoted 4 lines
Anyone see this before? This was 2.5.65-mjb2 running on my laptop, at the start of a "tune2fs -j" ....
buffer layer error at
fs/buffer.c:395grrr. This means that the
block_devlayer somehow managed to get the filesystem softblocksize confused. There is something lurking in there. As usual, if I could reproduce it I could fix it.Was the fs mounted at the time?
Yes, was my root fs.
Quoted 1 line
What version of e2fsprogs?
Standard debian woody:
mbligh@flay:~/tmp$ apt-cache show e2fsprogs Package: e2fsprogs Essential: yes Priority: required Section: base Installed-Size: 832 Maintainer: Yann Dirson <[email protected]> Architecture: i386 Version: 1.27-2 Provides: libcomerr2, libss2, libext2fs2, libe2p2, libuuid1 Pre-Depends: libc6 (>= 2.2.4-4) Suggests: gpart, parted, e2fsck-static Conflicts: e2fslibsg, dump (<< 0.4b4-4), quota (<< 1.55-8.1) Filename: pool/main/e/e2fsprogs/e2fsprogs_1.27-2_i386.deb Size: 335402
Quoted 1 line
Can you reproduce it?
Not easily, I fear ... since it's a pain in the butt to remove an ext3 journal on the root fs once mounted. I suppose I could boot from CD or something ... will try to recreate on a less valuable box over the weekend ;-)
I had been having some other trouble with the fs (power cycled a couple of times for silly reasons), but it had just ext2 fscked. I suppose there *might* have been some corruption, but seems unlikely.
M.
Quoted 12 lines · Martin J. Bligh
Quoted 2 lines
Can you reproduce it?
Not easily, I fear ... since it's a pain in the butt to remove an ext3 journal on the root fs once mounted. I suppose I could boot from CD or something ... will try to recreate on a less valuable box over the weekend ;-)
I had been having some other trouble with the fs (power cycled a couple of times for silly reasons), but it had just ext2 fscked. I suppose there *might* have been some corruption, but seems unlikely.
OK. Please add the below to your patchset. I've had this in -mm for *ages*, precisely because this problem was reported a single time, maybe four months ago.
I have not had a report of it triggering since then. I'd like to know what block number it was.
fs/buffer.c renamed from fs/buffer.c~buffer-debug +3 -0
@@ -397,6 +397,9 @@ __find_get_block_slow(struct block_devic bh = bh->b_this_page; }while (bh != head);buffer_error (); +printk ("block=%llu, b_blocknr=%llu\n" , + (unsigned long long )block, (unsigned long long )bh->b_blocknr); +printk ("b_state=0x%08lx, b_size=%u\n" , bh->b_state, bh->b_size); out_unlock:spin_unlock (&bd_mapping->private_lock);page_cache_release (page);
_