HD filesystem integrity issues

HD filesystem integrity issues

[Felix Miata]

http://fm.no-ip.com/Tmp/Linux/dmsgAZBHD201401.txt is dmesg from a STB running 
2.6.15-sigma MIPS. In it I noticed the run e2fsck recommendation for (SATA 
"1.2TB") hdb1, so attempted to umount it and do just that, as the last time 
done would have been in excess of 3 months ago. Before doing so, I decided to 
e2fsck another HD available via USB 2.0 as "2TB" sda1, which began thus via 
telnet while the STB was "asleep":

$ e2fsck /dev/sda1
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Group descriptors look bad... trying backup blocks...
<volumelabel> was not cleanly unmounted, check forced.
Reading 1 blocks starting at 1027
Reading 1 blocks starting at 1288...
and ended thus:
...
Reading 1 blocks starting at 343
Pass 1: Checking inodes, blocks, and sizes
Killed
$

I was able to discover nothing to indicate what precipitated the kill. I 
proceeded to umount hdb1, and then:

$ e2fsck /dev/hdb1
e2fsck 1.41.9 (22-Aug-2009)
Killed
$

Again I found nothing to indicate what precipitated the kill.

I speculate this may have something to do with hardware and/or configuration 
limitation(s). The sketchy manual written in English by an obviously 
non-native English writer/speaker claims an internal HD size limitation of 
1TB. 1TB is the apparent maximum size the device is able to self-prepare for 
use on physical HT installation (1:partition; and 2:install ext2 filesystem).

I tested the STB briefly when new with a 1TB before installing a 2TB HD 
prepared on a Linux PC with a "full" (starting @S2048) device ext2 partition. 
I used it probably some months before deciding the 1TB limit might have some 
real justification, removed it, and installed a 1TB. I used the 1TB for quite 
some time before freespace began to drop under 5%, upon which I decided to 
try a size in between 1TB and 2TB. 10 months ago on a 1.5TB Samsung HD155UI 
(aka Seagate Green ST1500DL004; not sure whether 512e but I think yes) I 
created 2 partitions, one 1.2TB ext2, and the remainder type ext2, but 
without installing any filesystem on it. This is the 1.2TB hdb1 for which the 
second Killed appeared.

I removed the 1.5TB "hdb" from the STB and attached it via eSATA to a Linux 
PC to try again e2fsck, with the following result:
# e2fsck -v /dev/sdb1
e2fsck 1.42.6 (21-Sept-2012)
<volumelabel> was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks and sizes
Error reading block 12419091 (Attempt to read block from filesystem resulted 
in short read) while getting next inode from scan.
  Ignore error<y>? yes
Force rewrite<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

<volumelabel>: ***** FILE SYSTEM WAS MODIFIED *****

339 inodes used (0.00%, out of 80535552)
2 non-contiguous files(0.6%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 288/285/121
300564929 blocks used (93.31%, out of 322122496)
         0 bad blocks
       276 large files
       314 regular files
        15 directories
         0 character device files
         0 block device files
         0 fifos
         0 links
         1 symbolic link (1 fast symbolic link)
         0 sockets
----------
       330 files
#

I've now restored the 1.5TB HD to the STB.
$ uname -a
Linux AZBox 2.6.15-sigma #138 PREEMPT Thu Jan 22 21:35:07 KST 2009 mips unknown
$ free
               total         used         free       shared      buffers
   Mem:       100484        96360         4124            0         1520
  Swap:            0            0            0

Googling "Attempt to read block from filesystem resulted in short read" 
produced a lot of hits, of which little seemed to be of any use. The e2fsck 
man page seems rather unhelpful as well. The STB has a rather rudimentary 
toolset in the form of busybox v1.00, producing a lot of command not founds 
trying to perform shell tasks common on a Linux PC (e.g. smart, shutdown, 
tune2fs), and its command history does not survive reboots. Neither /boot nor 
/proc/config* exist.

1-Is my 1.2TB partition now most likely OK?

2-Is the meager 100484 of total RAM available to the 2.6.15 kernel likely the 
reason or heavily related to the manual's 1TB size "limit"?

3-Is the meager 100484 of total RAM likely the reason for the e2fsck kills?

4-Any suggestions?

5-Is this the wrong place to have asked all this? If so, where better?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: HD filesystem integrity issues

[Robert Hancock]

On 01/01/2014 04:43 PM, Felix Miata wrote:
> http://fm.no-ip.com/Tmp/Linux/dmsgAZBHD201401.txt is dmesg from a STB
> running 2.6.15-sigma MIPS. In it I noticed the run e2fsck recommendation
> for (SATA "1.2TB") hdb1, so attempted to umount it and do just that, as
> the last time done would have been in excess of 3 months ago. Before
> doing so, I decided to e2fsck another HD available via USB 2.0 as "2TB"
> sda1, which began thus via telnet while the STB was "asleep":
>
> $ e2fsck /dev/sda1
> e2fsck 1.41.9 (22-Aug-2009)
> e2fsck: Group descriptors look bad... trying backup blocks...
> <volumelabel> was not cleanly unmounted, check forced.
> Reading 1 blocks starting at 1027
> Reading 1 blocks starting at 1288...
> and ended thus:
> ...
> Reading 1 blocks starting at 343
> Pass 1: Checking inodes, blocks, and sizes
> Killed
> $

Have you checked the dmesg output? There would likely be some indication 
of what happened. Given that this thing only has 100MB or so of memory, 
it seems quite likely that the out-of-memory killer kicked in.

This isn't really related to linux-ide, the main Linux kernel mailing 
list would likely be more suitable.

>
> I was able to discover nothing to indicate what precipitated the kill. I
> proceeded to umount hdb1, and then:
>
> $ e2fsck /dev/hdb1
> e2fsck 1.41.9 (22-Aug-2009)
> Killed
> $
>
> Again I found nothing to indicate what precipitated the kill.
>
> I speculate this may have something to do with hardware and/or
> configuration limitation(s). The sketchy manual written in English by an
> obviously non-native English writer/speaker claims an internal HD size
> limitation of 1TB. 1TB is the apparent maximum size the device is able
> to self-prepare for use on physical HT installation (1:partition; and
> 2:install ext2 filesystem).
>
> I tested the STB briefly when new with a 1TB before installing a 2TB HD
> prepared on a Linux PC with a "full" (starting @S2048) device ext2
> partition. I used it probably some months before deciding the 1TB limit
> might have some real justification, removed it, and installed a 1TB. I
> used the 1TB for quite some time before freespace began to drop under
> 5%, upon which I decided to try a size in between 1TB and 2TB. 10 months
> ago on a 1.5TB Samsung HD155UI (aka Seagate Green ST1500DL004; not sure
> whether 512e but I think yes) I created 2 partitions, one 1.2TB ext2,
> and the remainder type ext2, but without installing any filesystem on
> it. This is the 1.2TB hdb1 for which the second Killed appeared.
>
> I removed the 1.5TB "hdb" from the STB and attached it via eSATA to a
> Linux PC to try again e2fsck, with the following result:
> # e2fsck -v /dev/sdb1
> e2fsck 1.42.6 (21-Sept-2012)
> <volumelabel> was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks and sizes
> Error reading block 12419091 (Attempt to read block from filesystem
> resulted in short read) while getting next inode from scan.
>   Ignore error<y>? yes
> Force rewrite<y>? yes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 3A: Optimizing directories
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
>
> <volumelabel>: ***** FILE SYSTEM WAS MODIFIED *****
>
> 339 inodes used (0.00%, out of 80535552)
> 2 non-contiguous files(0.6%)
> 0 non-contiguous directories (0.0%)
> # of inodes with ind/dind/tind blocks: 288/285/121
> 300564929 blocks used (93.31%, out of 322122496)
>          0 bad blocks
>        276 large files
>        314 regular files
>         15 directories
>          0 character device files
>          0 block device files
>          0 fifos
>          0 links
>          1 symbolic link (1 fast symbolic link)
>          0 sockets
> ----------
>        330 files
> #
>
> I've now restored the 1.5TB HD to the STB.
> $ uname -a
> Linux AZBox 2.6.15-sigma #138 PREEMPT Thu Jan 22 21:35:07 KST 2009 mips
> unknown
> $ free
>                total         used         free       shared      buffers
>    Mem:       100484        96360         4124            0         1520
>   Swap:            0            0            0
>
> Googling "Attempt to read block from filesystem resulted in short read"
> produced a lot of hits, of which little seemed to be of any use. The
> e2fsck man page seems rather unhelpful as well. The STB has a rather
> rudimentary toolset in the form of busybox v1.00, producing a lot of
> command not founds trying to perform shell tasks common on a Linux PC
> (e.g. smart, shutdown, tune2fs), and its command history does not
> survive reboots. Neither /boot nor /proc/config* exist.
>
> 1-Is my 1.2TB partition now most likely OK?
>
> 2-Is the meager 100484 of total RAM available to the 2.6.15 kernel
> likely the reason or heavily related to the manual's 1TB size "limit"?
>
> 3-Is the meager 100484 of total RAM likely the reason for the e2fsck kills?
>
> 4-Any suggestions?
>
> 5-Is this the wrong place to have asked all this? If so, where better?

Re: HD filesystem integrity issues

[Felix Miata]

On 2014-01-02 21:04 (GMT-0600) Robert Hancock composed:

> Felix Miata wrote:

>> http://fm.no-ip.com/Tmp/Linux/dmsgAZBHD201401.txt is dmesg from a STB

> Have you checked the dmesg output? There would likely be some indication
> of what happened.

Checked for what exactly? That's why I gave it to the list to look at. The 
only thing I recognized as a problem indication was "running e2fsck is 
recommended".

> Given that this thing only has 100MB or so of memory,
> it seems quite likely that the out-of-memory killer kicked in.

As another responder replied within minutes of my post, and you seem to have 
confirmed. It's what I suspected, but I was able to find any way to confirm 
other than to ask somewhere outside the device's so-called support forum.

> This isn't really related to linux-ide, the main Linux kernel mailing
> list would likely be more suitable.

I was thinking a generic filesystem list, but don't know of one about 
ext2/3/4, and thought this better than a high traffic generic list.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: HD filesystem integrity issues

[Robert Hancock]

On 01/02/2014 09:34 PM, Felix Miata wrote:
> On 2014-01-02 21:04 (GMT-0600) Robert Hancock composed:
>
>> Felix Miata wrote:
>
>>> http://fm.no-ip.com/Tmp/Linux/dmsgAZBHD201401.txt is dmesg from a STB
>
>> Have you checked the dmesg output? There would likely be some indication
>> of what happened.
>
> Checked for what exactly? That's why I gave it to the list to look at.
> The only thing I recognized as a problem indication was "running e2fsck
> is recommended".

Is that output from after attempting to run e2fsck? It doesn't appear 
that in this output it has even finished recognizing the USB hard drive 
yet. If the OOM killer kicked in, there should be a bunch of output in 
dmesg about it.

>
>> Given that this thing only has 100MB or so of memory,
>> it seems quite likely that the out-of-memory killer kicked in.
>
> As another responder replied within minutes of my post, and you seem to
> have confirmed. It's what I suspected, but I was able to find any way to
> confirm other than to ask somewhere outside the device's so-called
> support forum.
>
>> This isn't really related to linux-ide, the main Linux kernel mailing
>> list would likely be more suitable.
>
> I was thinking a generic filesystem list, but don't know of one about
> ext2/3/4, and thought this better than a high traffic generic list.