On Sun, 2012-12-16 at 10:45 +1100, Russell Coker wrote: > I've attached the output of dmesg after mounting the filesystem in question > with 3.6-trunk-amd64 from experimental and then running "ls -l" on the root of > the filesystem in question. > > 3.6 is a significant improvement in that although the filesystem is mounted > read-only I can access at least some of the data. With the wheezy kernel > programs like ls enter D state and never return and a hardware reset is the > only option. > > I tried to umount the filesystem but umount got stuck in D state with nothing > in the kernel log about it. So there's still some serious problems. > > I think that the kernel should be able to correct the filesystem and even if > that's not possible umount should always succeed (if this was a server it > would cause downtime). [ 59.965339] btrfs: free space inode generation (0) did not match free space cache generation (353091) Looks like filesystem corruption. It's no longer clear where the free space is... [ 62.488778] btrfs: block rsv returned -28 so it's impossible to allocate any blocks... [ 62.488782] ------------[ cut here ]------------ [ 62.488819] WARNING: at /media/data2/mattems/src/linux-3.6.9/fs/btrfs/extent-tree.c:6323 btrfs_alloc_free_block+0xd3/0x296 [btrfs]() and btrfs generally doesn't deal well with full disks. I suggest you report this upstream (linux-btrfs@vger.kernel.org), cc'ing the bug address. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way.
Attachment:
signature.asc
Description: This is a digitally signed message part