Hallo,

kürzlich habe ich mir ein WD Elements USB 2 Laufwerk gekauft, dass ich im Grunde genommen direkt zurück geben hätte sollen, habe mich aber dazu entschieden etwas zu testen, da die Laufwerke angenehm ruhig sind, jedenfalls solange sie nicht unentwegt rauf und runter fahren.

Diese Laufwerke fahren nach ca. 10 Minuten ohne Zugriff runter, was ok wäre, wenn sie nicht willkürlich mehrfach in einer Stunde auch wieder hochgefahren werden würden.

Dies passiert unter all meinen Linux, mit init, upstart und mit Arch Linux, also systemd. Unter Arch nutze ich Xfce.
[rocketmouse@archlinux ~]$ pacman -Q thunar-volman
thunar-volman 0.8.0-1
[rocketmouse@archlinux ~]$ pacman -Q gvfs
gvfs 1.14.2-4
Vielleicht würden sie nicht willkürlich hochgefahren werden, wenn nicht irgend ein Zugriff stattfinden würde, dessen ich mir nicht gewahr bin.

Bisher kann ich ein Runterfahren nur erfolgreich unterbinden, indem ich ein Script auf die Platte zugreifen lasse.

Wenn ich aber wild mounte und unmounte, unterliegt der Teil, der für das mounten zuständig ist einem Condition Race.

Das die Schleife, die warten soll, bis wirklich unmounted wurde überflüssig ist und sogar selbst zu einem Problem werden kann weiß ich, dies ist kein fertiges Script, sondern ein Experiment alle möglichen denkbaren Condition Races abzufangen.

Das mounten über Thunar und das Script können, müssen sich aber nicht in die Quere kommen. Gibt es eine Möglichkeit eine Partition der Platte von Thunars Mount-Funktion auszuschließen?

Könnte ich die Platte wach halten ohne eine Partition gemountet zu haben? Irgend etwas scheint sie ja willkürlich zu wecken, dies müsste ich also auch nutzen können.
[rocketmouse@archlinux ~]$ cat /usr/local/sbin/no-spind
#!/bin/sh
# /usr/local/sbin/no-spind

realpart=`blkid -L u1.1tmp`
mountpoint=/mnt/u1.1tmp
exit_i=1
count=0

echo "Please wait 30 seconds"
sleep 30

if [ "$(mount -l | grep u1.1tmp)" ]; then
  echo "Unmounting $realpart"
  umount $realpart
  while mount -l | grep u1.1tmp; do sleep 3; done ;
fi

if [ "$(lsusb -d 1058:)" ]; then
  mkdir -p $mountpoint
  echo "Mounting $realpart $mountpoint"
  mount $realpart $mountpoint
  exit_i=$?
  chown rocketmouse:rocketmouse $mountpoint
  chmod ug=rwx,o=r $mountpoint
else
  echo "No WD USB drive connected"
  mount -l | grep u1.1tmp; echo $exit_i; exit $exit_i
fi

echo 0 >$mountpoint/.no-spind.counter
while test -f $mountpoint/.no-spind.counter; do
  sleep 300; ((count++))
  echo $count >$mountpoint/.no-spind.counter
done
exit_i=$?

echo  "Stopping"
umount $realpart
mount -l | grep u1.1tmp; echo $exit_i; exit $exit_i
Diese "grünen" WD Laufwerke sind dafür bekannt, die Garantiezeit nicht zu überleben, wenn man sie gewähren lässt.
[rocketmouse@archlinux ~]$ mount -l | grep u1.1tmp
/dev/sdc1 on /mnt/u1.1tmp type ext3 (rw,relatime,data=ordered) [u1.1tmp]
Es kann vorkommen das u1.1tmp als sdc1 bis sd* gelistet wird, wobei man diesen Müll nicht los werden kann, aber alles dennoch funktioniert, dass Laufwerk real dem letzten Buchstaben zugeordnet ist, also z.B. sdd.

Grüße
Ralf
> Könnte ich die Platte wach halten ohne eine Partition gemountet zu haben?

Du kannst mit idle3ctl -d die Funktion deaktivieren. Es kann sein, dass du die Platte dafür ausbauen und per SATA anschließen musst, wenn der USB-Adapter die nötigen ATA-Befehle nicht unterstützt.
Danke.

Ich bin zwar Experte im partialen abföhnen von Siegeln oder ich reiße die Schraube unter einem Siegel einfach mit Gewalt raus, um die Garantie nicht zu verlieren, doch dieses Gehäuse ist frei von Siegeln und Schrauben und wer weiß ob überhaupt eine SATA drin ist oder nicht alte 3.5" IDE Platten verbraten wurden.

idle3ctl -d werde ich später ausprobieren. Nötigenfalls müsste ich die Platte einmalig an SATA anschließen und könnte sie danach wieder über USB benutzen, die Änderung wäre beständig?

Weiß jemand wie man die WD Elemets Gehäuse, ohne das etwas schaden nimmt, öffnen und wieder schließen kann?
Nötigenfalls müsste ich die Platte einmalig an SATA anschließen und könnte sie danach wieder über USB benutzen, die Änderung wäre beständig?
Richtig.

Allerdings muss die Platte einmal komplett rebootet werden, damit die Einstellung übernommen wird (=vom Strom trennen). Beim Aus-/Einbau passierts eh, aber wenn du das über USB einstellst, musst du die Externe hinterher komplett ausschalten und für 5-10 Sekunden Stecker ziehen.
Das die Platte rauf und runter fährt liegt weder an der Platte, noch am
Kernel, es scheint durch die DEs verursacht zu werden. Normalerweise fährt das Laufwerk runter und wird nicht willkürlich wieder hochgefahren. "noatime" oder "relatime" kann schwerlich in /etc/fstab disabled werden, wenn dort nicht gemountet wird, zudem besteht das Problem auch wenn keine Partition gemountet ist.
[rocketmouse@archlinux src]$ wget http://garr.dl.sourceforge.net/project/idle3-tools/idle3-tools-0.9.1.tgz
[rocketmouse@archlinux src]$ tar xzvf idle3-tools-0.9.1.tgz
[rocketmouse@archlinux src]$ cd idle3-tools-0.9.1
[rocketmouse@archlinux idle3-tools-0.9.1]$ make
[rocketmouse@archlinux idle3-tools-0.9.1]$ sudo cp idle3ctl /usr/local/sbin/
[rocketmouse@archlinux idle3-tools-0.9.1]$ cd ..
[rocketmouse@archlinux src]$ rm -r idle3-tools-0.9.1*
[rocketmouse@archlinux src]$ sudo pacman -Syu tcl tk
tcl und tk werden von idle3ctl nicht benötigt, aber idle3 benötigt sie, unwichtig in diesem Falle, es ist mir zufällig durch einen Tippfehler aufgefallen.
[rocketmouse@archlinux src]$ idle3ctl -V
idle3ctl v0.9.1
[rocketmouse@archlinux src]$ sudo smartctl -i /dev/sdc
smartctl 6.0 2012-10-10 r3643 [x86_64-linux-3.7.10-1-ARCH] (local build)
Copyright (C) 2002-12, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD20EZRX-00DC0B0
Serial Number:    WD-WMC300753067
LU WWN Device Id: 5 0014ee 65863b194
Firmware Version: 80.00A80
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Sat Mar 16 12:00:15 2013 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

[rocketmouse@archlinux src]$ sudo smartctl /dev/sdc -a | grep '^193'
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       1747
[rocketmouse@archlinux src]$ sudo idle3ctl --force -v -d /dev/sdc
Checking if Drive is a Western Digital Drive
outgoing cdb:  85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x8
SG_IO: bad response (not CHECK_CONDITION)
Trying legacy HDIO_DRIVE_CMD
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
So muss ich also herausfinden wo der Fehler bei den DEs liegt.

In der Mailing Liste ist es leider nicht erwünscht, um Hilfe zu bitten:

-------- Forwarded Message --------
From: arch-general-owner
Subject: Request to mailing list arch-general rejected
Date: Fri, 15 Mar 2013 05:42:52 -0400

Your request to the arch-general mailing list

Posting of your message titled "Re: [arch-general] Western Digital
external drives"

has been rejected by the list moderator. The moderator gave the
following reason for rejecting your request:

"Enough speculation for this week: messages where you make many
different hypothesis without actually testing any are of no use to
this list. Please wait until you have have actual facts to report or
contribute before posting next time. Cheers. --[...]"

Wie soll ich etwas testen, wenn ich nicht weiß was ich testen soll? Aus diesem Grunde bitte ich schließlich um Hilfe.
Ralf schrieb Vielleicht würden sie nicht willkürlich hochgefahren werden, wenn nicht irgend ein Zugriff stattfinden würde, dessen ich mir nicht gewahr bin.
audit könnte dabei helfen den Prozess zu identifizieren (der Daemon scheint sich erst nach einem Reboot starten zu lassen). Beispiel:
systemctl start auditd.service
mount /dev/sdb1 /mnt/
auditctl -w /mnt -p rwa -k usbhdd
touch  /mnt/foo
ausearch -i -k usbhdd
Hallo,

danke, leider hat diese Methode 2 Haken, zum einen muss eine Partition gemountet sein, dass Problem tritt aber bereits auf, wenn keine Partition gemountet ist und zum anderen wird nicht jeder Zugriff registriert.
[root@archlinux rocketmouse]# systemctl start auditd.service
[root@archlinux rocketmouse]# auditctl -w /run/media/rocketmouse/u1.1tmp -p rwa -k usbhdd
[root@archlinux rocketmouse]# echo "Wie finde ich heraus, was das Hochfahren bei nicht gemounteter Partition verursacht? Naja, vielleicht gibt es einen Hinweis, wenn ich es mit einer gemounteten Partition versuche. Danke" > /run/media/rocketmouse/u1.1tmp/auditd_test.txt
[root@archlinux rocketmouse]# ausearch -i -k usbhdd
----
type=CONFIG_CHANGE msg=audit(03/18/2013 13:47:00.781:2) : auid=rocketmouse ses=1 op="add rule" key=usbhdd list=exit res=1 
[root@archlinux rocketmouse]# touch /run/media/rocketmouse/u1.1tmp/foo.txt
[root@archlinux rocketmouse]# ausearch -i -k usbhdd
----
type=CONFIG_CHANGE msg=audit(03/18/2013 13:47:00.781:2) : auid=rocketmouse ses=1 op="add rule" key=usbhdd list=exit res=1 
----
type=PATH msg=audit(03/18/2013 13:55:03.509:3) : item=2 name=(null) inode=14 dev=08:21 mode=file,644 ouid=root ogid=root rdev=00:00 
type=PATH msg=audit(03/18/2013 13:55:03.509:3) : item=1 name=(null) inode=2 dev=08:21 mode=dir,777 ouid=rocketmouse ogid=rocketmouse rdev=00:00 
type=PATH msg=audit(03/18/2013 13:55:03.509:3) : item=0 name=/run/media/rocketmouse/u1.1tmp/foo.txt inode=2 dev=08:21 mode=dir,777 ouid=rocketmouse ogid=rocketmouse rdev=00:00 
type=CWD msg=audit(03/18/2013 13:55:03.509:3) :  cwd=/home/rocketmouse 
type=SYSCALL msg=audit(03/18/2013 13:55:03.509:3) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7fffdb0aaac5 a1=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a2=0x1b6 a3=0x7fffdb0a8f00 items=3 ppid=811 pid=996 auid=rocketmouse uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=1 tty=pts0 comm=touch exe=/usr/bin/touch key=usbhdd 
[root@archlinux rocketmouse]# ls -hAl /run/media/rocketmouse/u1.1tmp
total 24K
-rw-r--r-- 1 root root 185 Mar 18 13:53 auditd_test.txt
-rw-r--r-- 1 root root   0 Mar 18 13:55 foo.txt
drwx------ 2 root root 16K Mar  1 19:24 lost+found
-rw-r--r-- 1 root root   3 Mar 14 16:49 .no-spind.counter
Ich bin mir jetzt nicht sicher, ob ich das Problem genau erfasst habe, aber hast du mal deinen LCC gecheckt? Springt der überdurchschnittlich in die Höhe?
Dieses Problem hatte ich damals mit einer WD Platte, weil alle acht Sekunden der Lesekopf geparkt wurde, Linux aber alle 20 Sekunden zugreift und das Spiel so lustig hin- und hergeht. Da ich dort aber nicht wirklich merkte, dass die Platte "hoch und runter" geht, bin ich mir wie erwähnt nicht sicher, ob du dies meinst.
Falls dich das betrifft/interessiert: http://www.amazon.de/review/RPWF4KNFV23ZL
Den Link werde ich mir später durchlesen, danke.
auditd habe ich soeben gestoppt. Nachdem die Platte aus ihrem Schlaf wach geküsst wurde, hat audit nichts außer meinen Zugriffen angezeigt.

Wenn ich Linux nur zum root Prompt hochfahre, keine Desktop Environment Session starte, ist alles bestens, dies habe ich mit Ubuntu getestet, dass ebenfalls mit Xfce installiert ist. Für Suse mit GNOME2 ist es nicht anders als für Ubuntu und Arch mit Xfce und unter AV Linux mit Xfce findet alle paar Sekunden ein Zugriff statt, was die LED anzeigt, so dass die Platte nie runter gefahren wird.

Ich werde nun mal gucken was passiert, wenn ich thunar-volman, gvfs und tumbler entferne, soweit diese keine Abhängigkeiten für etwas anderes sein sollten.

Weitere Ideen sind willkommen 😉
Die sind definitiv Abhängigkeiten von tonnenweise Kram.

Hast du ein Temperatur-Applet oder sowas laufen? Die könnten auch auf die Festplatte zugreifen.
@ gridcol:
Siehe oben, #5 im 2. Code-Fenster. Dies ist eine EU-Verordnung für externe Laufwerke und kein Bug und ich kann es nicht deaktivieren. Gut zu wissen, dass man es kann, wenn die Platte nicht hinter einem USB-Controller ist, doch glaube ich nicht, dass es sich lohnt zu lernen, wie man einen DOS-USB-Stick einrichtet, nachdem das Linux-Programm es nicht deaktivieren konnte.

Da das Laufwerk neu ist und ich nicht weiß wie man das Gehäuse öffnen und schließen kann ohne etwas zu beschädigen, sollte dies überhaupt möglich sein, sehe ich im Moment keine Möglichkeit es ohne den USB-Controller betreiben zu können.

@ Creshal:
Nein, es ist ein noch kaum eingerichtetes Arch Linux und es wird auch kein unnötiger Service hinzukommen, da ich mit harter "Real-Time" arbeiten muss.

Du irrst Dich, es gibt keine Pakete, die abhängig von diesen Paketen sind.
[root@archlinux rocketmouse]# pacman -R thunar-volman
checking dependencies...

Targets (1): thunar-volman-0.8.0-1

Total Removed Size:     0.61 MiB

Do you want to remove these packages? [Y/n]  
(1/1) removing thunar-volman                                        [######################################] 100%
[root@archlinux rocketmouse]# pacman -R tumbler
checking dependencies...

Targets (1): tumbler-0.1.27-2

Total Removed Size:     0.98 MiB

Do you want to remove these packages? [Y/n]  
(1/1) removing tumbler                                              [######################################] 100%
[root@archlinux rocketmouse]# pacman -R gvfs
checking dependencies...

Targets (1): gvfs-1.14.2-4

Total Removed Size:     6.74 MiB

Do you want to remove these packages? [Y/n] 
(1/1) removing gvfs                                                 [######################################] 100%
Ralf schrieb danke, leider hat diese Methode 2 Haken, zum einen muss eine Partition gemountet sein, dass Problem tritt aber bereits auf, wenn keine Partition gemountet ist und zum anderen wird nicht jeder Zugriff registriert.
Man kann auch das Device der Festplatte oder das der (ungemounteten) Partition angeben. Ich habe mit audit auch keine Erfahrung, war nur hier darauf gestoßen.
gvfs hat das verbrochen? Hilfe! Ich sollte wohl doch mal von Thunar auf mc o.ä. umsteigen.
gvfs ist eh ein Verbrechen gegen die Menschheit. Das Ding ist ja nichtmal vollständig anwendungstransparent, ich hab noch nie Verstanden, was der Sinn sein soll, wenn ich die Dateien doch wieder auf den Desktop schieben muss, damit ich sie auch öffnen kann…
Creshal schriebich hab noch nie Verstanden, was der Sinn sein soll, wenn ich die Dateien doch wieder auf den Desktop schieben muss, damit ich sie auch öffnen kann…
„Aber gvfs ist so einfach!“ … typische Gnome-User-Verblendung eben. Keiner will den Scheiß ernsthaft nutzen.
maltem schriebgvfs hat das verbrochen? Hilfe! Ich sollte wohl doch mal von Thunar auf mc o.ä. umsteigen.
Creshal schriebgvfs ist eh ein Verbrechen gegen die Menschheit. Das Ding ist ja nichtmal vollständig anwendungstransparent, ich hab noch nie Verstanden, was der Sinn sein soll, wenn ich die Dateien doch wieder auf den Desktop schieben muss, damit ich sie auch öffnen kann…
Dirk schrieb
Creshal schriebich hab noch nie Verstanden, was der Sinn sein soll, wenn ich die Dateien doch wieder auf den Desktop schieben muss, damit ich sie auch öffnen kann…
„Aber gvfs ist so einfach!“ … typische Gnome-User-Verblendung eben. Keiner will den Scheiß ernsthaft nutzen.
Das was die Entwickler von Thunar dazu meinen ist leider auf Englisch:

http://mail.xfce.org/pipermail/thunar-dev/2013-March/004973.html

Der durchschnittliche Arch-Nutzer kann so ein Problem für sich selbst lösen, der durchschnittliche Computer-Nutzer, für Linux sind dies wahrscheinlich überwiegend Ubuntu-Nutzer, kann so eine Aufgabe nicht selbstständig lösen.
Dirk schrieb
Creshal schriebich hab noch nie Verstanden, was der Sinn sein soll, wenn ich die Dateien doch wieder auf den Desktop schieben muss, damit ich sie auch öffnen kann…
„Aber gvfs ist so einfach!“ … typische Gnome-User-Verblendung eben. Keiner will den Scheiß ernsthaft nutzen.
s/User/Developer/, die User hätten sicher nichts dagegen, wenn sie was funktionierendes hätten. 🙂
… da drängt sich mir doch die Frage auf: Sind die Developer auch User? Manchmal glaube ich, die Macher kommen nur sehr selten aus ihrem Elfenbeinturm heraus …
Bei Gnome frage ich mich das auch…