Nem! A gyakorlat nagy átlagban nem ezt mutatja, hanem azt, hogy a jelenlegi SSD-k valamivel jobbak.

Az itt emlegetett dolgok, hogy elfelejti az adatokat mondjuk egy év után megintcsak olyanok mint a TBW, a gyártó megad mondjuk 1 évet arra, hogy ennyi ideig nem felejt az SSD, akkor sem ha nincs áram alatt. Csakhogy ez nem azt jelenti hogy egy év után elkezd "felejteni" az SSD, hanem hogy 1 évet garantálnak - azaz ha hamarabb felejt akkor az garanciális probléma. A gyakorlatban nem szoktak hamarabb felejteni, mint egy HDD, és ez is nagyban függ a hőmérséklettől, a garantált időtartam ráadásul viszonylag magas tárolási hőmérsékletre vonatkozik (nem emlékszem pontosan talán 50°C-ra) Szobahőmérsékleten tárolva, szerintem nem kell attól tartani, hogy elfelejti a tárolt adatokat, persze nyilván mentés azért kell, mert bármi elromolhat tároló típustól függetlenül is.

Van egy régi laptopom amit nagyon keveset használok, előfordult hogy több mint egy éveig be sem volt kapcsolva. Valami Lite-on SSD van benne, és eddig nem felejtett semmit, de mindjárt előkapom, mert megint eltelt vagy egy év, és nem ártana feltölteni az akkut sem néha

szoftver keresés

Sziasztok!
Nem gép probléma, de hátha valaki rögtön tudja a választ: Milyen szoftvert ajánlanátok redundáns fájlok keresésére? A Total Commander default tud ilyet használtam is már, de hátha ismertek kicsit szofisztikáltabbat ilyen célra.
Konkrétan azért kellene, mert megkértek rokonok, hogy tegyük már rendbe a számítógépet mert van nekik körülbelül 5-6000 fotó meg 120-130 rövid video, a gépben van egy rendszer 1Tb-s meg egy 512-es valamint még 1T-s elsődleges mentés HDD.
Mind lényegében tele van, de össze-vissza vannak bennük a könyvtárak, a könyvtárak a képekkel.
Durva áttekintés után találtam olyan "esküvői képek" könyvtárat, amit legalább 10 különböző helyen van lementve (nehogy az elvesszen felkiáltással), de összességében rettentő pókhálós a könyvtárszerkezet.
Ennek az összefésüléséhez lenne jó egy ilyen ingyenes program. (Van egy szintén 1T-s külső USB3 HDD, ez még üres....)
Köszi mindenkinek..

"és eddig nem felejtett semmit"

Az honnan derül ki számodra? Ugyanis a fájlrendszerek nem szoktak CRC-ket tárolni, csak a metaadatokhoz - vagyis a fájlrendszer saját dolgaihoz igen, a fájlok tartalmához nem. Így neked kell hash-eket vagy CRC-ket készíteni és időnként összehasonlítani, ha biztosan tudni akarod. A ReFS-en, ill. Linuxon a ZFS-en (és a Btrfs-en) kívül nem ismerek mást hasonlót.

A ReFS egyébként a Windows világának komolyabb, drágább fájlrendszere, és őszintén szólva, még nem láttam olyat, vagy legalábbis nem tudtam róla, hogy olyat használok. A ZFS néha nekem is eszembe jut (NAS-okon gyakori, ha minden igaz), mert idegesít hogy az ext4 nem képes észrevenni a fájlok tartalmának változásait. Nekem ugyan mondhatják ezerszer is, hogy az átlagfelhasználónak ez mennyire nem fontos... nyilván az alacsonyabb szintű védelmekre, a háttértárolók képességeire gondolnak olyankor. De a leírások szerint "nagy memória" kell neki - ennél tovább még nem jutottam, de biztosan van itt is, aki jól ismeri.

Amikor felírsz egy fájlt, szerintem mindegy, hogy honnan jön, vannak metaadatai és adatai, amikkel foglalkozni kell. A kettő közt HDD-n nagyobbak a távolságok, FAT-on nagyon nagyok, NTFS-en, ahol elosztva vannak a könyvtárbejegyzések, kisebbek. De ne tévesszen meg, néhány részletet ismerek még (régi szolgáltatás a "write-through", vagyis a buffered I/O kikapcsolása egy-egy fájl megnyitásánál), de nem tudom pontosan, mi zajlik...

Rendben, viszont meggyőzni magamat nem könnyű, azt én is látom. Ha egy másik fórumon nem győzködtek volna, akkor még a mostani, idei év elején épített gépemben se lenne SSD, még a rendszernek se. Sajnos megmaradt bennem, hogy az SSD írás-olvasási ciklusainak száma véges és előbb-utóbb elkezdenek problémák lenni a fájlokkal... (...)

Várjunk! Tulajdonképpen az okostelefonokban is "SSD" van, ha úgy vesszük, nem? A telefonomat anno használtan vettük, azóta többször is megtelt a memóriája képekkel, amit mindig kiürítettem, de még mindig nem lett ettől baja. | Tulajdonképpen akkor ehhez hasonlóan az SSD miatt se kellene aggódnom, nem?

Talán ha régebben kipróbáltál volna már egy SSD-t rendszermeghajtónak, rájöttél volna,
hogy francnak se kell többet HDD, nem hogy rendszer, de még adat meghajtónak sem.

Szerintem kezdjük elveszteni a fonalat mert még azt sem tudjuk pontosan, hogy mit is csinál valójában a PowerShell scripted, így azt sem tiszta, hogy mit és mivel hasonlítunk össze.

A PowerShell scriptet el lehet felejteni, az már az alkalmazási példája volt annak, amiről beszéltem: az operációs rendszerhez adott alapszoftverekről, alap fájltulajdonságokról, és mindez a hatékony fájlmásolás okán. Az xcopy a DOS-os időkből való, a robocopy-t az NT 4 óta adja a Windows-hoz az MS.

Én más véleményen vagyok, de ez így is jó.

Mert csak ezt a kis részt olvastad el... : -) Az alábbi lehetett a félreértés oka, hogy valami PowerShell-ben megírt különleges fájlmásolásról beszélek és nem az említett Windows alapprogramok használatáról: "Amikor felírsz egy fájlt, szerintem mindegy, hogy honnan jön, vannak metaadatai és adatai, amikkel foglalkozni kell. A kettő közt HDD-n nagyobbak a távolságok, FAT-on nagyon nagyok, NTFS-en, ahol elosztva vannak a könyvtárbejegyzések, kisebbek."

Talán idegenek voltak a kifejezések. Jó bonyolult folyamat egyetlen fájlt létrehozni, a tartalmának írása/másolása eltörpül a metaadatoké mellett, ami csak egy elnevezés a fájl nevére, attribútumaira, allokációira stb. A file system driver intézi. A HDD-nél még nagyon költséges volt az ugrálás a könyvtárak kezelése, SSD-n meg ott van már a “write at once” - nem tudok minden lépésről számot adni, én is annak örülnék, ha valaki fejből sorolná, de az optimalizáció nyilván nagyon fontos. Egy kicsit rosszul is írtam: a FAT fájlrendszernek is lehettek több helyen a könyvtárbejegyzései, de nem feltétlenül közel a fájlokhoz, csak lineáris listák voltak, nem bináris fák, mint a modernebbek, így sok-sok olvasással jártak stb. Az NTFS-ben van külön MFT, meg az “journaling file system”, így ott még napló is készül a változtatásokról (de nem a fájlok tartalmának változásáról), szóval sok az írnivaló.

A másik az volt hogy a minden fájlműveletnek az alapját képező Win32-es (igazából a Kernelbe lefutó, ott NtCreateFile névre hallgató) CreateFile API függvény használatakor is lehet trükközni: létrehozáskor vagy nyitáskor ki lehet kapcsolni a cache-elést (ami fájl-szintű), és azonnal a lemezre íratni az adatokat. Ezt sok kis fájl másolásánál ajánlják az említett utility-k. Ami elsőre kicsit visszásnak tűnhet, de olyankor jobban kézben lehet tartani, hogy mikor mi történik. A Shell-szintű fájlkezelést akkor muszáj használni, amikor Shell-kiegészítőben van elkészítve valamilyen virtuális fájlrendszer. Lehet egy tömörített fájl vagy egy felhős fájlrendszer könyvtárnézete. És lassú. Csak így nagyon hosszú lesz a hozzászólásom. : -)

Innen indultunk, ezt átlátom: “nem hiszem, hogy gyorsabb lenne mint a normál csomagméret maximalizált másolás akár Win intézőben, akár TC-ben mert itt a HDD fejmozgási ideje és az oda-vissza járó adat maga a lassú”, vagyis erre próbáltam válaszolni, hogy mi az, ami a javasolt módszer nagyobb mennyiségű fájl másolásánál, mióta létezik, miért lehet racionális, hol alkalmazzák stb. Még a Novell gyors hálózati fájlmásolójára is emlékszem, amivel a fájl tartalma közben még csak nem is érintette a munkaállomást... : -) Linuxon meg az rsync a bugylibicska.

Ismerem az adott két programot, csak nem használom őket soha. Arra gondoltam, hogy a script csak annyiból említendő, hogy meghív valamilyen utasítást valamelyik nevezett programból. Az lenne a lényeg, hogy mit mert az alapján lehet összehasonlítani az elvárt működést a valóban véghez vittel. Szerintem még mindig szilvát hasonlítunk a banánhoz mert ha a tiéd nem formáz akkor tkp. csak feleslegesen veszélyezteti az adatok épségét az ide-oda másolgatásukkal. Ha ráadásul ezt a HDD-n belül teszi akkor eleve ~feleződik a sebesség, plusz a rendszeres megszakítások miatt csak csak lassabb lehet, mint egy másik meghajtóra irányított, szektorról szektorra haladó, optimalizált másolás.

Vagy valamit nagyon elbeszélünk egymás mellett az alapvető információhiányból adódóan.

Egyébként azért nem mentem bele jobban a részletekbe mert egyrészt nem vagyok programozó, így a Windows low level API-k működésében nem vagyok otthon, másrészt a tényállás ismerete nélkül feleslegesnek érzem mert pl. HDD és HDD közt is óriási különbségek vannak: a hagyományos (CMR / PMR) HDD-kre kvázi direktben történik az írás a HDD RAM-jából, míg a modernebb HDD-ken A RAM-ból először egy cache területre (media cache) kerül (a tányérok külső részén, ahol a leggyorsabb a drive), majd (SMR HDD esetén, sorbarendezés után) onnan másolja át a hosszú távú adattároló területre. Hasonló az SSHD-knél, csak azoknál a cache a NAND-ban van. A cache kikapcsolásával pedig a drive a valódi sebességére lassul a tapasztalatok alapján.

Ráadásul az SMR HDD-knél nem olyan egyszerű a törlés / formázás mint egy hagyományos HDD-nél mert az SMR HDD-k ilyen szempontból SSD-ként viselkednek (ugyanúgy TRIM-elni kell őket mint az SSD-ket, ezért a törlési / formázási folyamat sem olyan egyszerű náluk mint a CMR / PMR HDD-knél).

Adat meghajtóknak inkább tartok HDD-t, jelenleg 2×HDD+1×SSD felállásban vagyok és így biztosabban érzem magam. Az viszont tagadhatatlan, hogy az SSD-nek hordozható eszközökben (pl. laptop) van igazán jelentősége (nem tartalmaz mechanikai alkatrészeket).

Klassz. Megértem, hogy szakmai szempontból túl sokrétű a HD-k és SSD-k működése egy-egy hiteles predikcióhoz abban, hogy mi hogyan fog alakulni performance szempontjából, hogy ilyen szép magyarul írjam, ill. az sem mindegy, hogy a driverek mennyire kezelik a drive-jaikat eltérően a Kernel szintjén, de ez a bonyolultság nem tegnap alakult ki, és úgy néz ki, hogy a magasabb rétegekben alkalmazott említett optimalizációs technikák a mai napig érvényesek. Még csak nem is én találtam ki őket. Ezt kell bizonyítani vagy megcáfolni - gondolni fogok rád, mikor legközelebb alkalmam-szükségem lesz ilyesmivel foglalkozni. : -)

"A cache kikapcsolásával pedig a drive a valódi sebességére lassul a tapasztalatok alapján." Nem veszed figyelembe, hogy ez egy hangsúlyozottan speciális esetre - és szintén a mai napig - alkalmazott, sőt egészen hivatalos leírásokban ajánlott eljárás sok nagyon apró fájl esetén, ez szintén nem valószínű, hogy elavult lenne.

Hogy mi miatt történhetnek a fentiek, arról próbáltam írni egy kicsit. Talán olyanokon lehet elcsúszni, hogy amikor a fájlrendszerbe való írásról van szó, ott vannak olyan kőbe vésett állapotok, bizonyos információknak a konkrét, fizikai rögzítése, felírása, amit egy-egy adott pillanatban kell biztosítani az integritás miatt, tehát sokkal kevésbé lehet a mindenféle op.rendszer- és alacsonyabb szintű cache-ekre támaszkodni, mint ahogy az ember naivan (tehát a pontos működést nem ismerve) gondolná - és az optimalizációt is befolyásolja (esetleg ettől maradhattak érvényesek korábbi eljárások).

Persze okoskodni könnyű, de nem ez az első ilyen helyzet, mikor két egymással kapcsolatban lévő szakterület valahogy mégis annyira távolinak látszik. : -)

Közben keresem magam ellen az információkat, most éppen megtehetem. Látod, ezt okozza a zárt forráskód, ezért áll az ember, mint a hülye egy mélyebb kérdésnél annak ellenére, hogy részemről a Kernel-szintű ismeretekből is akad azért:

"there is only basic information available on the allocation algorithm of the currently most widely spread file system; NTFS. We have therefore studied the NTFS allocation algorithm and its behavior empirically."

https://link.springer.com/article/10.1007/s11036-019-01441-1

Ezt 2020-ban írták, és ez még csak a fájlrendszer szintje. : -) De legalább hardware-független. A legalsó réteg, pl. a NVMe.sys viszont már vastagon az és nyilván még kevésbé hozzáférhetőek róla információk.

A metaadatok felírásáról egyébként pont az ellenkezőjét találtam: hogy döntően cache-eltek (és a journaling miatt így is megbízható az egész) - kivéve, ha külön megmondod, hogy mikor akarod őket fizikailag kiíratni a disk-re, _ha_ azon van olyan lehetőség, vagyis hajlandó rá... Sok a belső összefüggés.

Annak megállapításához, hogy a korábbi cache-elési technikák alkalmazhatók-e ma is, szerintem ezt az absztrakciót lehetne megvizsgálni, hogy ezek a Storage Controller Driverek milyen IOCTL hívásokkal működnek (ez a módja egy driver-rel való kommunikációnak, ez szokott dokumentálva lenni), tehát mennyiben különbözhet a különféle HDD-k és SSD-k kezelése - amiket te ismersz a másik oldalról. Ezek azok a területek, amiknek fejlesztésébe mindig is nagyon sok pénzért lehetett beszállni, már ha eredményt akart valaki elérni, ezen az sem segít, ha tudom, hogyan kell belekezdeni. Pl. ezért írnak inkább Shell-kiegészítőket, amik nyilván csak ezen a szinten működnek és messze gyengébb a teljesítményük. De itt abbahagyom, bocsánat.

Próbáltam átnézni a cikket de rögtön bele is futottam egy pótlandóba mert ők még a fix 12.5%-nyi MFT területről írnak, holott az már a cikk írásának az idejére is több lépcsőben gyakorlatilag korlátlanra lett emelve a drive kapacitásától függően. Illetve nem rémlik, hogy arról írtak volna, hogy NTFS-nél összekapcsolhatóak az MFT helyfoglalók, hogy nagyobb méretű bejegyzés számára is elegendő helyet biztosítsanak.

A RoboCopy / Xcopy témában annyit találtam, hogy alapvetően a fájlonkénti (metadata) overhead csökkentésével és többszálas futással optimalizálják a folyamatot, amivel gyorsabb lehet mint a szektorról-szektorra haladó szekvenciális másolás sebessége (bár a részleteinek még jobban utánanéznék).

"amik nyilván csak ezen a szinten működnek" - amik nyilván csak felhasználói szinten működnek (dll-ek a felhasználó folyamataiban főleg az Explorer-be betöltődve). Bocs.

Igen, ez biztos, hogy nagyon régóta léteznek a dinamikusan létrehozott MFT-k, legalábbis ezt a jelzőt emlegetik, az viszont szokták, hogy ez mennyire optimalizált. De a fix terület most is megvan a kötetek elején. Mintha még a méretét is befolyásolni lehetne. Csak ez sajnos nem segít azokban a "számításokban", amikről beszéltünk.

A többszálasságot szokták a legtöbbször leírni, mivel command line kapcsoló is, a "hogyan"-ról már megint több szó esik, mint a "miért"-ről, de nem közlik, hogy ez valami belső optimalizációt is tartalmaz-e olyan értelemben, hogy valamit egyszerre csinálnak a szálak és egyszerre lépnek tovább egy következő tevékenységre, vagy egyszerűen azért történik több másolás egyszerre, hogy a CPU minél kisebb eséllyel legyen bottleneck, mivel a mai drive-oknak nem számít, hogy több helyre kell írni, vagy még jobban is működnek... Ehhez most vagy már nem tudok értelmeset hozzátenni, sőt kétségeim vannak, hogy ha egyszer a file system driver működése nem hardware dependent, csak a legalsó rétegé, akkor vajon hogyan lehet minden optimális minden drive-val, de még nincs vége... : -)

Ilyenkor általában a Linux kódok szoktak segíteni, igazából még NTFS driver is van, méghozzá jó, egy darabig naponta használtam írás/olvasásra, de nyilván nincs benne minden trükk. : -)