Hello,

 

I was examining my syslog after a hard reset and found these in the log.  MyMain says they are minor issues.  What do they mean?

 

They were in the log after another loss of connection to my server today (something I still haven't found a solution for or the problem)(see post http://lime-technology.com/forum/index.php?topic=8766.0).

 

Nov 18 15:41:47 Tower kernel: REISERFS (device md9): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md10): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md14): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md3): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md6): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks.

Nov 18 15:41:47 Tower kernel: REISERFS (device md2): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md3): Using r5 hash to sort names

Nov 18 15:41:47 Tower kernel: REISERFS (device md6): Using r5 hash to sort names

Nov 18 15:41:47 Tower kernel: REISERFS (device md1): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md7): replayed 2 transactions in 0 seconds

Nov 18 15:41:47 Tower kernel: REISERFS (device md14): Using r5 hash to sort names

Nov 18 15:41:47 Tower kernel: REISERFS (device md13): replayed 2 transactions in 0 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md8): replayed 2 transactions in 1 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md9): Using r5 hash to sort names

Nov 18 15:41:48 Tower kernel: REISERFS (device md15): replayed 2 transactions in 1 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md12): replayed 2 transactions in 1 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md2): Using r5 hash to sort names

Nov 18 15:41:48 Tower kernel: REISERFS (device md5): replayed 2 transactions in 1 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md10): Using r5 hash to sort names

Nov 18 15:41:48 Tower kernel: REISERFS (device md4): replayed 2 transactions in 1 seconds

Nov 18 15:41:48 Tower kernel: REISERFS (device md8): Using r5 hash to sort names

Nov 18 15:41:48 Tower kernel: REISERFS (device md11): replayed 2 transactions in 1 seconds

 

I searched the other logs on the flash and the only other time this appeared was after the last loss of connection (the first log after restart).  There seems to be a connection??

 

Could losing connection be associated to the " Kernal oops" that caused Limetech to release a new version 4.6?

Yes, a kernel oops can crash a server, although the one recently fixed typically did not.

 

The messages in your log are completely normal.  They are not errors, they are status messages.  They describe the journaling file systems replaying the journal entries to get the file-systems back to where they should be.  I've see that replay of transactions take as long as 15 minutes after a hard shutdown preceded by a lot of disk activity.  None of yours took more than 1 second.  Your disks must have been mostly idle.

 

Joe L.

Thx Joe. That's a relief. I probably worry about my server too much.

 

Yes, a kernel oops can crash a server, although the one recently fixed typically did not.

 

When you use the term "Crash a server" in this instance, could that produce the problem I have been seeing? (loss of connection).  I'm guessing the server doesn't shut down?

 

Back to the log - I was just adding this to my first post when you posted.

 

When I just looked at the log again, I found further errors.  Seems to have occurred after the disk spindown was activated.

Nov 18 16:51:52 Tower kernel: ata7: exception Emask 0x10 SAct 0x0 SErr 0x990000 action 0xe frozen

Nov 18 16:51:52 Tower kernel: ata7: irq_stat 0x00400000, PHY RDY changed

Nov 18 16:51:52 Tower kernel: ata7: SError: { PHYRdyChg 10B8B Dispar LinkSeq }

Nov 18 16:51:52 Tower kernel: ata7: hard resetting link

Nov 18 16:51:52 Tower kernel: ata6: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen

Nov 18 16:51:52 Tower kernel: ata6: irq_stat 0x00400000, PHY RDY changed

Nov 18 16:51:52 Tower kernel: ata6: SError: { PHYRdyChg }

Nov 18 16:51:52 Tower kernel: ata6: hard resetting link

 

The same is happening to ata8 as well.

 

These can't be good?

 

EDIT: Just found some stuff in the wiki about this here http://www.lime-technology.com/wiki/index.php?title=The_Analysis_of_Drive_Issues#Drive_interface_issue_.234

 

I'm not sure how I associate ata5,6,7 to a drive, but I'm suspicious they are all Seagate ST500630AS drives. The wiki didn't mention a firmware update for this particular drive.