Custom Query (1494 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (421 - 423 of 1494)

Ticket Resolution Summary Owner Reporter
#658 wontfix Many (long) HDD default timeouts cause data loss or corruption (silent controller resets) Ch.Ris
Description

The default error correction timeouts of many HDDs cause data loss or corruption (so long or disabled that the controller hard resets the drives instead of only marking single blocks as bad). And the smartctl utility is the place to adjust the "scterc" timeouts of HDDs.

Please ship the provided scripts and default udev rule with the smartmontools package, so that they try to configure safe timeouts, depending on the drives capabilities, usage and configuration.

The problem with mismatching default timeouts surfaced through repeated reports about drives being droped from raid arrays, and about a high rate of unrecoverable errors occuring during raid-reconstruction, on the linux-raid mailinglist, but the problem is not limited to redundant disk setups. Many experienced "disk failures" are probably just failures due to mismatched recovery timeout settings.

(The scripts have been posted upstream without response, but it is still a distro resposibility to ensure that installations will have safe defaults. Note that the provided udev rules specific to mdadm are only to be included in the mdadm package.)

RATIONALE

The error recovery (ERC) time of a drive *must* be shorter than the controller timeout.

Otherwise read errors will cause controller resets, leading to direct data loss or, if it is a redundant disk, loss of redundancy and a very high probability of another read error and data loss when re-establishing the redundancy.

If a drive does not support adjusting its ERC timeout, the controller timeout must be increased above the drive's maximal error recovery time. If you don't want that kind of long device timeout, you should look for a drive with SCT ERC timeout support. (smartctl -l scterc /dev/...)

The files are attached at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780162

#659 fixed "update-smart-drivedb" uses old sourceforge HTTP link Christian Franke ackackack
Description

When curl is used in the drivedb update script it does not follow the redirect as given by sourceforge for http to https

Curl can be told to follow redirects with the -L option

Here is a simple patch that seems to solve this issue:

@@ -77,7 +77,7 @@
 for t in $os_dltools; do
   if which $t >/dev/null 2>/dev/null; then
     case $t in
-      curl)  DOWNLOAD="curl ${q:+-s }"'-f -o "$DEST.new" "$SRC"' ;;
+      curl)  DOWNLOAD="curl -L ${q:+-s }"'-f -o "$DEST.new" "$SRC"' ;;
       lynx)  DOWNLOAD='lynx -source "$SRC" >"$DEST.new"' ;;
       wget)  DOWNLOAD="wget $q"'-O "$DEST.new" "$SRC"' ;;
       fetch) DOWNLOAD='fetch -o "$DEST.new" "$SRC"' ;; # FreeBSD

As an alternative the URL for the updates could be modified to look to https instead of http:

@@ -40,7 +40,7 @@
 SMARTCTL="$sbindir/smartctl"

 # Download URL for sourceforge code browser
-SRCEXPR='http://sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw'
+SRCEXPR='https://sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw'

 # Parse options
 q="-q "

#660 fixed Add to database - OWC Aura Pro Mick Russom
Description

Add to the database - OWC Aura Pro

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.