NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
New FSCK Errors
Today I performed an upgrade to 4.2.24 and selected a volume scan on reboot. Here is what was found:
***** File system check forced at Tue Jul 23 21:02:13 WEST 2013 ***** fsck 1.42.8 (20-Jun-2013) e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Inode 4195619, end of extent exceeds allowed value
(logical block 64907, physical block 11435403, len 16) Clear? yes
Inode 4195619, i_blocks is 1337216, should be 1337176. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information Block bitmap differences: -(11435403--11435407) Fix? yes
Free blocks count wrong for group #348 (2130, counted=2135).
Fix? yes
Free blocks count wrong (417470107, counted=417470112).
Fix? yes
/dev/c/c: ***** FILE SYSTEM WAS MODIFIED *****
/dev/c/c: 625785/30212096 files (13.6% non-contiguous), 65923424/483393536 blocks
Any ideas???
If it helps guys, the same file as before is causing the issue with inode 4195610, a very large MS access DB.
***** File system check forced at Tue Jul 23 21:02:13 WEST 2013 ***** fsck 1.42.8 (20-Jun-2013) e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Inode 4195619, end of extent exceeds allowed value
(logical block 64907, physical block 11435403, len 16) Clear? yes
Inode 4195619, i_blocks is 1337216, should be 1337176. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information Block bitmap differences: -(11435403--11435407) Fix? yes
Free blocks count wrong for group #348 (2130, counted=2135).
Fix? yes
Free blocks count wrong (417470107, counted=417470112).
Fix? yes
/dev/c/c: ***** FILE SYSTEM WAS MODIFIED *****
/dev/c/c: 625785/30212096 files (13.6% non-contiguous), 65923424/483393536 blocks
Any ideas???
If it helps guys, the same file as before is causing the issue with inode 4195610, a very large MS access DB.
9 Replies
Replies have been turned off for this discussion
- What model ReadyNAS is this on and if you download the logs (Status > Logs > Download all logs) and extract the zip contents what does the initrd.log look like?
- It's a ReadyNAS Pro 6.
I actually suspect the issue may be due to me reloading the NAS whilst users still have an open connection to the MS Access DB. I am going to request that all users close this down at the end of each day.
Nothing exciting here:
[2012/08/03 09:02:35] Factory default initiated by button!
[2012/08/03 09:05:12] Selected X-RAID2 mode, 10GB snapshot, RAID level 6
[2012/08/03 09:05:41] Factory default initiated on RAIDiator 4.2.21.
[2013/06/10 19:31:26] Updated from RAIDiator 4.2.21 to 4.2.23.
[2013/07/23 20:02:08] Updated from RAIDiator 4.2.23 to 4.2.24. - Any feedback?
- Did you test your theory?
- Well I am going to leave it a couple of months first before trying this.
- Have you tried sending your logs into support for review? You can open an online support case and attach your logs to your case (see the Online Submission link in my sig).
- To be honest, I've been through them myself and there isn't really anything useful.
I'll see what happens when I next reload. - OK... I ensured that the access DB was closed on all machines prior to doing a reboot at 40 days and no fsck errors were seen.
I believe the DB being open when the NAS is reloaded was the cause of the errors but in theory I don't see why this should happen. It certainly didn't on the NV+ I was using previously, although that would be ext3 and not ext4. - Anybody able to think of a reason behind this?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
