ReadyNAS Diagnostic error

Hi BrianL,

BrianL2 wrote:

Hi davidr1,

 

I am not sure how but let me check it with my colleagues and get back to you.

 

 

Kind regards,

 

BrianL
NETGEAR Community Team

Any luck yet, please?

I ran Diagnostics again today. The results were:

On the ReadyNAS 314 (2x4TB WD Red):

2016-09-28 09:53:26: EXT4-fs error (device sdc1):

ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-25 08:44:28: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-23 13:42:28: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-13 13:06:40: EXT4-fs error (device sdd1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-10 14:12:09: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-06 14:47:02: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-03 13:56:17: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-09-01 12:44:05: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-08-30 13:10:40: EXT4-fs error (device sdd1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-08-24 09:36:51: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-08-16 14:30:47: EXT4-fs error (device sdd1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters
2016-08-14 09:49:40: EXT4-fs error (device sdc1): ext4_mb_generate_buddy:757: group 2179, block bitmap and bg descriptor inconsistent: 32254 vs 3021 free clusters

On the Ultra (2x1TB WD Red):

2016-09-12 11:23:04: journalctl[7632]: segfault at 7fcf2d8a9e68 ip 00007fcf35200f71 sp 00007ffd28a192f0 error 4 in libsystemd-journal.so.0.0.3[7fcf351fe000+11000]
2016-09-12 09:57:39: journalctl[4522]: segfault at 7f326292ee68 ip 00007f326a15bf71 sp 00007fff0d248100 error 4 in libsystemd-journal.so.0.0.3[7f326a159000+11000]

On the Pro (2x2TB WD Red):

2016-09-23 07:39:28: EXT4-fs error (device sdc1): ext4_put_super:789: Couldn't clean up the journal
2016-09-23 07:23:24: EXT4-fs error (device sdc1): ext4_read_inode_bitmap:184: comm rsync: Cannot read inode bitmap - block_group = 384, inode_bitmap = 12582928
2016-09-23 07:23:10: EXT4-fs error (device sdc1): ext4_find_entry:1457: inode #2: comm rsync: reading directory lblock 0

Any advice as to what this means would be appreciated - especially if I need to replace any disks.

David

Do you still see this on 6.6.0-RC2?

EXT4 is a Linux filesystem. You could do a read-only filesystem check on the USB disk using e2fsck if you specify the right options. I would suggest using the options to do a read-only check first and check to see the result.

Hi mdgm,

Thanks for your reply.

I'm on 6.5.2. I steer clear of Beta releases as these are in business use. So I haven't tried 6.6.0-RC2.

Are you saying that sdc drives are external? Then in a 4 bay RAID 2 how are the drives designated?

Critically, does any of my post refer to internal NAS drives?

IMHO it would be great if the NAS did not check external devices - and cause fewer heart failures :-)

Many thanks,

David

I do realise this forum is busy and I do appreciate the support it gives.

Does my post indicate disk failure in the NAS units?

Many thanks

David

Lots of errors with your external disk - if it is healthy perhaps it needs reformatting.

Netgear said that the segfault was fixed in 6.6.0.  What else are you seeing that is concerning you?

Many thanks StephenB.

---

StephenB wrote:

Lots of errors with your external disk - if it is healthy perhaps it needs reformatting.

---

Yes, I have run e2fsck on all of them (for the three units I use 12 disks - daily or weekly or monthly backup disks) and 'corrected' the errors.

---

Netgear said that the segfault was fixed in 6.6.0.  What else are you seeing that is concerning you?

---

How do I clear the logs so the next diagnostic does not show the same historical errors ?

I'm on 6.5.2 -6.6.0 isn't released yet is it except in Beta? I need to be sure it is 'safe' before installing betas. Check For Updates says I have the latest.

I think what concerns me most is why does OS 6+ check external backup drives when doing Diagnostics? The results can be confusing (as they were to me) as IMHO checking external backup drives should be the job of the user. My immediate reaction is my NAS disks are failing.

Thanks

ReadyNAS OS 6.6.0 has been released. It is available as a local update only at this time.

After checking it on 6.6.0 you could post an idea in the Ideas Exchange suggesting that the Diagnostics tool makes it clear which disks are internal and which are external.

Thanks mdgm

And thanks also to StephenB - you guys and others help us so much.

Please know it is really appreciated.

I will update this weekend, check and make the suggestion.

---

mdgm wrote:

You won't get a segfault error when checking diagnostics on 6.6.0.

---

Upgraded 31400, Pro and Ultra to 6.6.0 and ran Diagnostics as requested. Run at 2016-10-01 11:15 approx.

1.

No external drives attached. Diagnostics on Ultra show a segfault though note the date:

2016-09-12 11:23:04: journalctl[7632]: segfault at 7fcf2d8a9e68 ip 00007fcf35200f71 sp 00007ffd28a192f0 error 4 in libsystemd-journal.so.0.0.3[7fcf351fe000+11000]
2016-09-12 09:57:39: journalctl[4522]: segfault at 7f326292ee68 ip 00007f326a15bf71 sp 00007fff0d248100 error 4 in libsystemd-journal.so.0.0.3[7f326a159000+11000]

2.

Is there any way of preventing historical faults on sdc1 from showing in these reports? Clutter, confusing and annoying :-)

The logs do get rotated/truncated automatically after a period of time. Not sure how many lines we keep for the journal, but it is several times the amount of lines we include in the logs zip download.

Thanks...