Read Onley filesystem!

[ALT-FUser]

Hi,
Stopped all service umounted the disk, and checked

[root@dns325]# fsck.ext4 -f /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
/dev/md0: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md0: 24848/183083008 files (3.8% non-contiguous), 322456602/732305792 blocks

But after restarting services, got again RO files system on /dev/md0.Any Idea how to fix this issue?

Thanks in advance!

[João Cardoso]

On Thursday, 1 March 2018 11:11:59 UTC, ALT-FUser wrote:

Hi,
Stopped all service umounted the disk, and checked

Why did you do that before first knowing *why* is was in RO mode? No Status page message? No log watching?

Have you see if in Disk->Filesystem if it was set to be mounted "ro"?

[ALT-FUser]

Hi,
It was suddenly moved to RO after few time restart and FSCK is again RW. I have 2 harddrive 1Tb+2TB and formatted both in ext4 in one JBOD file system. Thanks for great support here!


PS: sourceforge is down almost since 15FEB can't download any files from ALT-F repos

[ALT-FUser]

UPDATE:
The download links are changed from sourceforge to:

https://jaist.dl.sourceforge.net/project/alt-f/pkgs/stable
https://jaist.dl.sourceforge.net/project/alt-f/pkgs/unstable

[Andrej A.]

Hi there! I have same problem for a few weeks. I have dns-323 with Alt-f 1.0 Probably after upgrade Transmission from stock version, FS going to RO-mode. In syslog I have this errors:

kernel: blk_update_request: I/O error, dev sda, sector 207408000
May 10 14:11:38 kernel: ata1.00: exception Emask 0x0 SAct 0x100000 SErr 0x0 action 0x6
May 10 14:11:38 kernel: ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
May 10 14:11:38 kernel: ata1.00: cmd 60/08:a0:78:cb:5c/00:00:0c:00:00/40 tag 20 ncq 4096 in
May 10 14:11:38 kernel:          res 41/40:00:78:cb:5c/00:00:0c:00:00/40 Emask 0x409 (media error)
May 10 14:11:38 kernel: ata1: hard resetting link
May 10 14:11:39 kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May 10 14:11:39 kernel: ata1.00: configured for UDMA/133
May 10 14:11:39 kernel: sd 0:0:0:0: [sda] tag#20 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
May 10 14:11:39 kernel: sd 0:0:0:0: [sda] tag#20 Sense Key : 0x3 [current] [descriptor]
May 10 14:11:39 kernel: sd 0:0:0:0: [sda] tag#20 ASC=0x11 ASCQ=0x4
May 10 14:11:39 kernel: sd 0:0:0:0: [sda] tag#20 CDB: opcode=0x28 28 00 0c 5c cb 78 00 00 08 00
May 10 14:11:39 kernel: blk_update_request: I/O error, dev sda, sector 207407992
May 10 14:11:39 kernel: ata1: EH complete
May 10 14:11:42 kernel: ata1.00: exception Emask 0x0 SAct 0x8000 SErr 0x0 action 0x6
May 10 14:11:42 kernel: ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
May 10 14:11:42 kernel: ata1.00: cmd 60/08:78:78:cb:5c/00:00:0c:00:00/40 tag 15 ncq 4096 in
May 10 14:11:42 kernel:          res 41/40:00:78:cb:5c/00:00:0c:00:00/40 Emask 0x409 (media error)

And I have this problem if I started checking torrent in Transmission. After reboot problem is gone for 3-4 days, but after that the problem appears again.
I can't use my dns-323 normally - torrents are corrupted on download, and I need to re-download it a few times
Help me to resolve this problem!

[Paulo Elifaz Andrielli]

I had this problem a long time ago, due power outage at home. A sudden shutdown on NAS, made everything in "read only" mode.

This thread should help you:

https://groups.google.com/forum/#!searchin/alt-f/read$20only%7Csort:date/alt-f/EgvOXxp814s/JV38I7fbAAAJ

[]´s

Paulo

--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/alt-f.
For more options, visit https://groups.google.com/d/optout.

[Andrej A.]

Unfortunately, it's a completely different problem. In my case transmission create a large load, as a result of which the disk is remounted to the RO mode. Try it yourself - you can run checking loaded torrent in Transmission -after a few minutes the check will be stopped with an error, and the disk is remounted to the RO-mode. In addition, if the Transmission has a lot of torrents (50 or more), the disk can also be remounted in the RO mode a few hours after the reboot. While loading a big torrent , there may be a similar problem.
I checked the SMART - HDD is OK.

четверг, 10 мая 2018 г., 16:54:45 UTC+3 пользователь Paulo Elifaz Andrielli написал:

To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.

[João Cardoso]

On Thursday, 10 May 2018 17:32:48 UTC+1, Andrej A. wrote:

Unfortunately, it's a completely different problem. In my case transmission create a large load, as a result of which the disk is remounted to the RO mode. Try it yourself - you can run checking loaded torrent in Transmission -after a few minutes the check will be stopped with an error, and the disk is remounted to the RO-mode. In addition, if the Transmission has a lot of torrents (50 or more), the disk can also be remounted in the RO mode a few hours after the reboot. While loading a big torrent , there may be a similar problem.
I checked the SMART - HDD is OK.

But the syslog errors indicate a disk problem. Have you run a smart short (and if successful a long) test? -- Without transmission running.

The general SMART health status might be OK, but that does not means that there are no issues. Post the SMART log after running the tests.

[Andrej A.]

OK, here's a result of short test:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   196   196   051    Pre-fail  Always       -       1439
  3 Spin_Up_Time            0x0027   171   170   021    Pre-fail  Always       -       6433
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       854
  5 Reallocated_Sector_Ct   0x0033   160   160   140    Pre-fail  Always       -       1710
  7 Seek_Error_Rate         0x002e   200   181   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   096   096   000    Old_age   Always       -       3259
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       23
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       111
193 Load_Cycle_Count        0x0032   176   176   000    Old_age   Always       -       74175
194 Temperature_Celsius     0x0022   113   111   000    Old_age   Always       -       37
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       597
197 Current_Pending_Sector  0x0032   192   191   000    Old_age   Always       -       2871
198 Offline_Uncorrectable   0x0030   197   196   000    Old_age   Offline      -       977
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   188   000    Old_age   Offline      -       2

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       10%      3259         202841240
# 2  Short offline       Completed: read failure       10%      3246         202841240
# 3  Short offline       Completed: read failure       10%      3221         202841240
# 4  Short offline       Completed: read failure       10%      3195         202841240
# 5  Short offline       Completed: read failure       10%      3173         202841240
# 6  Extended offline    Completed: read failure       90%      3147         143928264
# 7  Short offline       Completed: read failure       10%      3123         202841240
# 8  Short offline       Completed without error       00%      3115         -
# 9  Short offline       Completed: read failure       10%      3091         202841240
#10  Short offline       Completed: read failure       10%      3052         202841240
#11  Short offline       Completed: read failure       10%      3032         202841240
#12  Short offline       Completed: read failure       10%      3005         202841240
#13  Extended offline    Completed: read failure       90%      2982         168997552
#14  Short offline       Completed: read failure       10%      2959         202841240
#15  Short offline       Completed: read failure       10%      2933         202841240
#16  Short offline       Completed: read failure       10%      2911         202841240
#17  Short offline       Completed: read failure       10%      2888         202841240
#18  Short offline       Completed: read failure       10%      2862         202841240
#19  Short offline       Completed: read failure       10%      2836         202841240
#20  Extended offline    Completed: read failure       90%      2813         168997552
#21  Short offline       Completed: read failure       10%      2767         207221120

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Your opinion?


четверг, 10 мая 2018 г., 20:01:29 UTC+3 пользователь João Cardoso написал:

[João Cardoso]

In my opinion the disk has problems.

Most (but one) SMART tests fails reading data at around  LBA 202841240 (~96GB)

The reallocated sector count is too high (Reallocated_Sector_Ct   0x0033   160   160   140    Pre-fail  Always       -       1710) and current value (160) is approaching the pre-fail threshold (140). This means that bad sectors were detected (1710) and remapped to spare sectors; when the spare area exhausts the disk will fail.

There are too many sectors read errors, 2871, and them can only be remapped to the spare area (described above) when explicitly written, as that mean potential data loss (Current_Pending_Sector  0x0032   192   191   000    Old_age   Always       -       2871).

The reallocated event count is also high: Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       597; besides other relevant parameters, that also shows "high" values.

The disk is relatively new, only 3259 hours, the equivalent of 135 (always on) days, so I would backup its data, put the disk on a PC, run the manufacturer test programs and eventually ask for a RMA. Some disk manufacturers (Seagate, namely) use some of the SMART IDs for its own usage, so my/the SMART parameter interpretation  might be wrong, so use the manufacturer test programs.

For comparison, on a 1TB Samsung with 36564 power-on hours (10x "older" that yours), there are only 145 reallocated sector count, and on a 2TB WD with 26308 hours there are zero (those disks are used only used for backups, not intensive continuous read/writes as Transmission does). On these two disks all other relevant "raw" values are zero or close to it.

Something that is not directly related, only worrying, is the "Load_Cycle_Count   ...   74175", which is somehow "high". Do you have a low spindown timeout value? Puting the drive to sleep just to wake it up soon just stress the disk. The default value is 20 minutes, but that is use-case dependant.

For comparison, on my 36564 hours disk the count is only 14611 -- a 10x "older" disk with 5x less head load cycle counts

[Andrej A.]

Thanks for the very detailed answer. Now it's clear what the problem is. This disc is almost new, and I was sure that he was fine.

пятница, 11 мая 2018 г., 3:51:36 UTC+3 пользователь João Cardoso написал: