Is HDD onder AHCI uit de caddy halen zonder ejecten veilg?

[PostHEX]

Ik heb het proberen op te zoeken maar tot nu toe geen straight-up antwoord kunnen vinden (of misschien stel ik niet de juiste search queries). Met AHCI ingeschakeld, neem ik aan dat het verantwoord is om een HDD fysiek te verwijderen zonder 't OS eerst te laten weten dat er een opslag station wordt verwijderd -- simpelweg omdat er geen eject icoon voor die drive is en AHCI hot-swap ondersteunt -- maar ik wil het graag zeker weten. Dus mijn vraag; Is HDD onder AHCI uit de caddy halen zonder vooraf ejecten veilg voor de data op de schijf? Ik bedoel, raakt de data niet corrupt?

[jan99999]

http://www.maximumpc.com/forums/viewtopic.php?t=100051

Denk dat je het beter niet kunt doen.
Ik weet dat sata hotswat zou moeten ondersteunen, maar dat niet alle moederborden dit goed ondersteunen.
Misschien toch eerst de pc uitzetten,
of bij hardware de hd uitzetten kun je proberen.
Misschien kun je via de register de schijf in je usb lijst krijgen, vroeger waren er problemen omdat alle schijven hier in gingen staan.

Of probeer de hd aan te sluiten via een externe aansluiting indien dit snel genoeg is. usb3.0 bijv.

En je kunt nog zoeken naar een flush command om de cache leeg te maken.
En misschien de cache uitzetten zodat niks in het geheugen blijft staan, nadeel is denk ik wel dat dit langzamer is.

[ Voor 25% gewijzigd door jan99999 op 23-03-2014 12:55 ]

[leonbong]

Ahci maakt natuurlijk niet elke sata aansluiting hot swap.
Dus je aansluitingen moeten echt die functionaliteit hebben anders gaat het geheid mis.
Daarnaast is veilig ejecteren bedoelt om alle schrijfacties af te sluiten om dataverlies te voorkomen.

[PostHEX]

De Gigabyte Z68XP-UD3 ondersteunt hot-swap/hot-plug. PC uitschakelen om HDD te verwijderen met AHCI ingeschakelt is overbodig. Ik weet zeker dat de SATA poort die ik nu in gebruik heb voor de caddy dit ondersteunt. Het hot-swappen op zich is geen enkel probleem. Maar het gaat mij meer om het per sé of niet per sé op OS niveau moeten ejecten voordat ik de schijf fysiek verwijder.

Twee contextuele vragen:
#1
Ik gebruik de meeste HDDs als media dump stations. Dus een keer schrijven, heel veel lezen. Als ik dus een HDD in de caddy schuif om toegang te krijgen tot de media, en puur alleen om media te lezen, maar nadat ik klaar ben met lezen de applicatie waarmee ik de media heb gelezen afgesloten is -- zou er dan nog een scenario kunnen voordoen waarom het toch niet verantwoord is om een schijf af te koppelen zonder te ejecten? Zo ja, waar moet ik dan aan denken waarom dit dan het geval is?

#2
Stel als ik een schijf in de caddy wil pluggen om vervolgens data naar de schijf te gaan schrijven, en waarna ik klaar ben met de schrijf sessie ik de applicatie sluit waarmee ik data heb geschreven (bijvoorbeeld met een download manager) en ik vrijwel zeker weet dat er geen andere schrijf acties op de HDD nog afspelen, is dan ook in dit geval het verantwoord om de schijf fysiek te vewijderen zonder te ejecten?

Ik hoop dat m'n vragen logisch overkomen. Ik doe m'n best.

[RaZ]

Wat denk je wat de koppen doen op de platters als een schjif 7.200rpm gaat en je rukt dat ding er uit? Dan kunnen de koppen de platters raken, en de schijf slopen... De schijf dus eerst down gooien, dmv een eject, en de koppen gaan van de platters af, de schijf stopt met draaien, en dan uitnemen...

[spone]

Een schijf met een read-write filesystem gemount moet eerst een sync krijgen voordat deze ge-eject wordt. Punt. Komt namelijk doordat er (tenzij echt read-only gemount, en dat is iets anders dan 'geen bestanden erop zetten') *altijd* changes zijn, zoals bijvoorbeeld bijgewerkte access times e.d.

Enige uitzondering is dat je iedere vorm van write caching uitzet voor de schijf (in Linux heet is geloof ik de mount-optie sync), onder Windows delayed writes/caching. Maar daar wordt je schijftoegang echt ontzettend traag van.

Nu is mijn ervaring (op servervlak) dat NTFS beter tegen dit soort filesystem mishandeling kan dan bijvoorbeeld ext3 of ext4 (als in corrupte filesystems met bijbehorende corruptie en dataverlies), maar zoals hierboven al genoemd: niet doen en gewoon netjes ejecten.

Betekent overigens niet dat het nooit goed kan gaan hoor. In essentie doen veel mensen hetzelfde met een USB stick.

[PostHEX]

@RaZ
Kwa spin down is er geen probleem lijkt me. Je voelt de schijf totaal niet meer draaien wanneer 't deurtje van de caddy volledig open is. Ik weet niet op hoeveel toeren het dan nog door draait, maar zeker onder de 5000 (edit: ik bedoel niet in de buurt van de 5000, maar zeker onschadelijk laag). Hoe dan ook, ik wacht altijd een aantal seconden wanneer ik de schijf volledig uit de caddy haal.

Maar over dat punt. Om te testen heb ik net een HDD met USB enclosure even ge-eject. Bevinden was echter dat de schijf gewoon nog vrolijk door draaide.

@Spone
Over read-only, goed punt. Totaal niet aan gedacht. Misschien moet ik daar maar eens naar gaan kijken. En ja over write caching uizetten. Had 't een en ander gelezen en dat moet je niet willen.
(For the record voor wie deze thread in de toekomst tegen komt: http://blogs.msdn.com/b/o.../2013/04/16/10411267.aspx )

Bedankt.

[ Voor 4% gewijzigd door PostHEX op 24-03-2014 00:27 ]

[spone]

Nog 2 dingetjes:

- Waarom wil je perse niet ejecten? Omdat je de disk niet ziet in je popupmenu? Volgens mij kan je dat per SATA poort instellen via een BIOS instelling. In elk geval op mijn GA-Z87-HD3 wel.

- Via diskpart kan je een readonly vlaggetje voor een volume instellen. Ik denk dat ie dan volledig readonly gaat, maar dat durf ik niet heel hard te zeggen.

[PostHEX]

Twee redenen dat ik hier mee kwam
-Gemakzucht. Als iets niet per sé hoeft of vermijden zou kunnen worden, then why bother.
-Om meer te weten te komen over de do's en don't's op dit gebied.

Als dat zou kunnen om eject optie per SATA poort in te stellen zou ook handig zijn. Zal ik zeker morgen naar kijken. In de nabije toekomst wil ik upgraden naar een 3 in 2 caddy (http://www.icydock.com/goods.php?id=157), zou super zijn om dan per bay specifieke instellingen te kunnen gebruiken.

Maar de read-only suggestie is denk ik precies wat ik voorlopig zoek.