Question about message "EXT3-fs: INFO: recovery required on readonly filesystem"

Notice when machine is booting that disk repair will sometimes show the in the logs. Not always though. Could someone please answer the following three questions....
1. Does this indicate any hard drive problems or anything I should be concerned about, or is it normal operation?
2. What is the cause of this needing repair?
3. Should systems be rebooted every so often so inodes can be cleaned up or can it also happen during runtime?

Dist = Debian 6.0.7

Thanks.

SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.01: SATA link down (SStatus 0 SControl 300)
ata1.00: ATA-8: TOSHIBA THNS256TY8CCAA, AGYA0310, max UDMA/100
ata1.00: 500118192 sectors, multi 16: LBA48
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA  TOSHIBA THNS256G AGYA PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: dm-0: orphan cleanup on readonly fs
ext3_orphan_cleanup: truncating inode 1810667 to 0 bytes
ext3_orphan_cleanup: deleting unreferenced inode 1811265
ext3_orphan_cleanup: deleting unreferenced inode 6584451
ext3_orphan_cleanup: deleting unreferenced inode 7156684
ext3_orphan_cleanup: deleting unreferenced inode 7588970
ext3_orphan_cleanup: deleting unreferenced inode 1169769
ext3_orphan_cleanup: deleting unreferenced inode 1169754
ext3_orphan_cleanup: deleting unreferenced inode 728012
ext3_orphan_cleanup: deleting unreferenced inode 446658
ext3_orphan_cleanup: deleting unreferenced inode 1206016
ext3_orphan_cleanup: deleting unreferenced inode 1206018
ext3_orphan_cleanup: deleting unreferenced inode 1209060
EXT3-fs: dm-0: 11 orphan inodes deleted
EXT3-fs: dm-0: 1 truncate cleaned up
EXT3-fs: recovery complete.
LinkAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

rindiCommented:
On Linux the file-system is checked and if necessary repaired after a certain number of reboots (I believe the default is 50). If it happens outside of that window, then a problem was detected and the check done when needed.

This can point to disk problems, but also other issues can cause this, such as system crashes where files weren't properly closed for example.

To do the repairs the file-system must be in read only mode, and the best way to do this is via a reboot.

I would check the RAID controller's utility for problems with the disks, or if you aren't using a RAID controller, boot the PC using the UBCD and then run the disk manufacturer's diagnostic tool which is included on that CD. If either the controller or the utility reports an error, you should replace the bad disk.

http://mirror.sysadminguide.net/ubcd/ubcd535.iso

Also check the rest of the PC for if the disks are fine, for reasons why it may be crashing, (overheating, bad RAM, bad powersource/PSU etc.).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
LinkAuthor Commented:
Thanks for comment....This is a Linux server with a redundant backup and the active node was up and running for about a year. Upon reboot there were over 20 orphaned unreferenced inodes that were deleted. Two hours later the node was again restarted and I saw a single inode get cleaned up. Would you know what causes files not to be properly closed? Also do file checks ever occur when the system is running?
I'd like to investigate this problem more deeply can you point me to any good reference material? Trying to figure out what is normal behavior and what isn't.
rindiCommented:
There are a lot of things that can cause file-system corruption, as I mentioned earlier. The fsck doesn't happen during normal operation. If the system was running for one year without reboot, I'd say it is normal to get some corruption, but it would still be a good idea to check the state of the disks. Most servers include a module you can use to connect to the server remotely to check it's hardware. For example on Dell Servers that is iDRAC, and on HP servers ILO. Of course this needs to be configured first to start off.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.