USB HDD leválasztás, leállítás

KDE

A minap beszereztünk egy 2 terás WD MyPassport darabot. Rádugva a gépre nem a leggyorsabban, olyan másfél perc alatt csatolódik fel (ext3-ra formáztam, nem tudom számít-e, a témába biztosan nem vág). Ez még nem lenne akkora gond, de leválasztva, majd kihúzva, később visszadugva már nem mindig akar mountolódni.

Valószínűsítem, hogy az oka a leválasztás utáni nem leállítás, amit az évekkel korábbi rendszerek tudtak. Konkrét emlékem egy Linux Mint-ről van Gnome2-vel, ahol a leválasztás mellett ott volt még a leállítás opció is, ami le is kapcsolta az energiát, és a külső HDD szépen le is állt.
Mostanában unmount után pörög a lemez, majd tulajdonképp ki kell rántani, ami (szerintem) egyáltalán nem jó.
Az eddig használt HDD-k valahogy elbírták, bár valószínűleg azoknak sem tett jót.
Xfce-ben volt már rá megoldás, de nekem (illetve a hölgynek aki majd használja) Linux mint és KDE alatt kellene.
Ha nem is ez az oka a fentebbi nem mountolásnak, akkor is hasznos lenne ez az opció.

Hogyan lehetne megoldani felhasználóbarát módon?

( ak0sh | 2015. 03. 08., v – 02:58 )

A Nautilus szépen leválasztja, majd kikapcsolja a külső vinyókat.
A Palimpsest próbáltad? (más néven Gnome-Disks – igaz, nem KDE-s)

( aga_et v | 2015. 03. 08., v – 12:12 )

Megnézem 'udisks --detach' vagy 'hdparm -y' mit tesz.
Pontosabban udisks --unmount /dev/sdbx && udisks --detach /dev/sdb

Illetve találtam még két scriptet itt (hat éves..) és itt.
A gond inkább az, hogy ezek nem grafikus felületen kattintgatható cuccok, így nem is igazán felhasználóbarát. El tudom magyarázni a hölgynek, hogy ezt így meg így, de nem fog neki tetszeni. Pedig ez a safety remove nem egy nagy kérés. Amúgy is leáll egy idő után a nem használt HDD.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

( locsemege v | 2015. 03. 08., v – 12:22 )

A másfél perc csatolási időből egészen másra gondolok. Szerintem a vezetéken történő feszültségesés miatt állandóan brown-out reset-elget a HDD, és sokadjára sikerül neki a művelet. Lehet, logokat kellene nézegetni, szerintem abból látszania kell, ha így van. Tehát az egész úgy instabil, ahogy van.

Mindig alaplapba közvetlenül ültetett USB csatlakozóba dugd az eszközt, lehetőleg igen rövid 'Y' kábellel.

Meglátásom szerint az umount után már nincs jelentősége, hogy hogyan veszed el a HDD tápját. A "kiadás" használata célszerűbb, mint az "eltávolítás"-é, gondolj arra az esetre, ha több felcsatolt filerendszer van egyazon fizikai eszközön.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha 3,5"-os lemez, annak van külön tápja(12V)
Ezt nem közölte a kérdező.
Ezért sem áll le ha csak kihúzod az usb kábelt, mert a tápfesz megmarad.

A tv-nél próbálkzásom usb hubbal emiatt nem jött be, mert csak akkor állt le a lemez
a tv kikapcsoláskor ha közvetlenül a készülék usb portjára csatlakozott.

a megoldás egy script lehet, desktop ikonnal,
ami sync-et és leállítást is megoldja.
Erre talán rá tudnak kattintani! :)
a sync adatvesztés miatt, pl. hogy ne félig másolt fájl legyen a lemezen.

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

A sync csak javítja az esélyeket, de nem korrekt megoldás. Kell az umount. Gondolj bele, mi van akkor, ha sync alatt van nyitva írásra file, vagy közvetlen utána nyitják meg. Tény, hogy a disk cache flush-ölése sokat hoz a dolgon a korábban írt file-ok vonatkozásában.

Azért üzemszerűen a tranzakciós naplóból helyreállítani a filerendszert elég perverz.

Persze, ha úgy érted, umount előtt legyen sync, az nem baj, mert sikertelen umount esetén - pl. timeout - jobb helyzetet eredményezhet, mint nélküle.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"ha úgy érted, umount előtt legyen sync,"
igen.
Én terminálon mielőtt kihúzom az usb dugeszt mindig beírom.
Ártani nem árt. :)
Olyasféle mint win alatt a "biztonságos eltávolítás".
Nem lesz sérült/olvashataltlan fájl, ami történetesen mindig
akkor derül ki mikor olvasni akarjuk. :)

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Anélkül, hogy az umount forrását nézegetném szerintem ezt csinálja:

- elérhetetlenné teszi az alkalmazások felől a filerendszert
- kiírja a szükséges metaadatokat
- üríti a disk cache-t a fizikai eszközre
- visszatér

Jó, nagyon leegyszerűsítve, de a mondandóm lényege, hogy kizártnak tartom, hogy az umount ne flush-ölje a disk cache-t, mert ha nem tenné, akkor szinte felesleges is volna.

Tehát szerintem nem igaz az állításod, hogy umount, és a disk cache flush-ölése, hiszen az umount ezt már tartalmazza.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Na most elbeszélünk egymás mellett.
Én az umount parancsot nem használom, csak a sync-et és a promt visszatérésekor kihúzom a kábelt.

Mivel teljesen auto csatlakozik minden drive, amit bedugok és az umounthoz root jog is kell(ene) ilyen esetben(vagy fuse, de az még egy láncszem ami hibát adhat), meg volt már rá példa hogy kissé összezavarodott ez az automount "rendszer" a külső belenyúlásokkor. Bent maradt a media könyvtárban
de halottan a csatolás és csak reboot segített.
Ezért inkább nem piszkálom ezt a részt, így jóm műxik. :)

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Értem, csak így nem igazán korrekt. Pláne manapság nem értem, amikor GUI-ról intézhető sima felhasználóként minden. Na, nem mintha ne lehetne sudoers file-t szerkeszteni visudo-val, meg scriptet írni, meg ugye van gvfs is, szóval megoldható minden. Végső esetben a root password begépelése is megoldható. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nincs sudo, akkor hogyan lehet egyes parancsokra root jogot megengedni? A sudo, /etc/sudoers szerintem nem rossz dolgok, bár magam is kerülöm, ha lehet.

A csak sync-kel az a bajom, hogy a filerendszer továbbra is elérhető, azon file nyitható, így még naplózó fs esetén is lehet adatvesztés. Arról nem is beszélve, mennyire disznóság a kernellel szemben, hogy minden előzmény nélkül kihal alóla a block device, amelyen egy vagy több filerendszere volt.

Az fs legközelebbi csatolás alkalmával tartalmazza, hogy nem tisztán lett lecsatolva, így fsck-t kér magára, és így tovább. Szóval ezt eléggé barbár megoldásnak gondolom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Az fs legközelebbi csatolás alkalmával tartalmazza, hogy nem tisztán lett lecsatolva, így fsck-t kér magára, és így tovább. Szóval ezt eléggé barbár megoldásnak gondolom."

Már több éve így csinálom, pendrive, usb hdd, telefon ...
Még nem kért fsck-t egyik drive sem.

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Szerintem ez filerendszertől is függ. FAT-nél mintha lenne erre flag, ext4 biztosan tudja. Nekem az egyik pendrive-omon a két filerendszer egyike FAT, másika ext4. :) Ha jól tudom, fstab bejegyzéstől függ, legyen-e ellenőrzés. Gondolom, az fstab-ban nem szereplő fs-ek esetén valami policy lehet erre, de meg nem mondom, hogy hol. Udev, systemd?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

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.

A disk tud ilyet, mert ha nincs használva, akkor egy idő után leáll.
KDE a felirat alapján „Safety remove”-ot csinál, logban meg sem találtam csak annyit, hogy „USB disconnect 8”.
Udev/powersaving-ről sem tudok semmit, nálam udev alatt nincs ilyen. Amúgy már hülye vagyok ezekhez, anno egyszerűbb volt számomra, mostanában az is szokott zavarni, hogy /run/media alatt van minden. Pl. pár hete, amikor elkezdték nagyon szidni a systemd-t, akkor vettem észre, hogy vagy egy éve használom.
Ha megmondod mit-hol keressek, lehet megtalálom.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

"Tovabba a syslog szepen megmondja, de majdnem biztosan fsck fut a hatterben."

# cat /var/log/syslog|grep fsck
#

"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."

Nem turkáltam semmit!
Nem szokásom elrontani ami működik! :)
Valószínú bug volt, mert mostanság jól megy.

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Másik, frissebb rendszeren már gyorsabb. A cucc két napos, így nem lehet megtörve az amúgy elég speciális kábel. Nem külső tápos, hanem 3.0-ás USB. Amúgy rohadtgyors. A kábel csatlakozóján egyben és egymás mellett van egy micro és egy nano (?) usb csati. Elég érdekes, mert vannak ilyenek itthon, de külön. A lassú csatolás oka inkább az, hogy 2.0-ába van dugva, abban a laposban még nincs 3.0 USB.

De mint írtam, nem ez a legfontosabb. A safety remove egy gombbal viszont igen.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Ezzel tisztában voltam. A lassú csatolás oka ez lehetett. Pl. fileműveletnél, ami jellemzően másolás, olyannyira leterheli a lapos akksiját, hogy hálózatra kell dugni, mert különben használhatatlanságig lassul a gép. 2 terás külső vinyót már csak 3.0-val lehet kapni, az a lapos pedig nem olyan régi, kb. 3 éves. Enyémben is csak egy 3.0 USB csati van, pedig ez olyan másfél éves.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Egy picit nem értem mit írsz. Mi köze a sebességnek a villamos terheléshez? Közvetve persze lehet úgy, hogy a gép igyekszik spórolni villamos energiát. A másik, hogy USB 2.0 host interface-ből szerintem 500 mA-t vehetsz ki, utána a védelem nem engedi.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Picit utánatúrtam, az 1TB-os verzióban egy teszt alapján WD10TPVT diszk van. Annak az áramfelvétele csúcsban 900mA. Mégjobban turkálva a neten a 2TB-os verzióról az derült ki, hogy abban WD20NMVW diszk található, amiről leírást nem, csak fotót találtam, amin áramfelvételre 750mA szerepel: http://epelmart.com/images/all/WD20NMVW/aa.jpg
Szóval az egy darab USB2-ból megtápolás kevés lesz neki.

A leírás és a tapasztalatok alapján megy 2.0-val is, csak sokat fogyaszt. Nem tudom mi van benne, nem szándékoztam szétszedni. Elég nehéz és viszonylag vastag, Kb. mint a Silicon Power Army-m, de annál a hosszában és szélességében kisebb. Mintha 2 2,5 colos HDD lenne benne egymáson.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

A 2TB-os diszk esetén nagyon esélyes, hogy a fotón látható típus van a dobozban - ugyanis ez a típusszám kifejezetten ebbe a termékbe készül - legalábbis amit találtam infó, az erről szól.
Elvileg megy, de az USB2 áramkorlátozásánál magasabb (maximális) áramfelvétele (nagyobb fogyasztása) miatt egy USB2-es portról nem garantálható (azaz bizonytalan) a működése.
Nem véletlen, hogy a nagyobb USB2-es diszkeket Y-kábellel (egyikben táp+adat, másikban csak táp van bekötve) adják.

Meglehet, semmi értelmes infó nincs róla a WD honlapján. Még képekkel is csínján bántak, a csatlakozó alig látszik. Itt az egyik blogban pont belinkelték az USB3 micro3 „madzag” csatijait, pontosan ugyanilyen van hozzá.
Ahhoz képest, hogy nem garantálható az áramfelvétele, egész stabilan működik, a korábbi samu HDD, ami csak 2.0-ás USB-s sokkal instabilabb volt, nagyobb mentésnél sokszor megállt. Az sima micro USB-vel kommunikált.
Az SP Army-hoz Y kábelt adtak, de egy kisebb elrejtve az oldalába nem az, és azzal is működik.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Érdekes, én a reggeli kávé elkészülte alatt kerestem rá, és találtam infót, most ne keressem meg újra...
Nem az áramfelvétele nem garantálható, hanem a maximális áramfelvételt szabvány szerint nem kell tudni a egy darab USB2 portnak kiszolgálnia. LEHET, hogy működik, mert az adott USB2 port mögött nincs meg/magasabbra van állítva az áramkorlátozás, de attól még lehetnek általad észre nem vett, túláramból adódó rövid kiesések. Ezt meg na'on nem szokta szeretni a diszk.

Amúgy az a szép h. ez az Y kábelt a HIVATALOS szabványban tiltott:

https://en.wikipedia.org/wiki/USB#Power

Some devices, such as high-speed external disk drives, require more than 500 mA of current[88] and therefore may have power issues if powered from just one USB 2.0 port: erratic function, failure to function, or overloading/damaging the port. Such devices may come with an external power source or a Y-shaped cable that has two USB connectors (one for power and data, the other for power only) to plug into a computer. With such a cable, a device can draw power from two USB ports simultaneously.[89] However, USB compliance specification states that "use of a 'Y' cable (a cable with two A-plugs) is prohibited on any USB peripheral", meaning that "if a USB peripheral requires more power than allowed by the USB specification to which it is designed, then it must be self-powered."[90]

--
WP8.x kritika: http://goo.gl/udShvC

Nem tartom kizártnak, hogy a fenti WD-ben kisebb fogyasztású disk van. Eleve 5400-as, nem 7000, vagy 10000. Azt is nehezen hiszem, hogy a WD egy olyan komolytalan, szánalmas cég lenne, aki belehazudja az USB 2.0 támogatást az eszközébe.
Ebből a 3.0 microUSB kábelből sem valószínű, hogy a van Y kábeles.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Az általad megjelölt eszközbe (több helyről megerősített adatok alapján) WD20NMVW gyártói típusszámmal bíró diszk kerül - ezt a típust kizárólag ebbe a dobozba építik bele - és ennek a diszknek a csúcsárama 750mA.
Az USB2 támogatás nem belehazudás, hanem lefelé kompatibilitás. Ahogy egy USB2-es eszköz működik USB1.1-es lukba dugva, úgy az USB3-asok is képesek USB2-vel kommunikálni - viszont senki sem mondta/mondja, hogy elegendő nekik (mert egy USB3-as eszköznek nem a 2.0-s, hanem a 3.0-s csatlakozón kivehető villamos teljesítményhatárnak kell megfelelni!) az USB2 alacsonyabb Imax értéke.

Keresztkérdés: van-e az eszközhöz gyárilag csomagolt USB2-es kábel?

Azért ez nem ennyire egyszerű. Ugyanis egy USB eszköz nem vehet fel "engedély nélkül" 100mA-nél többet a tápból. Azaz úgy néz ki a történet, hogy az USB interfész feljön, rajta elkezdenek beszélgetni, a host meglátja, hogy jé, ő többet akar, mint 100mA, no, akkor engedjük meg neki. Na ezután kapcsolhatja be a nagyobb fogyasztókat a készülék. Ha a motor tápfelvétele nem menedzselhető, akkor gyakorlatilag el sem indulhat USB2.0-án, mert sosem fog akkora engedélyt kapni, ami neki elég lehetne. Én azonban azt gyanítom, hogy ezek az okosok áramkorlátosra építették a motor tápját, és ha csak 500mA-re kap engedélyt (USB2.0-án ugye ez a legnagyobb, amit kaphat), akkor ennyiből fog gazdálkodni. Aminek az eredménye a perces motorindulás... hiszen a forgáshoz már elég a 2.5W, a speckó szerint ugyanis <=2W elég neki működés közben, nyilván csak induláskor enne többet.

Nincs hozzá semmilyen más kábel, csak a valahol itt már linkelt micro3-3.0 USB. Viszont a dobozán, a weboldalukon, és minden webáruházban is ki van hangsúlyozva a 2.0 kompatibilitás.
Amit itt felettem vl írt, egy teljesen logikus működése lehet az eszköznek.
A tulaja azóta rakott már rá olyan másfél terányi backupot 2.0-án keresztül, mindenféle probléma nélkül. Ami hiba lehet, azt itt már leírtam; Lassabban csatolódik fel, írási folyamat közben akkuról érezhetően sokat fogyaszt. Ezekkel viszont együtt lehet élni.
Az egyik első művelet az NTFS legyalulása ext3-ra volt. Azóta mintha gyorsabb is lenne.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Azaz USB2-re kötéshez nem adtak kábelt. A kompatibilitást meg ki lehet írni, hiszen az usb3 felülről kompatibilis vele - a tápellátást viszont oldd meg, ahogy tudod.
Lassabban csatolódik fel - mert a felpörgetésnél csak alacsonyabb áramfelvételre van lehetőség. Autós hasonlat: Csak félig nyomhatod a gázt, és úgy gyorsulj fel adott sebességre. Tovább fog tartani, mintha padlógázzal gyorsíthatnál.

Ezt a közvetve dolgot egyszer már itt is megtárgyalták. Még az sem mindegy mekkora táppal van használva a lapos. Kicsit más jellegű személyes tapasztalat, ha valaminél erősen használom az Nvidia GPU-t. Pl. játéknál ez igen látványos, akksiról igen hamar elkezd akadozni, be-beszaggat, fél másodpercekre megáll, rádugva hálózatra megszűnik. Sőt, ha nem 90W-s tápot használom, csak egy 60W-osat akkor is gyengébben, akadozva fut.
Ígyhát igen, akkuról igyekszik spórolni a gép, mindegy melyik perifériáról van szó. Ez néha ugye zavaró.
☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

( BehringerZoltan | 2015. 03. 08., v – 20:11 )

Hm... az előlapi usb csatin nálam akkor is van kakaó ha a gépet egyébként kikapcsolom - pörög tovább a rádugott vincsi. (Gondolom, h azért van így, h lehessen vele tölteni usb-s aksikat.) Abban bízom, h KDE-s leválasztással tulképp minden szükséges műveletet megtörténik, elemeli a fejeket is a lemezektől és így a madzag kihúzásakor már nem tehetek kárt. Nem volt vele gondom sosem.

"elemeli a fejeket is a lemezektől "

Az már rossz lenne, ha elemelkedne! :)
Parkoló pályára húzza.

Nem tudom hogy az újabb super, automount, hald, stb hogyan kezelik a biztonságos leválasztást.
Erre rá kell keresni!
A régebbi appok pl. usbmount configjában szerepelt a sync és sok más mount opció.
Pendrivenál nem szerencsés a sync mount, legalább is ez volt a módi.
Mert így több írást szenved el a chip.
A technológiák fejlődnek, vélhetően ez is már a múlté, de ha az ssd-re gondolunk, még ott sem
annyira nyerő a sok írás(cache, log, swap, stb)
Ezért használom cli inkább leválasztás előtt, mint hogy adatvesztés legyen.

............
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)

Akkor van egy rossz hírem: kb. amióta IDE diszkek vannak (azaz sacc/kb. >20 éve), azóta a diszknek két állapota van: pörög, vagy nem pörög. Olyan nincs, hogy biztonságban van a fej, de pörög a motor... akkor tolja be a fejet, ha elindult a motor, és akkor húzza ki egy rugó, amikor leáll a motor. És azért rugó, hogy ha elmegy az áram, akkor se maradjon bent.

( Nextra | 2015. 03. 31., k – 18:32 )

Nekem még van olyan pendrive-om melyen van led és villog ha adatforgalom van. De sajna már nem igen lehet ilyeneket beszerezni. Nos azt vettem észre hogyha egy nagyobb fájlt másolok fel a penre, és a program kiírta hogy végzett, és rámegyek az ummonutra akkor még jó sokáig villog a led, és ha már nem villog, csak akkor írja ki hogy most már kiveheted az eszközt.

A 3,5-ös dokkolóm meg nem veszi el a feszültséget hiszen ott is van egy folyamatosan világító led.
Úgyhogy én inkább leválasztom, majd kikapcsolom a dokkolót, és csak akkor veszem ki a lemezt.
De igen nagyot szokott ilyenkor kattanni a vinyó. Emlékszem a dokkoló előtt mikor még ugyanezek a vinyók egy USB rackban voltak, akkor azok umountnál az áramot is levették, és szép csendesek voltak a leállások.

Van egy Samsung 1,5 terás vinyóm is mely amint fel van csatolva rögtön elkezd darálni. Mintha ilyenkor leltárt vagy listát készítene magáról. S ha végzett, akkor elcsendesül. Aztán amikor idle állapotba kerül és újra hozzáférés történik, akkor megint kezdi elölről a darálást. Még vadiúj korában is ezt csinálta. Amúgy 2009-es HDD, és azóta is hibátlanul működik.
Ezt csak érdekességképpen említettem meg. De gőzöm nincs hogy ezt miért csinálja.

Elvben, ha mar vegzett az umount es kiirodott a disk cache, eleg csak kihuzni a diszket, mert mind az USB mind pedig a SATA tamogatjak a hotswapet. Egyebkent tudtommal a parancssori umount nem is ter vissza addig, amig nincs kiirva minden a diszkre (elnyom egy 'sync'-et is), csak a grafikus feluletek ennyire benak, hogy nem birtak egy varakoztato ablakot osszeutni hozza.
--
Blog | @hron84
Üzemeltető macik

Na ez az, amit a Windows csinal, es nem jo. Tul sokat lattam mar turelmetlen embereket, akik azt hittek, azzal, hogy kiadast nyomtak, mar huzhatjak is ki. Az arcukba kell tolni, hogy "meg nem jo, meg mindig nem jo, meg most sem jo, oke, kihuzhatod", kulonben csak kitepkedik.
--
Blog | @hron84
Üzemeltető macik

Az elvvel nem értek egyet, mert a felhasználónak nem feltétlen dolga tudni, melyik alkalmazás, milyen céllal, mikor nyit meg file-t, s azt melyik filerendszeren van, amely melyik block device-on, vagy akár többön - pl. LVM - van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A linuxnak sokszor tovább tart mint várnánk míg "kitolja a fizikai eszközre a disk cache-t", mert még egy mount vagy sync kiadásakor sem iródnak ki azonnal (azzal a sebességgel amit az USB/diszk lehetővé tesz) az adat a diszkre vagy pendrivera.
Gyors kiadásra optimalizált eset lehetne a mount flush vagy sync opciója. Ez adott eszköz/csatolási pont esetében az fstabban megadható, de hogy lehet beállítani ilyen opciót minden USB-s eszközre/csatolásra (Debian/Ubuntu alatt)?

Kapcsolódó infók:
https://askubuntu.com/questions/122113/copy-to-usb-memory-stick-really-…
https://askubuntu.com/questions/353792/incomplete-file-transfers-to-usb…
--
Légy derűs, tégy mindent örömmel!

Ha valami roossz ötlet az pendrive esetén a mount sync opciója, hacsak nem az a cél, hogy mielőbb tönkretedd a pendrive-od.

       sync   All I/O to the filesystem should be done synchronously.  In  the
              case  of  media with a limited number of write cycles (e.g. some
              flash drives), sync may cause life-cycle shortening.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az a baj, hogy nem tudom. Ugyan lehet a részhalmaza, még értelme is van, hiszen egy file törlése, filelista lehozása is módosítja a diratime-ot. Gondolom, ennek kiküszöbölésére lenne a nodiratime, mert ugyanaz a terület módosulna igen sokszor.

Viszont fogalmam sincs, hogy a noatime része-e a nodiratime, vagy csak ezt gondoljuk róla.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Aha. Tehát a noatime mind a file-ok, mind az alkönyvtárak hozzáférési idejének módosítását tiltja, míg a nodiratime csak az alkönyvtárak esetében teszi ezt.

Azaz úgy van, ahogy mondtad. A nodiratime részhalmaza a noatime-nak.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Végül is nem a lecsatolás a gond, hanem az időigénye. Pl. a lecsatolás előtt 20 perccel pendrivera másolt fájlok kiírása a cache-ből az eszközre a lecsatolás kezdeményezése után néha még 2-3 percet vagy többet is igényel, úgy hogy ebben a 2-3 percben néha van olyan hosszabb (pl. félperces) időszak ami alatt a pendrive írás jelző ledje nem világit.
Lehet hogy ezt nem a mount sync opciójával kellene kezelni, hanem elérni hogy a kernel amint van lehetősége írja ki az adatokat a cacheből az eszközre (így kiadáskor a cache adott részét egyszerűen eldobhatja hisz már ki van írva).
Jó lenne tudni, hogy ehhez mely kernel paramétereket hogy kellene beállítani.

Elgondolkodtató: https://rudd-o.com/linux-and-free-software/tales-from-responsivenesslan…
--
Légy derűs, tégy mindent örömmel!

Én nem vagyok annyira türelmetlen, hogy ostobságot csináljak. Lecsatoláskor megvárom, amíg feljön a buborék az üzenettel, hogy már vihetem a pendrive-ot. Hasonlóképpen megvárom a szabad jelzést vasúti átjáróban, s nem gondolom azt, hogy majd lepattan rólam 116 t mozdony. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A lecsatolás megtörténtét és annak visszajelzését megvárva, ha csökkenthető a lecsatolás ideje (mert előbb vagy gyorsabban történik a cache kiírása), akkor miért ne, hisz adatvesztést nem okoz.

Windows alatt beállítható hogy az USB pendrive használat gyors kiadásra legyen optimalizálva. Linux alatt ennek a megoldását keresve először a mount sync opciója kerül elő, a találatokban az fsync, flush block device cache, vm dirty ratio jönnek elő de a szükséges paraméterekről, beállításokról leírást nem sikerült találni. A talált alábbi kapcsolódó linkek szerint a dolog nem triviális, de lehet hogy csak rosszul kerestem...
https://blogs.gnome.org/cneumair/2006/02/11/ioctl-fsync-how-to-flush-bl…
http://artipc10.vub.ac.be/wordpress/2011/05/27/linux-performance-improv…
--
Légy derűs, tégy mindent örömmel!

Értem, bár attól függ, mi a szempont. Nekem nincs kedvem új pendrive-ot venni, így kifejezetten örülök, ha sokáig disk cache-ben van az adat, mert ha újra változik, mielőtt kiíródna, akkor csak egy írás lesz belőle. Ezzel kíméli a pendrive élettartamát, illetve kevesebb futásidő lesz ez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE