resize2fs: Can't read next inode while trying to resize

bonfire89 · 01-19-2010, 09:48 AM

Hello there,

I'm currently in the process of remove a drive from an lvm.

I am following this guide

http://ubuntuforums.org/showthread.php?t=449711

and to be honest I have also posted this question at http://ubuntuforums.org/showthread.php?t=1385223 but I have a fair amount of data at stake here and really need to make sure I'm acting safely. This is certainly not a place to button mash or guess.

this is the 2nd drive that I am removing, the first one went off without a problem.

However, I just received this error

Code:

resize2fs: Can't read next inode while trying to resize /dev/vg0/lvol0

and I'm not sure what it means or where to go from here.

The entire output is

Code:

root@dude:/mnt# resize2fs -p /dev/vg0/lvol0 4466524456k
resize2fs 1.41.4 (27-Jan-2009)
Resizing the filesystem on /dev/vg0/lvol0 to 1116631114 (4k) blocks.
Begin pass 2 (max = 253665186)
Relocating blocks             XXXXXX----------------------------------
Begin pass 3 (max = 47104)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
resize2fs: Can't read next inode while trying to resize /dev/vg0/lvol0

what should I do at this point in order to complete the removal of the hard drive from the lvm?

Thank you.

additional info:

Just prior to this resize the df output is as so

Code:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1             19228276    949600  17301928   6% /
tmpfs                   642736         0    642736   0% /lib/init/rw
varrun                  642736        56    642680   1% /var/run
varlock                 642736         0    642736   0% /var/lock
udev                    642736       196    642540   1% /dev
tmpfs                   642736         0    642736   0% /dev/shm
lrm                     642736      2192    640544   1% /lib/modules/2.6.28-17-generic/volatile
/dev/sdd1            1442145212 1368627316    261096 100% /mnt/1.5
/dev/sdh1            1442145212 1367879596   1008816 100% /mnt/freed1
/dev/mapper/vg0-lvol0
                     6077137192 4382897544 1632522860  73% /mnt/lvm

ozanbaba · 01-19-2010, 01:57 PM

did you do fsck? i'm guessing that some kind of confusion exist on the file system. you do dry run to see if it can do anything

bonfire89 · 01-19-2010, 03:39 PM

that is actually a really good idea. I'll try that. thanks. I'll report back.

though I'm not sure of the difference between that and e2fsck

I currently just set in motion

Code:

e2fsck -f /dev/vg0/lvol0

that will take a good handful of hours.

I just want to move really carefully here since I know I'm in the realm of potential big mess up. heh

ozanbaba · 01-19-2010, 03:59 PM

i'm guessing so. can't read inode error can not be a good news. fsck and see if its something can be fixed

ozanbaba · 01-19-2010, 04:02 PM

by the way, you try to resize the fs after you resize the lv right?

bonfire89 · 01-19-2010, 04:06 PM

no actually,

resize the fs then the lv.... it worked the first time and was was prescribed in the guide I'm following. =/

ozanbaba · 01-19-2010, 04:25 PM

for shrinking, resize fs then lv
for enlarging, resize lv then fs

bonfire89 · 01-19-2010, 06:31 PM

hmmmm

"Error reading block 1276051458 (Attempt to read block from filesystem resulted in short read) while getting next inode from scan. Ignore error<y>"

Any idea what do do with this?

ozanbaba · 01-20-2010, 03:42 AM

you may be having hardware problem. short read errors are confusing little errors.

bonfire89 · 01-20-2010, 06:08 AM

I'm now running with the -y option

It is my 3rd time running it, the first time it quit on it's own with

e2fsck: Can't allocate inode element

and the second time

e2fsck: Can't allocate duplicate block header

I figure there isn't much else to do.

Though, I'm not sure if the FS is resized or not at this point. If it is, I could resize the lvm, and take the drive out of the lvm, and that might solve the problem.. since my plan is to take out the drive anyway.

I'm dismantling the lvm for safety reasons, since I don't have backups and if a drive dies I would rather only lose one drives worth of information.

Although, once I do dismantle the LVM the plan is to have on drive for parity checking.

Is there any use in trying out different SATA ports?

ozanbaba · 01-20-2010, 08:59 AM

maybe you can find out if resize was successful by using dumpe2fs. information will be long and cryptic. you will have to need some fs docs to make sence of it.

if hardware problem comes from bad cable or bad socete then changing the place of hard disk may work. but be careful, device files that pointing to the hard disk will change

bonfire89 · 01-20-2010, 01:55 PM

I may try and figure that out.

In the mean time... I have found a lot of useless files!!! I have been deleting files for 6 hours now!

Over a month ago a program pretty much crashed and stopped working but I never got to fixing it due to time restraints... but... it's cache folder was enormous in the number of files it had.

I have cleared that. And now... I am removing a folder called .Trash-1000 that has gone on for probably 4 of those 6 hours! so far I think maybe .25TB has been freed up. Maybe that program that crashed when down in a spectacular way. It would be awesome if after clearing all these useless files my system were to pass e2fsck.

bonfire89 · 01-20-2010, 06:48 PM

oh jeez

/var/log/sylog

is filled with these

Code:

Jan 20 10:53:04 homeServer kernel: [50829.398184] EXT3-fs error (device dm-0): ext3_free_blocks_sb: bit already cleared for block 68287443

it seems like a folder named ./Trash-1000 is really messed up.

given the name.. I obviously don't care about it! heh

I had been using ubuntu server for a real long time. Then over I fiddled with centos for a bit.. and that is when all this started happening and that is why I went back to ubuntu..

and when I search that line (since I have no idea what it means) I seem to get messages regarding RHEL :S

ozanbaba · 01-21-2010, 12:35 AM

Quote:

Originally Posted by bonfire89

oh jeez

/var/log/sylog

is filled with these

Code:

Jan 20 10:53:04 homeServer kernel: [50829.398184] EXT3-fs error (device dm-0): ext3_free_blocks_sb: bit already cleared for block 68287443

you may indeed have a hardware problem on the disk. does it say anything
about IO errors. if so, you got a bad disk (to know for sure is to use
badblock

Quote:

it seems like a folder named ./Trash-1000 is really messed up.

given the name.. I obviously don't care about it! heh

and when I search that line (since I have no idea what it means) I seem to get messages regarding RHEL :S

intirestingly i usually found error solutions in ubuntu forums

bonfire89 · 01-21-2010, 02:06 AM

Quote:

Originally Posted by ozanbaba

you may indeed have a hardware problem on the disk. does it say anything
about IO errors. if so, you got a bad disk (to know for sure is to use
badblock

intirestingly i usually found error solutions in ubuntu forums

LOL!!!

and yes, I see some I/O errors during boot time.

For some reason in the back of my mind I wonder if there is a power issue but there shouldn't be. 7 sata drives now running off the psu (1 I have connected to a 12V adapter thing) and then CPU, RAM, MOBO, 2 controllers and usually no graphics card accept in times like these when things are being waky. Most of the drives are the WD digital green drives. Old P4 with hyperthreading (turned off) at 3.0x ghz. Abit IC7-g mobo. and the PSU is 750W. but that many drives (7) worked fine off that psu under ubuntu for quite some time. it was exactly when I tinkered with centos that things started going weird. lol. that is actually disappointing. I like the idea of running RHEL for the homeserver.

but. The good news. I discovered .Trash-1000 because I was trying to run du do find out the sizes of folders and du went so slow during .Trash-1000 I cancelled the process. Now that I have removed .Trash-1000 (it took over 10 hours) du runs as expected on the lvm.

so, I'm running e2fsc -vfy /dev/vg0/lvol0 again.. and we will see again in a few hours where I am at. At which point I'm hoping to be able to continue dismantling the LVM then implement some parity checking (which will be the next thing to figure out how to do) *crossing fingers* hehe