brand new HDD but EXTENTS_FL errors

rodp

Member
Hi All,

Just purchased a new HDD as per recommendations on this site. I bought a 2TB skyhawk. As instructed, the first thing I did was plug it into the humax and let it format the drive. No errors occured, disc check worked fine too. I then went onto webif and reinstalled webif. I then took a look at the SMART info. I spotted some high numbers on the smart report which lead me to put in it a external caddy and run the check system via gparted. It came up with many errors about inodes:

inode xxxxxxx has EXTENTS_FL flag set on filesystem without extents support.
Clear? yes

the check program (called something like e2fsck?) went through the HDD. For some reason when I tried to save the report from gpart it froze so I could only take a screen shot. Sorry about that!

Screenshot from 2020-09-07 19-27-06.png

I'm working on a Ubuntu live CD so let me save this and attached a screen shot of the SMART report below.


After installing webif and connecting after reboot the first time I got the above errror message but presume that was because it was a new disc (overall health is unknown)?

I clicked on acknowledge for the time being.
1599509113443.png
Sorry, the pic got clipped here it is again

This info was taken after formatting, reboot, install webif, reboot.

SMART data read from device /dev/sdb
Disk Information
SMART StatusPASSED
Device ModelST2000VX008-2E3164
Serial NumberZ529LXK4
LU WWN Device Id5 000c50 0c499e22f
Firmware VersionCV12
User Capacity2,000,398,934,016 bytes [2.00 TB]
Sector Sizes512 bytes logical, 4096 bytes physical
Rotation Rate5900 rpm
Form Factor3.5 inches
ATA Version isACS-2, ACS-3 T13/2161-D revision 3b
SATA Version isSATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time isSun Sep 6 12:36:32 2020 BST
SMART support isAvailable - device has SMART capability.
SMART support isEnabled
Attributes
IDNameFlagsRaw ValueValueWorstThresholdLife LeftNotes
1Raw_Read_Error_RatePOSR--421296100100006-
3Spin_Up_TimePO----0099099000-
4Start_Stop_Count-O--CK3100100020100%-
5Reallocated_Sector_CtPO--CK0100100010100%-
7Seek_Error_RatePOSR--32048100253030-
9Power_On_Hours-O--CK0100100000100%-
10Spin_Retry_CountPO--C-0100100097100%-
12Power_Cycle_Count-O--CK3100100020100%-
184End-to-End_Error-O--CK0100100099-
187Reported_Uncorrect-O--CK0100100000-
188Command_Timeout-O--CK0100100000-
189High_Fly_Writes-O-RCK0100100000-
190Airflow_Temperature_Cel-O---K30070 (30°C)070 (30°C)045 (55°C)-
191G-Sense_Error_Rate-O--CK0100100000-
192Power-Off_Retract_Count-O--CK3100100000100%-
193Load_Cycle_Count-O--CK3100100000100%-
194Temperature_Celsius-O---K30030040000-
197Current_Pending_Sector-O--C-0100100000-
198Offline_Uncorrectable----C-0100100000-
199UDMA_CRC_Error_Count-OSRCK0200200000-
Self-test logs
No.DescriptionStatusRemainingWhenFirst Error LBA
# 1Short offlineCompleted without error00%0-
# 2Short offlineCompleted without error00%0-
Acknowledge any current disk faults.

Here's a pic of the hdd
IMG_20200907_205243.jpg

-I'm using Humax HDR-Fox T2 (humax) 1.03.12/3.10
-Please could some one tell me what EXTENTS_FL flags are and what EXTENTS support is?
-Is this an effect of the Humax formatting something larger than 1TB?
-Has the gpart check process fixed something which needed fixing or has it upset the HDD for the humax to work properly and therefore I should reformat the drive again in Humax and then not run gparted on it?
-What do the high counts mean in the SMART data?

Thanks in advance

Rodp
 

Attachments

  • Screenshot_20200906-123539_Chrome.jpg
    Screenshot_20200906-123539_Chrome.jpg
    535.4 KB · Views: 9
  • 1599509099718.png
    1599509099718.png
    641.3 KB · Views: 5
Last edited:
I don't know why the Webif diagnostics are recording the disk health as unknown; a bug in Webif with these new disks perhaps? I'm speculating about this, I don't know.
I would not worry about those apparently high read and seek error rates, they are in hex: see here.
I think the extents flags are ext4 attributes that are unsupported in the ext3 format the HDR-FOX uses. I have seen something similar with the HD-FOX and the inline data flag: thread here. The version of e2fsck on your PC is probably the culprit: too new.
I would install the disk into the HDR-FOX, format through the on-screen menus using the remote control handset: the latest standard firmware will format a disk up to 2TB in size (you can format up to 4TB with the custom firmware, but not through the standard menus). Then, with the custom firmware installed, I would boot into maintenance mode and run fix-disk. This will correct filesystem errors with e2fsck, but not a version that will corrupt the ext3 filesystem.
 
Ignore the SMART nag - it's just WebIf dimness for whatever reason. The 'high' counts as perfectly normal.
Put the disk back in the Humax, go to maintenance mode and format the partitions as per the 2TB blog. You don't need to do the partitioning bit, just the stuff with mkfs:
Code:
humax# umount /dev/sda[123]
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda3
Reboot and reinstall WebIf.
It's much quicker than messing with anything else.
Job done.

Oh, and you need to install CF 3.13 as well. You're on 3.10.
 
as per the 2TB blog

- If I follow the blog, does that still mean i shouldn't then plug it into my pc and run any checks using my unbuntu 16.04 lice CD going forwards?

Oh, and you need to install CF 3.13 as well. You're on 3.10.

Sorry I think I got the CF version wrong as it would have downloaded it from the internet so it would have been the latest version.

- Is the below all I need to do from maintenance mode / prompt?
humax# umount /dev/sda[123]
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda3

- Will I be ok once reformatted to plug it back into my PC and copy the videos back over (but obviously not touch gparted / e2fsck)? My PC has USB 3 so will be a lot quicker. I only ask this just incase there is some rights / permissions issue that may cause an issue if doing this with the HDD out of the Humax box?

Thanks

Rodp
 
Last edited:
I spotted some high numbers on the smart report which lead me to put in it a external caddy and run the check system via gparted.
For heaven's sake why? What high numbers? Why would you do that without asking first?

After installing webif and connecting after reboot the first time I got the above errror message but presume that was because it was a new disc (overall health is unknown)?
Almost certainly. Just acknowledge and forget. Don't go looking for problems where none exist. Absolutely don't worry about error messages generated by a foreign system.
 
What high numbers?
these... are they high numbers? however following ' seek error rates, they are in hex: see here. ' quote above, I now understand that they are hex so that's all fine. :)
1599515919692.png


Why would you do that without asking first?
There is me thinking ubuntu 16.04 e2fsck would be backward compatible and not upset things! Obviosuly not?! I guess if I'd known that these raw values were actually hex (please note no letters A-F which would have otherwise given the game away), then the I probably would have ignored it - oh well, no harm done I guess, I shall reformat the HDD back in the humax as per:

humax# umount /dev/sda1
humax# umount /dev/sda2
humax# umount /dev/sda3
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda1
humax# mkfs.ext3 -m 0 -O sparse_super -T largefile /dev/sda2
humax# mkfs.ext3 -m 0 -O sparse_super /dev/sda3

Then reinstall the CF ware.

But can anyone confirm that I can still mount the drive onto Ubtun 16.04 and copy the files over without getting into problems such as permissions etc, (backup currently stored on an NTFS formatted drive).


Thanks

Rodp
 
The big red warning can appear whenever WebIf can't be sure that disk health hasn't changed.

The EXT2FS libraries and binaries should be the basically the same (SO version 2.4) between the Humax (with CF) and Ubuntu 16.04:
Code:
humax# ls -l /usr/lib/libext2*
lrwxrwxrwx 1 root root     14 Apr 26  2017 /usr/lib/libext2fs.so -> libext2fs.so.2
lrwxrwxrwx 1 root root     16 Apr 26  2017 /usr/lib/libext2fs.so.2 -> libext2fs.so.2.4
-rw------- 1 root root 207996 Dec  9  2014 /usr/lib/libext2fs.so.2.4
humax# mkfs.ext2 -V
mke2fs 1.42.13 (17-May-2015)
        Using EXT2FS Library version 1.42.13
Code:
Ubuntu$ ls -l /lib/i386-linux-gnu/libext2*
lrwxrwxrwx 1 root root     16 Feb 18  2020 /lib/i386-linux-gnu/libext2fs.so.2 -> libext2fs.so.2.4
-rw-r--r-- 1 root root 465436 Feb 18  2020 /lib/i386-linux-gnu/libext2fs.so.2.4
Ubuntu$ mkfs.ext2 -V
mke2fs 1.45.5 (07-Jan-2020)
	Using EXT2FS Library version 1.45.5
However when you run the format from the on-screen Humax UI, it doesn't just run the mkfs.ext2 program to format the partitions in the normal way: it formats them using its own code that calls the Ext2 libraries. This could have been borrowed from earlier mkfs.ext2 sources or just invented by Humax programmers, and might therefore disagree in detail with what e2fsck v1.45.5 expects, or even with what e2fsck v1.42.13 expects.
 
However when you run the format from the on-screen Humax UI, it doesn't just run the mkfs.ext2 program to format the partitions in the normal way: it formats them using its own code that calls the Ext2 libraries. This could have been borrowed from earlier mkfs.ext2 sources or just invented by Humax programmers, and might therefore disagree in detail with what e2fsck v1.45.5 expects, or even with what e2fsck v1.42.13 expects.
So, is there a need to reformat the disc within the Humax, using the above procedure still?
Should I also be advised not to do a e2fsck on the HDD in the future whilst connected up to Ubtuntu 16.04?

Some straight forward Yes / No answers would be great :)

Thanks

Rodp
 
does that still mean i shouldn't then plug it into my pc and run any checks using my unbuntu 16.04 lice CD going forwards?
Do it if you like. But I can't see much point in it at this time.
Is the below all I need to do from maintenance mode / prompt?
Yes.
Will I be ok once reformatted to plug it back into my PC and copy the videos back over
Yes.
these... are they high numbers? however following ' seek error rates, they are in hex
They're not high. And they're not hex. They are normal decimal.
So, is there a need to reformat the disc within the Humax, using the above procedure still?
I would. What have you got to lose?
Should I also be advised not to do a e2fsck on the HDD in the future whilst connected up to Ubtuntu 16.04?
It shouldn't matter. Try it now, having done the format, before you waste any more time agonising over things that don't need agonising over.
 
are they high numbers?
As above: no. You panicked due to not understanding what normal is.

You don't need to do the tune-up prpr recommends, all that was necessary was to fit the disk and let the Humax format it, but the tune-up improves performance (particularly when running fix-disk).

I think this is why car manufacturers are reducing the number of instruments on the dashboard: the more information there is, the more untrained drivers have to worry them (or completely ignore, which is just as bad). The Mk7 Fiesta doesn't even have a temperature gauge. My view is to provide the information and train people to use it properly - if they won't be trained that's their problem.
 
I think this is why car manufacturers are reducing the number of instruments on the dashboard: the more information there is, the more untrained drivers have to worry them (or completely ignore, which is just as bad). The Mk7 Fiesta doesn't even have a temperature gauge.
For some time temp gauges have been non-linear with a dead-zone in the middle to stop people worrying or complaining when it deviates slightly from the centre line.
 
Ugh. Keeping an eye on things like that can save major breakdown. I wish I had a voltage gauge (but never got around to fitting one), that would have saved a few problems from time to time as well.
 
They're not high. And they're not hex. They are normal decimal.
OK, my statement was incorrect, but your answer is only partial. The values are a composite of two values (number of seek errors plus total number of seeks) and can only be understood by converting them to hex, extracting both values and then converting from hex to decimal. For example, a seek error rate of 31715 corresponds to 0x0007BE3 which is 7 errors from BE3/ 3043 seeks.

EDIT. My calculation is incorrect: see post #19 below.
 
Last edited:
...
-Please could some one tell me what EXTENTS_FL flags are and what EXTENTS support is?
...
Having refreshed my memory, EXTENTS is a feature of the Ext4 filesystem format. The Ext2 filesystem architecture allows for extensions: Ext3 introduced journalling, and Ext4 introduced EXTENTS (a more efficient way of recording the disk usage of large files). Ext4 appeared just around the time of the Humax OEM software, and is supported by the EXT2FS software e2fsprogs v1.42.13 in the CF (you even get an Ext4 formatter if you install the repository e2fsprogs package). The driver for each filesystem version is supposed to be able to handle earlier versions without introducing anachronistic features.

I wouldn't expect an Ext4 filesystem to be usable even on a HD/HDR with CF, because the Ext4 filesystem kernel driver was added in kernel 2.6.28 vs our 2.6.18 (though perhaps someone could build fuse2fs, omitted from the default e2fsprogs installation, to add Ext4 support).

So the messages saying "inode xxxxxxx has EXTENTS_FL flag set on filesystem without extents support" are saying that the filesystem, which should be Ext3 formatted, has flags set that should only be set in Ext4 (or later, should such appear).

Inquiring minds will wonder how these flags became set:
  1. did the Humax formatter set them because of a bug?
  2. did the Humax formatter set them deliberately as part of an attempt to create an undocumented extension of Ext3?
  3. did the flags appear to be set because of an underlying disk fault (eg, intermittent logic fault on one bit)?
  4. did some rogue software set them on the Humax?
  5. did some rogue software set them on the Ubuntu PC?
As the EXT2FS software version 1.41 introduced EXTENTS, #2 should have caused the same messages to appear in any fix-disk run, which doesn't seem to be the case.

#3 doesn't match the SMART results.

That leaves some sort of bug as the possible cause.

The lead EXT2FS developer had this response to a similar report:
Ted Ts'o said:
What I suspect happened is that some kind of garbage --- perhaps simply a single 4k block of 0xFF's --- got written into the inode table. This would trigger this sort of complaint from e2fsck.
reporter said:
Perhaps this is just a consequence of check ordering though - maybe if the inode flags get corrupted then the EXTENTS flag is just the first one that will be tested in the e2fsck code?
Yes, this is one of the first things that e2fsck 1.42.x would test for.
 
Having refreshed my memory, EXTENTS is a feature of the Ext4 filesystem format. The Ext2 filesystem architecture allows for extensions: Ext3 introduced journalling, and Ext4 introduced EXTENTS (a more efficient way of recording the disk usage of large files). Ext4 appeared just around the time of the Humax OEM software, and is supported by the EXT2FS software e2fsprogs v1.42.13 in the CF (you even get an Ext4 formatter if you install the repository e2fsprogs package). The driver for each filesystem version is supposed to be able to handle earlier versions without introducing anachronistic features.

I wouldn't expect an Ext4 filesystem to be usable even on a HD/HDR with CF, because the Ext4 filesystem kernel driver was added in kernel 2.6.28 vs our 2.6.18 (though perhaps someone could build fuse2fs, omitted from the default e2fsprogs installation, to add Ext4 support).

So the messages saying "inode xxxxxxx has EXTENTS_FL flag set on filesystem without extents support" are saying that the filesystem, which should be Ext3 formatted, has flags set that should only be set in Ext4 (or later, should such appear).

Inquiring minds will wonder how these flags became set:
  1. did the Humax formatter set them because of a bug?
  2. did the Humax formatter set them deliberately as part of an attempt to create an undocumented extension of Ext3?
  3. did the flags appear to be set because of an underlying disk fault (eg, intermittent logic fault on one bit)?
  4. did some rogue software set them on the Humax?
  5. did some rogue software set them on the Ubuntu PC?
As the EXT2FS software version 1.41 introduced EXTENTS, #2 should have caused the same messages to appear in any fix-disk run, which doesn't seem to be the case.

#3 doesn't match the SMART results.

That leaves some sort of bug as the possible cause.

The lead EXT2FS developer had this response to a similar report:
The fault is probably caused by the version of e2fsck on the PC the OP used. The second link in post #2 is to a thread where running e2fsck on the HD-FOX caused the inline data flags (ext4 only attribute) to be set on some inodes of an ext3 disk. This happened after @af123 updated the version of e2fsck in the repository to 1.43.3. Rolling back to version 1.42.13 of e2fsck stopped the problem happening again. It would be interesting to know the version of e2fsck that was running on the OP's PC when the problem came to light.

EDIT. The OP was using version 1.45.5 of e2fsck.
 
Last edited:
  • Like
Reactions: /df
So the messages saying "inode xxxxxxx has EXTENTS_FL flag set on filesystem without extents support" are saying that the filesystem, which should be Ext3 formatted, has flags set that should only be set in Ext4 (or later, should such appear).
But before Ext4, those bit positions would have been unspecified so it is entirely possible Humax did what they wanted with them, or indeed the CF, without repercussions to an Ext3 system.

The morals of the story are to never over-interpret reported stats (if you spot what might be a problem but you're not sure, do nothing without asking advice first), and never use software tools that were not designed for the system in question.
 
As above: no. You panicked due to not understanding what normal is.
The reported seek error rate is about 0.2%. I am not sure how typical that result is. To be fair to the OP, the raw number in the smart table is a composite of errors and total seeks and to know what the raw value means requires these two variables to be extracted by converting this value to hexadecimal and then converting both numbers back to decimal. A small raw number could correspond to the same rate as a much larger one.
 
The values are a composite of two values (number of seek errors plus total number of seeks) and can only be understood by converting them to hex, extracting both values and then converting from hex to decimal. For example, a seek error rate of 31715 corresponds to 0x0007BE3 which is 7 errors from BE3/ 3043 seeks.
If the link above is correct it is a 48 bit field split into 16 bit seek errors plus 32 bit seeks. In this example case it would be 0x000000007BE3 which is 0 errors from 31715 seeks.
 
Thanks for the info Black Hole
never use software tools that were not designed for the system in question.
I honestly though I was using the same tool on a Humax vs Ubuntu 16.04 all beit a slightly newer version of the e2fsck program. I also was wanting a second opinion given that e2fsck on the humax couldn't get over an LBA0 error I had on my old HDD (I was replied to on that saying to do a security reset, which I guess would have lost all data - work in progress - I have yet to see if the PC version can resolve the LBA0 issue before I do that, but I'm not going to do that until I know that my recordings are safely on my new HDD and it's working).

So, my objective is to ensure the new drive is fit for purpose ultimately. As mentioned above, I've agreed to put the new drive back in and reformat the partitions and then reinstall etc. I'll then take it out again, plug it back into the PC and copy the video data back over as it will be alot quicker doing it like this (and I will not run e2fsck on it!) - I'll just trust what the humax has done in preparing the disc it has done it right. As no one has stated that copying the data over in this way would be a problem with permissions etc. I will therefore take this that this will be ok. So, that part of my query is done and dusted - thanks for all your replies.

The other part of my query relates to understanding if there is likely to be any compatibility issues when disc checking in the humax vs connected to a PC (ubuntu 16.04 and version 1.45.5 of e2fsck). Ok, the ubuntu found some errors which it fixed. Is fixing these flags going to cause something that might mean the normal humax based e2fsck program will throw a wobbly and not be able to fix / resolve any bad sectors or incorrect journals / indexes etc. in the future? (Perhaps you don't know and no one had documented this query or scenario until now and I'm finding myself to be the test dummy!)

I'm asking this question because (as mentioned above) I have my old humax HDD still to check out and when trying to run e2fsck on the humax, it found an error at LBA0 and couldn't fix it - it just kept looping round and round. The drive still worked just about but the box started rebooting every couple of minutes and you could hear the heads on the drive struggling to read or write (cyclic redundancy) so guessing there was more than one problem and not just LBA0 as infact I've been living with that for sometime now.

Thanks

Rodp
 
Back
Top