Ubuntu.pl 🇺🇦️ - Forum Ubuntu

W acerach na pewno mają domyślnie ustawioną agresywną politykę zarządzania energią. W kubuntu gutsy np. laptop mode ma wyłączone zarządzanie energią dysku. Trochę to bez sensu, ale może twórcy woleli tą kwestię scedować na producentów niż sami arbitralnie ustalać wartości. Wystarczy poprawić wpis w /etc/laptop-mode/laptop-mode.conf

Po przeczytaniu documentu z Hitachi okazuje sie ze twoje rozumowanie nie zgdza sie z rzeczywistoscia.

everth pisze:W ciągu normalnej pracy głowica przemieszcza się nad powierzchnią dysku kilkadziesiąt (a może kilkaset) razy na sekundę. I nikt nie robi z tego problemu. Zaparkowanie głowicy to dla niej wykonanie tylko dłuższego ruchu.
Rację mają ci którzy mówią że w parkowaniu nie chodzi o oszczędzanie energii - w tym przypadku nie ma żadnego oszczędzania - talerze wirują z pełną prędkością, głowica bez problemu mogłaby wisieć w miejscu ostatniego odczytu i też nie pobierałaby nadmiarowej mocy.

Glowica nie musi wykonac tylko dluzszego ruchu ale musi "wjechac" na specjalna pochylnie w ktorej znajduje sie specjalne wglebienie zabezpieczajace przed "lataniem glowicy". By uruchomic glowice ponownie ramie musi sie troszeczke uniesc i pozniej przesunac, i podczas tego unoszenia ramiena wystepuje zuzywanie sie materilu.
Druga sprawa; w tym samym opisie inzynier Hitachi pisze ze dzieki parkowaniu spada zuzycie energi nawet o 20%. Jest to zwiazane z tym ze jezeli glowica jest zaparkowana nie zuzywa wowczas energi na pozycjonowanie sie nad obszarem gdzie ostatnio wykonala operacje zapisu lub odczytu. W artykule mozna przeczytac rowniez o tym ze zaleta systemu parkowania jest unikniecie zbednego przypadkowego dotykania sie glowicy i talezy co dodatkowo przedluza zycie dysku. Glowica zostaje wyparkowana dopiero kiedy taleze osiagna nominalne obroty dzieki czemu powstaje miedzy dyskiem a glowica poduszka powietrzna zabezpieczajaca przed dotykaniem sie (zuzywaniem) elementow. Inna fajna ciekawostka to to ze system parkowania dziala rowniez w wypadku niespodziewanej utraty zasilania. Silnik w takiej sytuacji zaczyna dzialac jak dynamo i generuje wystarczajaco duzo energi by glowica mogla bezpiecznie zaparkowac.
Musze przyznac ze to jest bardzo fasynujacy obszar nauki na krawedzi nano-technologi. Przeczytalem go z wielkim zainteresowaniem.
Lukk'owi dziekuje za link do tego fantastycznego artykulu.

Czyli wg. tego artykułu opierając się na streszczeniu goudacastera jeśli zastosujemy skrypt podany w temacie to jedyne czemu przeciwdziałamy to zmęczenie materiału, choć nie jestem co do tego przekonany bo jeśli na siłę będziemy chcieli utrzymywać mechanizm nad talerzami to samo czuwanie skraca żywot.
Jedyne co zyskamy to niebezpieczeństwo uszkodzenia danych i większe zużycie energii.
To mnie tylko jeszcze bardziej utwierdza w przekonaniu, że niepotrzebnie panikujecie

everth pisze:W acerach na pewno mają domyślnie ustawioną agresywną politykę zarządzania energią. W kubuntu gutsy np. laptop mode ma wyłączone zarządzanie energią dysku. Trochę to bez sensu, ale może twórcy woleli tą kwestię scedować na producentów niż sami arbitralnie ustalać wartości. Wystarczy poprawić wpis w /etc/laptop-mode/laptop-mode.conf

mógłbyś dokładniej? po prostu włączyć? bo mam ten "problemik" na ascerze wlasnie, ze na xp nie przyrasta w duzym tempie natomiast na ubuntu przekracza 20 na 5 minut

pl-ayboy pisze: nie wiele mniej niz mam teraz (gora 2k przybyly)

To tez po czesci natura tego problemu, jedn twierdza ze to naduzywanie parkowania to wina dysku inni ze ubuntu. Co najciekawsze to zjawisko nie wystepuje u wszystkich. Ja mam 2 laptopy i na jednym jest wszystko OKe a na drugim nie i musialem zmienic ustawienia. W pracy wszyscy mamy ten sam model sluzbowego laptopa i niektorzy maja tez ubuntu, na moim byl problem a u kolegi nie.
Dlatego zalecam by sprawdzic najpierw czy problem nas dotyczy i jezeli tak to nalezy zastosowac sie do wskazowek.

Witam wszystkich
Ja mam z kolei inny przypadek.
Niedawno nabyłam laptopa Dell inspirion.
Na początku używałam tylko linuxa. Dysk pod ubuntu parkował jak oszalały, po zabawie z hdparam i spindown udało mi się zredukował ilość parkowań do około 15-20 na dobę.
Postanowiłam sprawdzić jak sprawa wygląda pod windowsem.
Przed włączeniem visty Load_Cycle_Count mierzony w ubuntu wynosił 548.
W czasie pracy pod windowsem co chwila było słychać parkowanie głowicy.
Po koło 2 godzinach pracy wróciłam na ubuntu i

Kod: Zaznacz cały

193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       656

Przez 2 godziny wzrosło o 108

, to mnie bardzo przeraziło.
Być może sytuacja pod windowsem się jeszcze zmieni kiedy zainstaluje dodatkowe serowniki do sata (bo na razie mam te natywne z visty)
Ale ogólnie widzę że w przypadku mojego dysku (TOSHIBA MK1646GSX) nie wygląda to wesoło.

u mnie problem występuje zarówno pod WinXP i Ubuntu7.10 (występował.)..

laptop ma 2 miesiące, Ubuntu na nim - około 5-6 dni.
na początku zdziwiło mnie takie.. 'pykanie' znacznie częstsze niż pod WinXP, wręcz.. notoryczne, po 2-3 razy na minutę, niewiedziałem co to oznacza, ale mnie denerwowało, pod Windowsem podobnie, chociaż sporo rzadziej.. gdy zobaczyłem ten wątek, pomyślałem, że muszę to sprawdzić, zatem:

1.
=== START OF INFORMATION SECTION ===
Local Time is: Sat Feb 9 03:06:37 2008 CET

193 Load_Cycle_Count 0x0022 095 095 000 Old_age Always - 10406

2.
=== START OF INFORMATION SECTION ===
Local Time is: Sat Feb 9 03:46:42 2008 CET

193 Load_Cycle_Count 0x0022 095 095 000 Old_age Always - 10471

(w 40 minut pracy pod Ubuntu.. przyrost o 65.)

po tym, wprowadziłem zmiany opisane przez lukk'a, z liczbą 254.. zdało mi się, że 'pykanie' ustało.. potem, komputer chodził znów pod XP tylko.. wyłączyłem, sprawdziłem pod Ubuntu:

3.
=== START OF INFORMATION SECTION ===
Local Time is: Sat Feb 9 13:55:19 2008 CET

193 Load_Cycle_Count 0x0022 095 095 000 Old_age Always - 10530

(zatem, po kilku godzinach pod Windowsem, przyrost 60.)

wykonałem godzinę później następny pomiar, komputer chodził tylko na Ubuntu:

4.
=== START OF INFORMATION SECTION ===
Local Time is: Sat Feb 9 15:00:37 2008 CET

193 Load_Cycle_Count 0x0022 095 095 000 Old_age Always - 10530

(jak widać, w Ubuntu ustało kategorycznie parkowanie dysku..)

hmm, zatem mój dysk często parkuje pod WinXP, nie robi już tego pod Ubuntu.. chociaż, to akurat średnio mi się podoba, czy, modyfikując liczbę 254, np. na 200.. można jakoś, dozować ilością parkowań?

ps. mój laptop to Lenovo Thinkpad R61, z dyskiem Seagate Momentus 5400.3 ST9120822AS 120GB..

90-100 na dobę...
Nie wiem, czy te 90-100 ma być na jeden dzień, czy 24 godziny użytkowania?

Mój wynik:

193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 2868

Laptop kupiony w połowie Grudnia 2007, często używany(kilka godzin na dobę).
Powinienem się martwić? Używam Ubuntu 7.10 32bit.

weakhead; Producenci mówią o około 400 000 ( wiem że ludzie mają i po 800 000) parkowań głowicy , na tyle gwarantują , to łatwo policzyć że 100 na dobę ( ty masz chyba jeszcze mniej 2868/na dwa miesiące to około 50 ) razy 365 dni to jest 36500, czyli 400 000 gwarantowanych cykli parkowań przez 36500 parkowań w roku daje prawie 11 lat , znajdź sobie coś innego do zmartwień , pamiętaj że na Windowsie i MacOS jest tak samo , to jest technologia dysku a nie systemu.

Opis jak ograniczyć lub wyłączyć parkowanie głowicy , przeczytajcie dokładnie posty pod artykułem tam jest jeszcze jedno rozwiązanie .

Pacjent_x z tego co tu piszesz to wynika że twój dysk już jest złomem i nic już mu nie pomoże ale cały zestaw programów diagnostycznych do dysków i nie tylko jest na UBCDpłyta liveCD większość programów pracuje w trybie tekstowym.

Będąc zapisany na:

Kod: Zaznacz cały

59695@bugs.launchpad.net

Dostałem dzisiaj informację treści:

Kod: Zaznacz cały

                                                                                                                                                                                                                                                               
Delivered-To: lukaszgraczyk@gmail.com
Received: by 10.142.163.13 with SMTP id l13cs2427wfe;
        Fri, 15 Feb 2008 16:55:20 -0800 (PST)
Received: by 10.100.37.20 with SMTP id k20mr5092366ank.24.1203123320210;
        Fri, 15 Feb 2008 16:55:20 -0800 (PST)
Return-Path: <bounces@canonical.com>
Received: from adelie.canonical.com (adelie.canonical.com [91.189.90.139])
        by mx.google.com with ESMTP id 18si6029969agb.36.2008.02.15.16.55.19;
        Fri, 15 Feb 2008 16:55:20 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) client-ip=91.189.90.139;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) smtp.mail=bounces@canonical.com
Received: from forster.canonical.com ([91.189.90.190])
	by adelie.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQBKo-0000bB-0D
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 00:55:18 +0000
Received: from localhost ([127.0.0.1] helo=forster.canonical.com)
	by forster.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQBGY-0005gf-3n
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 00:50:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jakob Unterwurzacher <jakob.at@gmx.net>
To: lukaszgraczyk@gmail.com
Reply-To: Bug 59695 <59695@bugs.launchpad.net>
References: <20060909203825.16647.70167.malonedeb@gangotri.ubuntu.com>
Sender: bounces@canonical.com
Date: Sat, 16 Feb 2008 00:42:12 -0000
Message-Id: <20080216004212.15789.22109.malone@gangotri.ubuntu.com>
Subject: [Bug 59695] The Debian Fix
X-Launchpad-Bug: distribution=ubuntu; sourcepackage=acpi-support;
	component=main; status=Confirmed; importance=Critical;
	assignee=None; 
X-Launchpad-Bug: distribution=baltix; sourcepackage=acpi-support;
	component=None; status=New; importance=Undecided; assignee=None;
X-Launchpad-Bug: distribution=debian; sourcepackage=acpi-support;
	component=None; status=Fix Released; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=fedora; sourcepackage=pm-utils; component=None;
	status=Invalid; importance=Unknown; assignee=None; 
X-Launchpad-Bug: distribution=mandriva; sourcepackage=laptop-mode-tools;
	component=None; status=In Progress; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=suse; sourcepackage=None; component=None;
	status=Confirmed; importance=Unknown; assignee=None; 
X-Launchpad-Message-Rationale: Subscriber
Errors-To: bounces@canonical.com
Precedence: bulk
X-Generated-By: Launchpad (canonical.com)

This is the official Debian fix, extracted from the latest acpi-support
Debian package: http://ftp.at.debian.org/debian/pool/main/a/acpi-support
/acpi-support_0.103-5_i386.deb .

The attached file, 90-hdparm.sh goes to the following two directories:
/etc/acpi/start.d
/etc/acpi/resume.d

That's all.

Dear Ubuntu package maintainer, take it and use it.

** Attachment added: "90-hdparm.sh"
   http://launchpadlibrarian.net/12024037/90-hdparm.sh

-- =

High frequency of load/unload cycles on some hard disks may shorten lifetime
https://bugs.launchpad.net/bugs/59695
You received this bug notification because you are a direct subscriber
of the bug.

Wiadomość została uzupełniona o:

Kod: Zaznacz cały

Delivered-To: lukaszgraczyk@gmail.com
Received: by 10.142.163.13 with SMTP id l13cs3596wfe;
        Fri, 15 Feb 2008 17:40:28 -0800 (PST)
Received: by 10.100.152.19 with SMTP id z19mr5137673and.56.1203126028019;
        Fri, 15 Feb 2008 17:40:28 -0800 (PST)
Return-Path: <bounces@canonical.com>
Received: from adelie.canonical.com (adelie.canonical.com [91.189.90.139])
        by mx.google.com with ESMTP id 36si6154857aga.17.2008.02.15.17.40.27;
        Fri, 15 Feb 2008 17:40:28 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) client-ip=91.189.90.139;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) smtp.mail=bounces@canonical.com
Received: from forster.canonical.com ([91.189.90.190])
	by adelie.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQC2U-0008D3-IP
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 01:40:26 +0000
Received: from localhost ([127.0.0.1] helo=forster.canonical.com)
	by forster.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQByB-0000BD-Em
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 01:35:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jakob Unterwurzacher <jakob.at@gmx.net>
To: lukaszgraczyk@gmail.com
Reply-To: Bug 59695 <59695@bugs.launchpad.net>
References: <20060909203825.16647.70167.malonedeb@gangotri.ubuntu.com>
Sender: bounces@canonical.com
Date: Sat, 16 Feb 2008 01:29:16 -0000
Message-Id: <20080216012916.16246.51187.malone@gangotri.ubuntu.com>
Subject: [Bug 59695] The Debian Fix (correction + debdiff)
X-Launchpad-Bug: distribution=ubuntu; sourcepackage=acpi-support;
	component=main; status=Confirmed; importance=Critical;
	assignee=None; 
X-Launchpad-Bug: distribution=baltix; sourcepackage=acpi-support;
	component=None; status=New; importance=Undecided; assignee=None;
X-Launchpad-Bug: distribution=debian; sourcepackage=acpi-support;
	component=None; status=Fix Released; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=fedora; sourcepackage=pm-utils; component=None;
	status=Invalid; importance=Unknown; assignee=None; 
X-Launchpad-Bug: distribution=mandriva; sourcepackage=laptop-mode-tools;
	component=None; status=In Progress; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=suse; sourcepackage=None; component=None;
	status=Confirmed; importance=Unknown; assignee=None; 
X-Launchpad-Message-Rationale: Subscriber
Errors-To: bounces@canonical.com
Precedence: bulk
X-Generated-By: Launchpad (canonical.com)

The file 90-hdparm.sh (attached above, comment #375) goes to the following =
four directories:
/etc/acpi/ac.d
/etc/acpi/battery.d
/etc/acpi/resume.d
/etc/acpi/start.d

Attached here is a debdiff between Ubuntu's and Debian's acpi-support packa=
ge, created with:
debdiff acpi-support_0.103.dsc acpi-support_0.103-5.dsc ,
with everything but the 90-hdparm.sh stuff removed.

** Attachment added: "debdiff of Debian's 90-hdparm.sh fix"
   http://launchpadlibrarian.net/12024340/debian-hdparm-fix.debdiff

-- =

High frequency of load/unload cycles on some hard disks may shorten lifetime
https://bugs.launchpad.net/bugs/59695
You received this bug notification because you are a direct subscriber
of the bug.

Zaraz przetestuje jak działa ten fix. Radzę też Wam to przetestować aby zweryfikować czy działa poprawnie. Wyrzucam Ugly Fix i instaluje to.

Dajcie znać jak to u Was działa.

#############################################

Ja już przetestowałem i powiem tak. Znowu potwierdza się fakt że Debian i Ubuntu nie są zgodne pakietami.

Napisałem na:

Kod: Zaznacz cały

59695@bugs.launchpad.net

Takie pytanie:

Kod: Zaznacz cały

How to install this Fix under Ubuntu 7.10? Debian package give me this kind of error messages:

Error: Dependency is not satisfable: acpi-support-base

After instalation:

acpi-support-base_0.103-5_all.deb

From:

http://packages.debian.org/lenny/all/acpi-support-base/download

Next Error was:

Error: Dependency is not satisfable: libc6

After instalation:

libc6_2.7-5ubuntu2_i386.deb

From:

http://packages.ubuntu.com/cgi-bin/download.pl?arch=i386&file=pool%2Fmain%2Fg%2Fglibc%2Flibc6_2.7-5ubuntu2_i386.deb&md5sum=6086195ebf404a874e2d721d730fa28a&arch=i386&type=main

Next Error message is:

Error: Dependency is not satisfable: x11-xserver-utils

This package generates conflict with so many packages in Ubuntu 7.10 that I just have to back to Ugly FIX by Ubuntu Deamon.

How to install this Debian FIX? When Ubuntu will create official Ubuntu Package with this FIX?

Narazie wróciłem do Ugly FIX i sądzę że jeszcze trochę będę z niego korzystał w zaistniałej sytuacji.

Jeśli znajdzie ktoś sposób na instalację tego pakietu Debiana to dajcie znać.

#############################################

Dostałem odpowiedź na pytanie dotyczące instalacji Debian FIX pod Ubuntu. Brzmi ona tak:

Kod: Zaznacz cały

Delivered-To: lukaszgraczyk@gmail.com
Received: by 10.142.163.13 with SMTP id l13cs31429wfe;
        Sat, 16 Feb 2008 07:56:15 -0800 (PST)
Received: by 10.100.172.17 with SMTP id u17mr1616556ane.65.1203177374916;
        Sat, 16 Feb 2008 07:56:14 -0800 (PST)
Return-Path: <bounces@canonical.com>
Received: from adelie.canonical.com (adelie.canonical.com [91.189.90.139])
        by mx.google.com with ESMTP id 6si6756604agd.23.2008.02.16.07.56.14;
        Sat, 16 Feb 2008 07:56:14 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) client-ip=91.189.90.139;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of bounces@canonical.com designates 91.189.90.139 as permitted sender) smtp.mail=bounces@canonical.com
Received: from forster.canonical.com ([91.189.90.190])
	by adelie.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQPOf-0000AT-TN
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 15:56:13 +0000
Received: from localhost ([127.0.0.1] helo=forster.canonical.com)
	by forster.canonical.com with esmtp (Exim 4.60 #1 (Debian))
	id 1JQPOf-0007iq-NO
	for <lukaszgraczyk@gmail.com>; Sat, 16 Feb 2008 15:56:13 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jakob Unterwurzacher <jakob.at@gmx.net>
To: lukaszgraczyk@gmail.com
Reply-To: Bug 59695 <59695@bugs.launchpad.net>
References: <20060909203825.16647.70167.malonedeb@gangotri.ubuntu.com>
Sender: bounces@canonical.com
Date: Sat, 16 Feb 2008 15:47:04 -0000
Message-Id: <20080216154704.10323.18558.malone@gandwana.ubuntu.com>
Subject: [Bug 59695] Applying the Debian fix manually
X-Launchpad-Bug: distribution=ubuntu; sourcepackage=acpi-support;
	component=main; status=Confirmed; importance=Critical;
	assignee=None; 
X-Launchpad-Bug: distribution=baltix; sourcepackage=acpi-support;
	component=None; status=New; importance=Undecided; assignee=None;
X-Launchpad-Bug: distribution=debian; sourcepackage=acpi-support;
	component=None; status=Fix Released; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=fedora; sourcepackage=pm-utils; component=None;
	status=Invalid; importance=Unknown; assignee=None; 
X-Launchpad-Bug: distribution=mandriva; sourcepackage=laptop-mode-tools;
	component=None; status=In Progress; importance=Unknown;
	assignee=None; 
X-Launchpad-Bug: distribution=suse; sourcepackage=None; component=None;
	status=Confirmed; importance=Unknown; assignee=None; 
X-Launchpad-Message-Rationale: Subscriber
Errors-To: bounces@canonical.com
Precedence: bulk
X-Generated-By: Launchpad (canonical.com)

If you want to use the Debian fix now, *DO NOT* install the Debian acpi-
support package (dowloaded from somewhere.debian.org). This won't work
or - worse - will break your system.

Instead, download this file,
http://launchpadlibrarian.net/12024037/90-hdparm.sh (from comment #375),

and copy it to these four directories:
/etc/acpi/ac.d
/etc/acpi/battery.d
/etc/acpi/resume.d
/etc/acpi/start.d

-- =

High frequency of load/unload cycles on some hard disks may shorten lifetime
https://bugs.launchpad.net/bugs/59695
You received this bug notification because you are a direct subscriber
of the bug.

Zaraz zabieram się za instalację. Czyli:

Ściągam plik:

Kod: Zaznacz cały

http://launchpadlibrarian.net/12024037/90-hdparm.sh

Do katalogu:

Kod: Zaznacz cały

/home/[User_name]

Potem instaluje go w następujących folderach za pomocą komend:

Kod: Zaznacz cały

sudo install 90-hdparm.sh  /etc/acpi/resume.d/
sudo install 90-hdparm.sh  /etc/acpi/start.d/
sudo install 90-hdparm.sh  /etc/acpi/ac.d/
sudo install 90-hdparm.sh /etc/acpi/battery.d/

Natomiast pliki z Ugly Fix wyrzucam. Sprawdzę czy działa poprawnie.

Na moje oko skrypt jest trochę bardziej rozbudowany niż Ugly FIX ale chyba robi dokładnie to samo co ten ostatni.

Zadam jeszcze pytanie czy to że mam w katalogu:

Kod: Zaznacz cały

/etc/acpi/resume.d

Ma jakieś znaczenie w sensie że są tam pliki o nazwach:

Kod: Zaznacz cały

90-thinkpad-unstandby-led.sh
90-xscreensaver.sh

Bo szczerze powiem że nie wiem czy ten numer na początku ma jakieś większe znaczenie dla systemu? Wie ktoś może?

Proszę testować tego FIXa.

mam ten problem na ibm t42, niestety wszystkie sposoby opisane w tym temacie zawiodly.... stuka mi co 13s macie moze jakies inne pomysly? bo zaczyna mnie to irytowac, wlasciwie non-stop cos...

Witam, u mnie problem rozwiązał skrypt SirLancelot'a na dysku Hitachi HTS541612J9SA00 z notebooka Dell Inspiron 6400/E1504. Komputer ma juz 1.5 roku, cykli jak na ten okres niewiele 22900, ale przyrost przerażający około 100/h (używając Ubuntu). Co mnie zadziwiło, wraz ze spadkiem cykli temeratura dysku twardego spadła z 54stC, na około 47-48stC - komputer stał sie chłodniejszy - super sprawa

udalo mi sie rozwiazac problem, ibm t42

dysk Model=TOSHIBA MK4026GAX RoHS , FwRev=PA107E , SerialNo= X5KZ3844T

do rc.local wpisujemy: hdparm -B 254 /dev/sda

Siema Wszystkim Użytkownikom Ubuntu!!!
Mam Acera Aspire i 4 godz temu odkryłem ten post, więc zaistalowałem smartools, żeby sprawdzić na swoim dysku ilość parkowań.
Przez 3 godz po zainstalowaniu ilość parkowań wynosiła 0 i testowałem z podłączonym i odłączonym zasilaczem(przeglądając strony internetowe, kopiując i oglądając film, oczywiście wszystko po kolei). Wszystko to było do czasu gdy nie wylogowałem się z normalnego użytkownika i zalogowałem na root(oczywiście w X-ach)
Przed operacją logout wynik był taki:

193 Load_Cycle_Count 0x0032 055 055 000 Old_age Always - 91363

Teraz zapieprza (sorry za wyrażenie ale się załamałem) z mega prędkością bo po 1 godz użytkowania jest już tak:

193 Load_Cycle_Count 0x0032 055 055 000 Old_age Always - 91485

Jeśli to nie ustąpi to zaraz zabieram się do wpisywania tych skryptów które są na początku postu, tyle tylko chciałbym wiedzieć dlaczego tak się stało, może ktoś jest mi w stanie odpowiedzieć.

P.S Jeszcze jedna sprawa którą teraz zauważyłem po włączeniu ktorrenta prędkość z jaką pędził "parkujący" ustała i się utrzymuje na takim samym poziomie już przez 15 minut.
A dodam że jak testowałem go na początku przez te 3 godz to też miałem włączonego ktorrenta. Czy to może mieć coś wspólnego?
I tak na koniec, jak ktorrent jest wyłączony to w ciągu 1 minuty parkuje aż 3 razy i się nie zatrzymuje

Wnioskowałbym z tego że jeśli dysk pracuje to nie parkuje, tak? (dobrze rozumuje?)

Pozdrowienia dla Wszystkich linuxowych Geniuszy.
P.P.S Ostatnia sprawa, laptopa mam od grudnia 2006r. czy 91549 cykli to dużo?

91 tysięcy jak na 15 miesiecy to nie tak dużo. Łatwo można obliczyć, że dysk wystarczy Ci jeszcze przynajmniej na kolejne 4 lata (przy zachowaniu aktualnego tempa parkowania, wtedy dobije do granicy 400.000). Nie okłamujmy się - nawet gdyby zdarzyło się, że za 4 lata nie będą dominować dyski ssd, to i tak na pewno będziesz chciał wymienić swojego twardziela ze względu na niesatysfakcjonującą pojemność. Zakładając oczywiście, że w ciągu tych 4 lat nie staniesz się posiadaczem kolejnego laptopa

Trafił do mnie 2,5 letni lap MAXDATA z dyskiem Western Digital WD600VE 60GB, używany wyłącznie pod winXP. Powodem mojej ingerencji były bardzo częste metaliczne "stuki" dysku, powodujące nawet "zwisy" windy. Po odpaleniu UBUNTU LIVE smartmontools pokazał Load_Cycle_Count=1046413...

(smartmontools można doinstalować do LIVE)
Testy dysku różnymi programami testującymi (hdd regenerator, ndd, drive fitness test itd) nie wykazały żadnych badsectorów... Po zastosowaniu poprawki lukk-a:
hdparm -B 254 /dev/sda
hdparm -S0 /dev/sda
przez ponad dobę Load_Cycle_Count zwiększył się o 2... mimo pracy pod windą i intensywnej pracy dysku (specjalne testy) smartmontools podał temperature_Celsius=32
Jednocześnie ANI RAZU nie wystąpił "metaliczny stuk" (pod winXP, Ubuntu odpalane tylko do odczytu smartmontools) mimo że wcześniej stuki były przynajmniej raz na minutę (Load_Cycle_Count podzieliłem przez Power_On_Hours i wyszło 83 na godzinę).
Wnioski:
1. duża ilość parkowań jest raczej spowodowana błędnymi ustawieniami firmware dysku a nie systemem operacyjnym
2. być może producenci dysków pod pretekstem "ochrony naszych danych" zapewnili sobie częstą wymianę dysków

Przemyślenia:
1. czy "parkowanie głowicy" na pewno zabezpiecza dysk? Mam wątpliwości... Raz że głowica przy przeciążeniu (uderzeniu) prawdopodobnie nie zdąży się "zaparkować" a dwa że porusza się podczas pracy na swoistej "poduszce powietrznej" wytwarzanej wirującymi talerzami. Co innego gdy dysk nie pracuje... Ale już w najstarszych dyskach były wydzielone cylindry parkujące właśnie do parkowania głowic w czasie gdy dysk nie pracuje.
2. Czy parkowanie głowic naprawdę oszczędza baterię? Być może, ale raczej w bardzo niewielkim stopniu... co innego w trybie STANDBY lub SLEEP... Najwięcej energii pochłania silnik napędzający talerze. Wg specyfikacji dysku http://www.wdc.com/en/products/Products.asp?DriveID=103 w trybach tych zużycie energii jest około dziesięciokrotnie mniejsze... Ale znowu jest "ale"... Jak wiadomo największe zużycie energii przez silnik jest podczas rozruchu... czy zwiększone wtedy zużycie nie "zje" nam poczynionych oszczędności? Jeśli komuś by się chciało, mógłby przetestować... Jeszcze jedno trzeba uwzględnić: laptop podczas pracy zużywa ok. 40W... więc jak do tego się ma 2,5W zużywane przez dysk?

Witam Wszystkich!!!
Mam pytanie odnośnie tego zmniejszenia parkowań, czy to może uszkodzić w jakimś stopniu dysk?
Zastosowałem się do rady na początku postu i stworzyłem ten skrypt. Tylko teraz nie chce mi wcale parkować (ilość cykli utrzymuje się na tym samym poziomie )czy to źle???:|
Pozdrawiam!

KRI$$ pisze:Witam Wszystkich!!!
Mam pytanie odnośnie tego zmniejszenia parkowań, czy to może uszkodzić w jakimś stopniu dysk?
Zastosowałem się do rady na początku postu i stworzyłem ten skrypt. Tylko teraz nie chce mi wcale parkować (ilość cykli utrzymuje się na tym samym poziomie )czy to źle???:|
Pozdrawiam!

Uważam że to nie jest źle... Myślę, że parkowania podczas normalnej pracy niczemu nie służą, ten mechanizm powinien być wykorzystywany tylko przy wyłączaniu dysku (SLEEP, SUSPEND, SHUTDOWN). Nie widzę zysków płynących z parkowania, nie widzę strat spowodowanych ich brakiem. Jak pisałem wyżej laptop z włączonym parkowaniem nabił ponad milion cykli, metaliczne "zgrzyty" pojawiały się bardzo często (czasami nawet kilka razy na minutę)... Teraz testuję tego laptopa 4 dobę, chodzi na okrągło pod windą, przybyło 2 cykle (wyłączałem na chwilę dla zainstalowania poprawek), temperatura 31-33 stopnie. Nie usłyszałem ani jednego "stuku", ani razu się nie zawiesił... Zapomniałem dodać że przez 2,5 roku pracował prawie cały czas na zasilaniu sieciowym, tylko kilka razy na baterii, cały czas leżał na stole, nigdy na kolanach czy innych powierzchniach.
Pozdrawiam

Moje spostrzeżenia. Laptop 3 miesiace. Ponad 50 tyś cykli. Praca w 80% na Linuksie i 20% na XP. Przyrost cykli na Ubuntu bez skryptu to ponad 100 na dobe. Zasilanie głownie z sieci bez baterii (90%). Po włączeniu skryptu (wartosc 254) przyrost na Ubuntu podczas pracy = 0. Przyrost występuje tylko w momencie uruchamiania systemu ok 3 cykli.
Pod Windowsem 2h gry w CoD4 dodal mi 150 cykli!!!!!!!
Wnioski. "Wady" przyrostów cykli zależą od producenta dysku raczej nie od systemu.

To tak nowy compal fl90 pracującym na zasilaniu sieciowym od 12 marca i Windows xp pierwsze co zrobiłem to monitorowałem dysk smarttolsem, hdtunem i miałem przyrost okolo10/20 na godzinę. Gdy postanowiłem sobie pograć w Cywilizacje IV

:razz: lecz gdy wylączylem grę i sprawdziłem smartolsem/hdtunem to przyrost był bardzo duży 100-250, wygoglowalem program do obsługi lapka " Notebook Hardware Control " który umożliwia ustawienie parkowań poprzez wybranie max perfomance która ma wartość 254. Parkowań mam w tej chwili mało bo 2237 dlatego że wątek stukania/parkowania śledzę od dawna od kiedy postanowiłem że sobie kupie notebooka. Głowica mi teraz parkuje 1-2 raza tylko podczas włączania lapka, temperatura w stresie dochodzi do 47/48 stopni C.

Ubuntu będzie na tym lapku w wersji 8.04 czyli już niedługo.
Dysk twardy Seagate ST9200420ASG 200 GB [186.31GB], z g-protectiont

Temat można by przypiąć i wyróżnić dla przyszłych Ubunciarzy z notebookami.

Ubuntu.pl 🇺🇦️ - Forum Ubuntu

Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?

Odp: Ubuntu niszczy dyski w notebookach?