Smart Recovery Daemon
Jermale Kunstler
How can I reset the SMART results so it does not register previous results. My reason is that I was testing the hard drives closed together on a closed case. This made one of the HDD fail the Airflow Temperature reading.
After opening the case up (Which lowered the Temp of all drives 10 degrees Celsius in 5 minutes) and then separating the drives a bit more (3 less degrees) All results were good but since the Airflow reading failed in a previous reading, it always shows as failing.
Actually there is a way to reset S.M.A.R.T. data. You only need simple rs232 to usb converter (uart to ttl) and a few cables attached to hdds diagnostic interfaces. (it's on the right side of sata port, 5 or 4 pins) You must conect RX TX and GND cables (and power cable of course :D) then power on HDD and connect to it with putty or hyperterminal (linux can connect with it's own terminal i guess)for example for seagate drives:for 7200.10 and older baud rate is 9600for 7200.11 and newer is 38400
That's why it says "failed in the past", not "failing now": you did just barely touch the max-temp threshold. Note the attribute display shows "normalized: 50, threshold: 45, worst: 45". (These are 0..200 normalized values like for any other attribute, not raw Celsius temps.)
A better SMART software UI would show you the current and max-ever temp. e.g.
smartctl -a /dev/sda or smartctl -x /dev/sda (-x prints all available SMART and non-SMART data it can get from the drive, including a temperature history log if the drive has one, with an ASCII bar graph.)
The software you're using looks like it's only showing the current temp, which is slightly below the threshold, but it's not going to hide the fact that the drive was out-of-spec at some point in the past.
You could certainly justify ignoring that momentary high-temperature, if you really did correct it in minutes. But you won't (or shouldn't) ever be able to make the drive itself lie about the fact that it was over its rated max temp for some time, and thus the attribute did fail in the past.
You can configure smartd to ignore any given attribute so you can still get a useful notification if anything else crosses a threshold into officially-failing territory.: smartd.conf(5) says:
-i ID [ATA only] Ignore device Attribute number ID when checking for failure of Usage Attributes. ID must be a decimal integer in the range from 1 to 255. This Directive modifies the behavior of the '-f' Directive and has no effect without it.
This is useful, for example, if you have a very old disk and don't want to keep getting messages about the hours-on-lifetime Attribute (usually Attribute 9) failing. This Directive may appear multiple times for a single device, if you want to ignore multiple Attributes.
If you drive has these extended attributes, you can show someone that the time spent outside of allowed temp was very short (if that's the case). Presumably if you were going to modify the SMART data, you'd just have done that and removed any mention of it being out-of-range ever, but obviously you can't 100% trust any data from a 2nd-hand drive that someone's trying to sell you.
A stupid thing about SMART is that it permanently stores one time transient things that did no damage at all. I had a drive that recorded a power failure in its SMART and forever after the computer would warn about the SMART data indicating "impending drive failure" simply because of a power outage caused by someone driving into a power pole. No idea why that specific power failure got recorded by SMART when I've had many computers and many drives experience power failures without recording them as an "error".
Hard drives have spare space for recovery reasons. The recovery happens automatically. Recovery tools only remap physically bad sectors to this spare space. Once remapped, when a read or write occur to a bad sector, the drive turns the access to the spare space, and hides the error.
Many of the unrecoverable drives that we receive, have been KILLED by such utilities mostly for the simple reason that a failing drive, needing to be kept TURNED OFF, has been massacred by an absolutely USELESS repair (killing) process
I am using router Totolink X5000R with openwrt 21.02
I have a problem when my TV (Samsung SmartTV) connect to wifi network from router. I turn off the TV for a few hours after using wifi network normarlly and then turn on again, then I get a message that can't connect to the internet on the TV (The TV still connect to the router). Other device still connect to internet as normal.
I cheked on my router via Luci web or logread, then still see the IP that be assigned to TV. But I can not ping to that IP from router
I don't understand this point. I enabled both of software flow offloading and hardware flow offloading on my router. I don't know how it is affecting on this problem.
Can you explain to me about this?
Just a thought....I wonder if setting the DHCP lease time to a lower value like say 1 hour (default 12 hours) would help refresh the TV's wifi connection?
-> I check logread from router and see the log disconected and connected again periodically.
That was a while ago for me. Have a single 2.4 IT device which after a week on OpenWRT the devices wifi got lost. The device had to be offboarded and reonboarded to fix the Wifi issue, but after a week issue came back.
Very difficult to track issues on such rare occurences. I have some doubts about the IoT sleep mode theory, as to why would a device suddenly go to sleep after 3 weeks? It rather feels like some kind of counter or so on the Wifi AP side somehow overflowing into a value range that the IoT cannot process. But I am a layman argumenting here, not a coder.
Time fast forward: a few weeks ago, my environment has changed: i have removed the timer and now have a dedicated x86 router. The dir-1960 is now operating in access point mode. Furthermore I have a mobile app running that regularly polls data from the IoT, so it also likely goes less into the suspected sleep mode. The issue has not yet reappeared since then. Could be the dir-1960 no longer acting as router or the more frequent polling of the IoT.
You should definitely test variations of the 3 parameters and keep note, what happens. None of the 3 parametrs break anything and can be set back to default.
You could also try latest snapshot, if recovery on your device feels easy.
My problem is seem be same to you. I checked log on my router, then see that my TV periodically disconnect from the router (is running openwrt) when it is in sleep mode. Specifically, after turning off the TV about 5 minutes, TV is disconnected from the wifi network. And after 20 minutes, it will ask to connect again. This keeps repeating when my TV is in sleep mode. I suspect that when I turn on TV (while it is disconnected state), something happen. I also check other smart TVs, then see there are no devices behave like that when they are in sleep mode. Seem be openwrt is having problem with the devices have the such sleep mode. I will search more information about such sleep mode on devices.
Maybe it's the TV's wifi is not handling sleep mode correctly. You could try manually updating the TV firmware. You could also try deleting third party apps that may be conflicting or crashing the TV wifi card.
I also loose my mind with the Samsung Smart TV.
On old Samsung tv, there was a bug, that only WPA2 TKIP encryption was working well, other was failing.
On new tv, I tried same - create a dedicated network (MyNetwork_4A) for the tv, that does not have any configuration with 802.11r/k/v/w and use just TKIP and nothing. The option disassoc_low_ack set to 0 also does not work.
One day, I disabled other wireless networks and I just tried to enable WPS and it seems to work. Then I come back to many SSIDs and it stops working. After few restarts, it starts, but after few days stops.
I just share my config, but it might not be helpful.
Soon I will add some log messages.
Hi,
Issue is not in the wireless configuration, but... in irqbalance. I did not dig yet, what would be proper configuration, but so far, I know that Xiaomi 4A Gigabit version with irqbalance and Samsung TV (QE55Q67B) is no a good buddies.
So if someone have issue with smart TV and router/dumb ap, I recommend to try to disable irqbalance (if its installed).
Edit:
After a while, it seems that the problem is...in option country "PL". I changed the country to US + added option noscan '1' and it works well. Finally I don't have any issue with MT7621 and Samsung TV.
When the Disk Drill data recovery tool is installed on your Mac, it includes the cfbackd daemon. This daemon is responsible for all of the aspects of the software that require constant disk communication and the ability to send user notifications.
PostgreSQL databases require periodic maintenance known as vacuuming. For many installations, it is sufficient to let vacuuming be performed by the autovacuum daemon, which is described in Section 25.1.6. You might need to adjust the autovacuuming parameters described there to obtain best results for your situation. Some database administrators will want to supplement or replace the daemon's activities with manually-managed VACUUM commands, which typically are executed according to a schedule by cron or Task Scheduler scripts. To set up manually-managed vacuuming properly, it is essential to understand the issues discussed in the next few subsections. Administrators who rely on autovacuuming may still wish to skim this material to help them understand and adjust autovacuuming.
There are two variants of VACUUM: standard VACUUM and VACUUM FULL. VACUUM FULL can reclaim more disk space but runs much more slowly. Also, the standard form of VACUUM can run in parallel with production database operations. (Commands such as SELECT, INSERT, UPDATE, and DELETE will continue to function normally, though you will not be able to modify the definition of a table with commands such as ALTER TABLE while it is being vacuumed.) VACUUM FULL requires an ACCESS EXCLUSIVE lock on the table it is working on, and therefore cannot be done in parallel with other use of the table. Generally, therefore, administrators should strive to use standard VACUUM and avoid VACUUM FULL.
c80f0f1006