search for: dm0

Full_Name: Tomas Larsson Version: 2.6.0 OS: Windows XP Submission from: (NULL) (198.208.251.24) This is not a bug, it is a performance issue but I think it should have an easy fix. I have a large matrix (about 2,000,000 by 20), when I type colnames(x) it takes a long time to get the result. However, if I select just the first couple of rows of the matrix I don't have to wait for the

...0, Keith Keller wrote: > > That's clearly a spurious error, so I checked dmesg: > > [159891.225762] EXT4-fs (dm-0): get root inode failed > [159891.227436] EXT4-fs (dm-0): mount failed The "get root inode failed" is rather unfortunate. Try running "debugfs /dev/dm0" and then use the "stat /" command. You can use debugfs to look at the file system and recover individual files without needing to mount it. However, if the root directory has been compromised, that makes using debugfs quite a bit more difficult. You can look at inodes by inode nu...

...ackup before getting too deep into a tricky e2fsck. At one point the fs was still mountable, so I could have tried to copy files off first. (In a physical failure scenario it's exactly what I'd have done, but I wasn't thinking of that in this case.) > Try running "debugfs /dev/dm0" > > and then use the "stat /" command. No happiness: # ./e2fsprogs-1.42.10/debugfs/debugfs /dev/dm-0 debugfs 1.42.10 (18-May-2014) debugfs: stat / stat: A block group is missing an inode table while reading inode 2 My hunch is that it would take a large and lucky effort t...

Hi Bodo and Ted, Thank you both for your responses; they confirm what I thought might be the case. Knowing that I can try to proceed with your suggestions. I do have some followup questions for you: On Sun, Jun 01, 2014 at 09:05:09PM -0400, Theodore Ts'o wrote: > Unfortunately, there has been a huge number of bug fixes for ext4's > online resize since 2.6.32 and 1.42.11.

...2fsck did that apparently ended up overwriting parts of the block group descriptors. It might be possible to read the block group descriptors associated with one of the backup superblocks to find the portion of the inode table associated with inode #2. (i.e., try using "debugfs -s 32768 /dev/dm0"). One of the things that might have detected the problem sooner, and perhaps allowed you to recover more smoothly, would be to try running e2fsck immediately after running resize2fs. With the vintage kernel and e2fsprogs shipping with the version of CentOS you are apparently using, online r...

Hi all, i''ve a Problem :) I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize /dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G :( Can somebody tell me whats wrong? i dont want to lose my data at the Disk! The Machine is Debian Lenny and the guest OS also. King Regards Florian Rahmann

I''m continuing to work on making a new XenCD as previously discussed here. In the course of that work, I''ve generated (actually, currently stuck on) the enclosed crash dump. Thought I''d forward it for interest. To head off questions, you''ll see references to a very large initrd (~114 Mb). The Xen dump may or not be related to this unusual usage.