On Sat, Jul 28, 2018 at 03:47:18PM +0200, Jaco Kroon wrote: > > Just a note. In order to be able to utilize dumpe2fs I had to apply the > patch from my first email. The only utility that would start up (and > fail) was fsck. It should be noted that I've hacked s_inodes_count to > 0xFFFFFFFF the first time we encountered this (with assistance from Jan). > > Group 524287: (Blocks 17179836416-17179869183) csum 0xe0ea > [INODE_UNINIT, ITABLE_ZEROED] > Group descriptor at 17179836416 > Block bitmap at 17179344911 (bg #524272 + 15) > Inode bitmap at 17179344927 (bg #524272 + 31) > Inode table at 17179352608-17179353119 (bg #524272 + 7712) > 12 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes > Free blocks: 17179838452-17179838463 > Free inodes: 4294959105-4294967296 > > If I read that correctly none of the inodes are in use, but there are > some data blocks in use (in fact, most of it). > > Suggestions/pointers on how to get those blocks re-allocated elsewhere? I'd suggest trying to see if you can use debugfs's icheck command to take a block number (such as 17179353120, for example, just beyond the inode table) and map it to an inode number: debugfs: icheck 17179353120 This will give you some inode number, perhaps 156789 (for example). You can then take the inode number and map it to a pathname: debugfs: ncheck 156789 You can then mount the file system, copy that file off, and then delete it. Then see what blocks are left as in use. Lather, Rinse, Repeat. :-) - Ted
