brand new HDD but EXTENTS_FL errors

[rodp]

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!



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.

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 Status	PASSED
Device Model	ST2000VX008-2E3164
Serial Number	Z529LXK4
LU WWN Device Id	5 000c50 0c499e22f
Firmware Version	CV12
User Capacity	2,000,398,934,016 bytes [2.00 TB]
Sector Sizes	512 bytes logical, 4096 bytes physical
Rotation Rate	5900 rpm
Form Factor	3.5 inches
ATA Version is	ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is	SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is	Sun Sep 6 12:36:32 2020 BST
SMART support is	Available - device has SMART capability.
SMART support is	Enabled

Attributes

ID	Name	Flags	Raw Value	Value	Worst	Threshold	Life Left	Notes
1	Raw_Read_Error_Rate	POSR--	421296	100	100	006		-
3	Spin_Up_Time	PO----	0	099	099	000		-
4	Start_Stop_Count	-O--CK	3	100	100	020	100%	-
5	Reallocated_Sector_Ct	PO--CK	0	100	100	010	100%	-
7	Seek_Error_Rate	POSR--	32048	100	253	030		-
9	Power_On_Hours	-O--CK	0	100	100	000	100%	-
10	Spin_Retry_Count	PO--C-	0	100	100	097	100%	-
12	Power_Cycle_Count	-O--CK	3	100	100	020	100%	-
184	End-to-End_Error	-O--CK	0	100	100	099		-
187	Reported_Uncorrect	-O--CK	0	100	100	000		-
188	Command_Timeout	-O--CK	0	100	100	000		-
189	High_Fly_Writes	-O-RCK	0	100	100	000		-
190	Airflow_Temperature_Cel	-O---K	30	070 (30°C)	070 (30°C)	045 (55°C)		-
191	G-Sense_Error_Rate	-O--CK	0	100	100	000		-
192	Power-Off_Retract_Count	-O--CK	3	100	100	000	100%	-
193	Load_Cycle_Count	-O--CK	3	100	100	000	100%	-
194	Temperature_Celsius	-O---K	30	030	040	000		-
197	Current_Pending_Sector	-O--C-	0	100	100	000		-
198	Offline_Uncorrectable	----C-	0	100	100	000		-
199	UDMA_CRC_Error_Count	-OSRCK	0	200	200	000		-

Self-test logs

No.	Description	Status	Remaining	When	First Error LBA
# 1	Short offline	Completed without error	00%	0	-
# 2	Short offline	Completed without error	00%	0	-

Acknowledge any current disk faults.

Here's a pic of the hdd


-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

 

[MontysEvilTwin]

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.

 

[prpr]

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:

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.

 

[rodp]

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

 

[Black Hole]

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.

 

[rodp]

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.

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

 

[/df]

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:

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

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.

 

[rodp]

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

 

[prpr]

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.

 

[Black Hole]

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.

 

[everthewatcher]

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.

 

[Black Hole]

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.

 

[MontysEvilTwin]

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.

 

[/df]

...
-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:

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.

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.

 

[MontysEvilTwin]

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.

 

[Black Hole]

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.

 

[MontysEvilTwin]

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.

 

[Black Hole]

I am not sure how typical that result is.

Neither am I, but I'm not going to panic about it.

 

[xyz321]

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.

 

[rodp]

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