does anyone know where I can read up more about clearing inodes and such?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
does anyone know where I can read up more about clearing inodes and such?
I have a server right now that is clearning inodes and has been since sunday, its a raid 10 array and it has said its cleared 6 million 19 thousand of them.
Mikaa, ext3 does use inodes. It just adds journaling to protect the filesystem state in case of a sudden crash.
Edkhosting -- are you getting this message during a filesystem fsck on bootup (or initiated manually)? Any time I've seen something like that it has generally pointed to a badly corrupted filesystem. Was the system forcibly shutdown recently or have there been any hardware failures? If the filesystem is damaged badly enough, you may need to clean things out by hand via debugfs (do not use unless the situation is hopeless and you really know what you're doing -- debugfs allows you to directly edit inodes, amongst other things) and if that fails restore from back-ups.
a filesystem fsck on bootup. Here is what I posted on another board
Quote:
I have a db server its a dual xeon with 2gb ram and a Adaptec 2230SLP with 4 Fujitsu 74GB running in a raid 10 setup and a Western Digital Raptor for a backup drive.
The main os is on the raid array(everything is). I didn't make it so \var\lib\mysql was on the raid array and mount it and have the os on another drive. Now this db server has 2 large databases on it totaling in over 3 million tables and 38gb of space. The server locked up the other night and it was rebooted and so I went to run a check on it when it came up and opened up a screen session and ran "mysqlcheck -rof --all-databases" which I have done many times before nothing unusual. The database was running correctly and the forum was working fine. It usually takes about 6-8 hours to do this and about 2 hours into it I noticed the server was somewhat down but before usually I wouldn't be able to ssh in but I was able to this time. I went and checked the screen session and every table it was checking was saying that it was read only and it was going through all the tables. Going onto the forums that the databases are used for it was throwing up an error saying the sessions table was read only and couldn't write to it. Well I tried to do a shutdown -r now and reboot the server but shutdown just hung I went into top and tried to kill it and couldn't so the server was hard rebooted. It came up and said that there were errors on the drive/raid array and to run a check. Well this has been since sunday on the 11th that it started clearing inodes after running fsck and it has currently cleared around 6 million 19 thousand inodes and counting.
Now after all this my question is do you think my databases are gone? I would hope not since the os was able to load and the server is running its just clearing inodes which means its fixing the file system. I cannot ssh in it is still running now clearing inodes. The thing is its clearing the inodes where the databases are located it seems the inodes for everything else is fine.
so my feeling is the data/databases are still there its just the permissions on them are wrong and it has to do with the inodes to which fsck is fixing now. I mean they were fine and then it said the tables were read only it didn't say they didn't exist that its just read only. I don't know how long this is going to take for the server to fix everthing but its been running since sunday clearing inodes so I take it thats a good thing. Also I was pondering the idea if I could just stop the check and tar up the msql folder even with the wrong permissons and just move them over to another db server that I ordered and is live and reset the permissions there on the new server to what they should be with that mysql database. Will that work?
background is I run a free forum host and there are two db's one for each web server. Each web server is hosting about 30,000 phpbb forums and each forum has about 25 tables so you can do the math on how many tables each db is holding.
Last edited by edkhosting; 12-15-2005 at 02:54 AM.
The inodes also hold the lists of the actual disk blocks used by the files, so if those lists have gotten corrupted, you're in trouble. Although if things were working OK for awhile, maybe you'll be lucky and the corruption will be with other files in the filesystem. My advice would be to let fsck run to completion and see what happens. Be prepared to look in the filesystem's lost+found directory for bits and pieces of files that fsck may recover from damaged files.
You need to figure out what caused the problem in the first place. Are your RAID controller and all of the disks working correctly? Have you had any disk or other subsystem failures?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.