Menu
▾
▴
smartmontools-support
|
From: Bruce A. <ba...@gr...> - 2008-01-07 15:02:21
|
Hi Dan, I think that this is still an issue. One could add a smartmontools feature to do self-tests some number of hours after the LAST self test. But for this to work the self test log timestamps and the power on time SMART attribute both must be reliable and work properly. MANY hard disks have problems with these, as can be confirmed by looking in the support mailing list and in the smartmontools FAQ. So I have never implemented this. Other suggestions are welcome!! Cheers, Bruce On Sun, 30 Dec 2007, ro...@vo... wrote: > Hallo, > > I have smartmontools installed on laptop, but sheduling options in smartd.conf > are not very "laptop friendly". In discussion, however, I found post > from 16.04.2004 that doing sleduling in a more clever way (like test > after 7 days of run ...) is not possible due to faulty firmware and/or > the danger of self-test high frequency if laptops are in sleep state > most of the time. > > I want to ask, if the reasons are still topical, or if there is a plan > to enhance sheduling support for laptops. Was any solution proposed? > There are more and more laptops all around :-) > > Best regards, > Dan > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
|
From: <ro...@vo...> - 2008-01-08 10:26:40
|
Hi, I was little bit afraid of it ;-) It makes me little bit worry about what all is wrong in disks - <irony>it is so hard or expensive to do it in right way? Suppose, no-one knows ... </irony> Well, what about implement is as "not secure" future (by default swithed off with warning in manpage), and provide a list of discs on which it will work without problems. If it is not hard work, of course - I understan= d that it is not very pleasant to spend large amount of time working on somethink which only few users will profit on ... Or to store the timestamps by smartd itself (only if not possible to store it on HDD). But will it work correctly with suspend/hibernate? The problem with laptops often sleeping ... Wish you the best in your future work, Dan > Hi Dan, >=20 > I think that this is still an issue. >=20 > One could add a smartmontools feature to do self-tests > some number of > hours after the LAST self test. But for this to work > the self test log > timestamps and the power on time SMART attribute both > must be reliable and > work properly. MANY hard disks have problems with > these, as can be > confirmed by looking in the support mailing list and > in the smartmontools > FAQ. So I have never implemented this. >=20 > Other suggestions are welcome!! >=20 > Cheers, > Bruce >=20 >=20 > On Sun, 30 Dec 2007, ro...@vo... wrote: >=20 > > Hallo, > > > > I have smartmontools installed on laptop, but sheduling > > options in smartd.conf > > > are not very "laptop friendly". In discussion, however, > > I found post > > > from 16.04.2004 that doing sleduling in a more clever > > way (like test > > > after 7 days of run ...) is not possible due to faulty > > firmware and/or > > > the danger of self-test high frequency if laptops > > are in sleep state > > > most of the time. > > > > I want to ask, if the reasons are still topical, > > or if there is a plan > > > to enhance sheduling support for laptops. Was any > > solution proposed? > > > There are more and more laptops all around :-) > > > > Best regards, > > Dan > > > > > > -----------------------------------------------------------------------= -- > > > > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > _______________________________________________ > > Smartmontools-support mailing list > > Sma...@li... > > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > > > > > --=20 P=F8iv=EDtejte nov=FD rok s lep=B9=ED postavou. Pomoc=ED bezpe=E8n=FDch a o= v=EC=F8en=FDch program=F9 spr=E1vn=E9 v=FD=BEivy m=F9=BEete zhubnout a v=E1hu si udr=BEet = u=BE natrvalo. V=EDce informac=ED naleznete na www.idealnivaha.cz . |
|
From: Christian F. <Chr...@t-...> - 2008-01-07 19:00:02
|
Bruce Allen wrote:
> Hi Dan,
>
> I think that this is still an issue.
>
> One could add a smartmontools feature to do self-tests some number of
> hours after the LAST self test. But for this to work the self test log
> timestamps and the power on time SMART attribute both must be reliable and
> work properly. MANY hard disks have problems with these, as can be
> confirmed by looking in the support mailing list and in the smartmontools
> FAQ. So I have never implemented this.
>
> Other suggestions are welcome!!
>
>
Hi Bruce,
this is probably a reason to add persistence to smartd.
Then it would be possible to start tests based on recorded time of (or
uptime since) last self test.
Cheers,
Christian
|
|
From: Jim P. <ji...@jt...> - 2008-01-07 20:10:35
|
Christian Franke wrote: > Bruce Allen wrote: > > I think that this is still an issue. > > > > One could add a smartmontools feature to do self-tests some number of > > hours after the LAST self test. But for this to work the self test log > > timestamps and the power on time SMART attribute both must be reliable and > > work properly. MANY hard disks have problems with these, as can be > > confirmed by looking in the support mailing list and in the smartmontools > > FAQ. So I have never implemented this. > > > > Other suggestions are welcome!! > > Hi Bruce, > > this is probably a reason to add persistence to smartd. > > Then it would be possible to start tests based on recorded time of (or > uptime since) last self test. Maybe add a new option like "run this test whenever we receive SIGUSR1". Then something like anacron can easily be set up to send the signal. -jim |
|
From: Bruce A. <ba...@gr...> - 2008-01-10 03:04:12
|
Hi Jim, The outstanding question is: where do we store the persistent data from smartd (in a way that is portable across OSes and OS distributions). Christian, you had a proposal for this (one file per disk serial number, as I recall). Do you intend to move ahead with it? Cheers, Bruce On Mon, 7 Jan 2008, Jim Paris wrote: > Christian Franke wrote: >> Bruce Allen wrote: >>> I think that this is still an issue. >>> >>> One could add a smartmontools feature to do self-tests some number of >>> hours after the LAST self test. But for this to work the self test log >>> timestamps and the power on time SMART attribute both must be reliable and >>> work properly. MANY hard disks have problems with these, as can be >>> confirmed by looking in the support mailing list and in the smartmontools >>> FAQ. So I have never implemented this. >>> >>> Other suggestions are welcome!! >> >> Hi Bruce, >> >> this is probably a reason to add persistence to smartd. >> >> Then it would be possible to start tests based on recorded time of (or >> uptime since) last self test. > > Maybe add a new option like "run this test whenever we receive SIGUSR1". > Then something like anacron can easily be set up to send the signal. > > -jim > |
|
From: Jim P. <ji...@jt...> - 2008-01-10 03:08:42
|
> On Mon, 7 Jan 2008, Jim Paris wrote: >> Maybe add a new option like "run this test whenever we receive SIGUSR1". >> Then something like anacron can easily be set up to send the signal. Bruce Allen wrote: > Hi Jim, > > The outstanding question is: where do we store the persistent data from > smartd (in a way that is portable across OSes and OS distributions). > Christian, you had a proposal for this (one file per disk serial number, as > I recall). Do you intend to move ahead with it? Well, my idea avoids needing persistent data in smartd. The config file just says "signal" instead of a time/date spec, and then anacron is used to send that signal when necessary. Anacron keeps track of things (as it's designed to do) so smartd doesn't have to. -jim |
|
From: Bruce A. <ba...@gr...> - 2008-01-10 03:28:00
|
Hi Jim, Duh. OK, I get it. We are already using SIGUSR1 to force a status check, so we could use SIGUSR2. The only downside I can see is that all disks would have to respond to this same signal. I'm copying the developers list to see if others like this idea or see problems with it. It seems OK to me, though Christian's idea of having persistent state files is probably a better and more flexible solution. Cheers, Bruce On Wed, 9 Jan 2008, Jim Paris wrote: >> On Mon, 7 Jan 2008, Jim Paris wrote: >>> Maybe add a new option like "run this test whenever we receive SIGUSR1". >>> Then something like anacron can easily be set up to send the signal. > > Bruce Allen wrote: >> Hi Jim, >> >> The outstanding question is: where do we store the persistent data from >> smartd (in a way that is portable across OSes and OS distributions). >> Christian, you had a proposal for this (one file per disk serial number, as >> I recall). Do you intend to move ahead with it? > > Well, my idea avoids needing persistent data in smartd. The config > file just says "signal" instead of a time/date spec, and then anacron > is used to send that signal when necessary. Anacron keeps track of > things (as it's designed to do) so smartd doesn't have to. > > -jim > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
|
From: Douglas G. <do...@to...> - 2003-10-17 07:00:28
|
Ivan Degtyarenko wrote:
> Dear madam/sir,
>
> we are using your software and first of all thank you for this. Soft is
> great. Just small question.
>
> When I am getting the information about my scsi device with
>
> smartctl -a /dev/sdf1
>
> between others it gives
>
> ...
> Manufactured in week 00 of year 2000
> ...
>
> what it means? Where from smartctl takes this date info?
> My problem is that harddrive which we bought is labeled by date:
> 28 Apr 2003 and 'smartctl' gives year 2000.
>
> Who is wrong?
Ivan,
Maxtor is wrong (or at least inconsistent)! During
production they should put a valid production date
in the disk firmware (about the same time as they
give it a unique serial number).
Smartmontools is simply outputting the contents of
log page 0xe ("start stop cycle counter" page).
Maxtor's product manual for the Atlas 10k IV says
to "contact your Maxtor applications engineer" for
more information about the contents of log sense
pages (their site doesn't have a product manual for
the Atlas 15k yet). Contacting Maxtor shouldn't be
necessary since that page is defined in the relevant
standard (www.t10.org SPC document).
> full output:
>
> -------------------------------------------
> # smartctl -a /dev/sdb1
>
> smartctl version 5.20 Copyright (C) 2002-3 Bruce Allen
> Home page is http://smartmontools.sourceforge.net/
>
> Device: MAXTOR ATLAS15K_73SCA Version: DT60
> Serial number: C80356MK
> Device type: disk
> Local Time is: Thu Oct 9 19:05:50 2003 EEST
> Device supports SMART and is Enabled
> Temperature Warning Enabled
> SMART Health Status: OK
> Current Drive Temperature: 36 C
> Manufactured in week 00 of year 2000
> Current start stop count: 182 times
> Recommended start stop count: 4294967295 times
Perhaps I should change that to "Recommended maximum ...".
Anyway the number is crazy and is 0xffffffff in hex. The
standard gives them no latitude to do that.
> Error counter log:
> Errors Corrected Total Total Correction Gigabytes
> Total
> delay: [rereads/ errors algorithm processed
> uncorrected
> minor | major rewrites] corrected invocations [10^9
> bytes] errors
> read: 349618 0 0 0 0 772.206
> 0
> write: 0 0 0 0 0 668.155
> 0
>
> Non-medium error count: 4
> No self-tests have been logged
> Long (extended) Self Test duration: 2056 seconds [34.3 minutes]
Perhaps you should do a self test (e.g. 'smartctl -t short /dev/sdf')
to see if the result turns up after the second last line.
Anyway, how does the Atlas 15k perform?
Doug Gilbert
|
|
From: Ivan D. <im...@fy...> - 2003-10-19 16:53:59
|
Douglas, On Fri, 17 Oct 2003, Douglas Gilbert wrote: > > smartctl -a /dev/sdf1 > > > > between others it gives > > > > ... > > Manufactured in week 00 of year 2000 > > ... > > > > what it means? Where from smartctl takes this date info? > > My problem is that harddrive which we bought is labeled by date: > > 28 Apr 2003 and 'smartctl' gives year 2000. > > Who is wrong? > > Maxtor is wrong (or at least inconsistent)! During > production they should put a valid production date > in the disk firmware (about the same time as they > give it a unique serial number). Ok, thank you, I thought the same, Atlas 15k models are very new and it should be an inconsistent. At least it can't 3 years old. > > full output: > > > > ------------------------------------------- > > # smartctl -a /dev/sdb1 > > > > smartctl version 5.20 Copyright (C) 2002-3 Bruce Allen > > Home page is http://smartmontools.sourceforge.net/ > > > > Device: MAXTOR ATLAS15K_73SCA Version: DT60 > > Serial number: C80356MK > > Device type: disk > > Local Time is: Thu Oct 9 19:05:50 2003 EEST > > Device supports SMART and is Enabled > > Temperature Warning Enabled > > SMART Health Status: OK > > Current Drive Temperature: 36 C > > Manufactured in week 00 of year 2000 > > Current start stop count: 182 times > > Recommended start stop count: 4294967295 times > > Perhaps I should change that to "Recommended maximum ...". > Anyway the number is crazy and is 0xffffffff in hex. The > standard gives them no latitude to do that. > > > Error counter log: > > Errors Corrected Total Total Correction Gigabytes > > Total > > delay: [rereads/ errors algorithm processed > > uncorrected > > minor | major rewrites] corrected invocations [10^9 > > bytes] errors > > read: 349618 0 0 0 0 772.206 > > 0 > > write: 0 0 0 0 0 668.155 > > 0 By the way, what those 'delay minor errors' could mean? Is it harmless? > > Non-medium error count: 4 > > No self-tests have been logged > > Long (extended) Self Test duration: 2056 seconds [34.3 minutes] > > Perhaps you should do a self test (e.g. 'smartctl -t short /dev/sdf') > to see if the result turns up after the second last line. After 'smartctl -t short' results are still the same > Anyway, how does the Atlas 15k perform? Can't say too much, currently I am testing software RAID-5 by 6 Atlas 15k 73Gb disks. All disks are Ultra320 but I have Adaptec 39160D and disks are running Ultra160 mode. As well testing PC is pretty poor (old Intel Celeron 433MHz with 256Mb of memory). Later I will connect RAID to server station with Adaptec 39320D and could tell more. now hdparm gives # hdparm -t /dev/sdg /dev/sdg: Timing buffered disk reads: 64 MB in 2.04 seconds = 31.37 MB/sec for short comparison on the other channel old IBM DDRS-34560 gives # hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 64 MB in 5.10 seconds = 12.55 MB/sec Later, if need, I could say more test info about Ultra320 mode. But behind this we had problems, two new Atlas 15k disks just crushed with many bad blocks after some weeks of hard using. It was this summer, then we lost our RAID. Now we got by warranty two new and I am testing it. # badblocks -b 4096 -s -w -c 512 /dev/sd?1 gave no error :) Ivan --------- Ivan Degtyarenko ----------- im...@fy... ---------- Laboratory of Physics Helsinki University of Technology tel +358-9-451 3103 P.O.Box 1100 fax +358-9-451 3116 02015 Espoo, Finland ---------------------------------- http://www.fyslab.hut.fi/ ------ |
Thanks for helping keep SourceForge clean.
X