Az, hogy igy csinalod evek ota, es hogy barbar dolog-e, nincs osszefugges. :)
Az umount kotelezo automount eseten is. Egyreszt azert, mert a sync kiirja a filesystem cache-t, de nem zarja le a nyitott fileokat. Igy egy alkalmazas lazan file szintu korrupciot hozhat ossze.
"Apro" kulonbseg meg, hogy a sync-et vegrehajtod ugy is, hogy nyitott fileok vannak a filerendszeren, de az umountot alapeseten nem.
Tovabba a syslog szepen megmondja, de majdnem biztosan fsck fut a hatterben.
Az automount pedig jelenleg particio UUID alapjan mountol. Ha barmi osszekeveredett, akkor az vagy nagyon regen volt (bugok akadtak eleinte szep szammal), vagy keresztbe turkaltal valamit, vagy megvaltozott az uuid, ami az almoskonyv szerint sok jot nem jelent.
A KDE-t nem ismerem, de tudtommal beallitas es drive beallitas/kepesseg fuggo, hogy kiadasra kerul-e a spin-down a kde "umount/eject" vonalon.
Valamelyik ablakozo rendszerben raadasul mindket opcio szerepelt.
Az eject - umount az osszes particion, ami a disken van es lekapcsol.
Az umount - adott fs umount-ja.
Amit akkor lattam, hogy ha umountoltad az osszes fs-t a disken, attol meg a lekapcsolast nem csinalta meg.
Az meg mar udev/powersave opcio megintcsak, hogy nem hasznalt diskeket lekapcsolja-e es mennyi ido utan. Ezt termeszetesen megintcsak tamogatnia kell a disknek.
(Nalam volt kulso, 3.5 colos, 1TB-os disk, ami nem volt hajlando leporogni, mert a doboz firmware-jeben ezt letitolttak anno.)
Tehat a kerdessel sikeresen osszemosasra kerult legalabb 3 dolog:
- tud-e a disk ilyet
- a kde megfelelo opcioja mit csinal
- mi az udev/powersaving opcio
Amugy 10+ ev usb disk tapasztalat, hogy ha umountolsz es utana szepen kihuzod az usb kabelt, akkor nem tortenik semmi gaz a diskkel.