Custom Query (1494 matches)
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) | ||
| 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 | ||
| 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 | ||
| Description |
Add to the database - OWC Aura Pro |
|||
