Zašto disk rošta kad započne skidanje torenta?

Ja i dalje tvrdim isto što i na početku, nikakve nule se ne upisuju niti ima potrebe za tim prije upisivanja stvarnog sadržaja datoteke, to mi govori zdrav razum i poznavanje osnova i bez guglanja. Te dvije sličice govore isto što sam i ja napisao, da su sparse datoteke podržane samo kod NTFS5. Kao što rekoh, niti sparse datoteke niti te sličoce nemaju veze sa pitanjem čitatelja i temom.

Te dvije sličice ti govore da su sparse datoteke podržane od Windowsa 2000 naovamo, od NTFS-a verzije 3.0 (koji su neki označili kao NTFS5 jer je došao uz Windowse NT 5.0, tj. uz Windowse 2000). Trenutna verzija NTFS-a pod Windowsima 10 je 3.1, znači to je novija verzija od "NTFS5". Drugim riječima, sparse datoteke su pod Windowsima podržane već 19 godina.

A što se tiče zapisivanja nula, uTorrent prealocira datoteke tako da u njih zapiše onoliko nula koliko datoteka mora biti velika i time uzrokuje roštanje na exFAT i FAT32 particijama, jer one ne podržavaju sparse datoteke. Evo, samo radi tebe napravio sam još jedan test - krenuo sam skidati istu ISO datoteku na prije spomenuti USB stick. Prvo sam ga formatirao NTFS-om - uTorrent je na njemu kreirao datoteku velične 1,28 GB u roku nekoliko sekundi. Zatim sam ga formatirao exFAT-om, a uTorrentu je sad trebalo minuta i 6-7 sekundi za kreiranje datoteke veličine 1,28 GB ispunjene nulama.

uTorrentovo izravno manipuliranje FAT tablicom ili MFT-om samo kako bi se stvorila datoteka određene veličine slučajnog sadržaja (koji je uvijek "slučajno" samo same nule!) je ničim potkrijepljena tvoja izmišljotina. A sad, ti možeš ostati pri tome, pa vjerovati u krivo, ili možeš prihvatiti iznesene činjenice pa biti informiran.  Meni ni iz džepa, ni u džep. Ja ti ni ne kažem nek mi vjeruješ - ne vjeruj mi nego isprobaj, provjeri, testiraj je li ovo što sam napisao istina. Pa ćeš sam sebe uvjeriti da je istina. Umjesto da uporno ponavljaš izmišljotinu. Not cool bro.

Opet ponavljam isto, da je podržan samo kod NTFS5 (nisam rekao samo NTFS5.0, a NTFS5.1 je samo podverzija od NTFS5 i logično da je podržano). Isto nisam rekao koliko godina. Kad sam ja to radio npr. u NTFS, nije bilo podržano.

Ne koristim uTorrent, nego Transmission u Linuxu koji je puno bolji tako da neću probavati.

Ako uTorrentu treba 6 sekundi, još uvijek nije dokaz da potpuno bespotrebno fizički upisuje prvo nule pa onda stvarnu datoteku.

Ako to ipak zaista i radi, to je potouno glupo i nepotrebno.

prvo sparse...

recimo bitan dio..

Support for sparse files is introduced in the NTFS file system as another way to make disk space usage more efficient. When sparse file functionality is enabled, the system does not allocate hard disk drive space to a file except in regions where it contains nonzero data. When a write operation is attempted where a large amount of the data in the buffer is zeros, the zeros are not written to the file. Instead, the file system creates an internal list containing the locations of the zeros in the file, and this list is consulted during all read operations. When a read operation is performed in areas of the file where zeros were located, the file system returns the appropriate number of zeros in the buffer allocated for the read operation. In this way, maintenance of the sparse file is transparent to all processes that access it, and is more efficient than compression for this particular scenario.

- a sad jedan primjer, npr kompresiran disk, ili laičko objašnjenje kako radi zip-lzv tj file kompresija (prosjčeno 1.6 omjer za exe.. dok je txt na 90% slike i sl je skoro beskorisno).

npr zip, ili kompresija u letu, tad se traži ponavljanje. Možemo reći x ili nula ili slovo.. no recimo 'x' i tad je recimo sadržaj txt filea ovo: xxxxxxx.. npr 10 komada ili 1000.. i kako to možemo efikasno 'kompresirati'? pa tako da napišemo x*1000 tj odgovarajući broj. i taj file će tad zauzeti 1000 puta manje (osim header-eof-a..) nego originalan + formula pa to nije 1000 nego recimo 950 puta manje kao banalizirano objašnjenje. Istu tehniku koristi FS, tj prikazuje-barata fileom što kažu 'transparentno' tj izgleda kao da je to file no rezultat prikazuje iz bufera tj formule koja ga je kreirala i zato vidiš tisuču znakova x mada ne postoje tj postojat će kad se file stvarno zapiše tj tad neće biti iksići nego stvarni sadržaj a do tad je to samo privid-trik tj podatak iz buffera, ne iz filea. Tj ono što se snimi se ažurira u popisu sadržaja ili ono kad se gledaju zelene crtice u torrentu ili kockice defraga.. :)

-kako to FS zna? pa zna, jer on vodi brigu o tome, tj on alocira, on prikazuje.. no stvarni sektor-blok-cluster je i dalje s onim sadržajem-byteom koji je bio prije snimljen i može ga se pročitati-spasiti, tj nije stvarno revritan kao što bi to radilo sec.earse dodanje ... tj to je trik, FSa i to na ntfs-u dok fat taj trik ne podržava i tad nema druge nego stvarno napraviti ono što fs traži tj snimi sadržaj jednako kao što to možeš bilo što programski npr dir>file.txt ili što već želiš u fileu fornextom itd. .. i upravo to test s ntfs i fatom demonstriraju tj ono što radi fs ovisno o fsu medija tj privid koji mi i appsi vidimo kao file.

-odnosno točno je da nema stvarnog zapisivanja tj na način kako bi to inače file radio.

-alokacija je samo alokacija, kao inicijalizacija varijable dim-x .. koji je tad empty odnosno možemo mu postaviti vrijednost što se naziva inicijalizacija no može jednako ostati empty čak ovisno o jeziku (vc-vb-vj..) do dodjele tipa varijable pa može tad postati string ili num ili objekt... (dok se u starim pravilima kod dimenzioniranja određivao i tip varijalble npr dim a as string ili as integer.. tj ovisno o strogoći jezika-kompajlera koji može inzistirati na deklaraciji i inicijalizaciji varijabli kao urednog koda). itd. :)

Možemo ponavljati do u nedogled i ja ću ostati pri svome, ti pri svome. Ako bilo koji program (uTorrent, Transmission, XY) prvo upisuje fizički nule u datoteku na disku, pa tek onda sadržaj datoteke to je potpuno nepotrebno duplo upisivanje i apsolutna glupost. Nema baš nikakvog razloga da to netko tako implementira.

 Prvo ja znam osnove i siguran sam da na fizičkom nivou nema duplog upisivanja podataka. Ti brkaš kreiranje datoteke i upisivanje na disk. Datoteka se kreira tako što je kreiraš u particijskoj tabeli, to isto radi i računalo automatski i mikrokontroler ručno. Nema veze sa fizičkim upisivanjem same datoteke nulama ili jedinicama. Time je rezervirana ili alocirana i drugi programi gledaju samo particijsku tabelu i vide da je zauzeto, ne gledaju binarne fileove na disku jesu nule ili jedinice. Upisivanje na disk slijedi i ono je potpuno neovisno jel imaš na postojećim fizičkim lokacijama samo nule ili ne. Zato nema nikakvog razloga prvo upisivati nule pa onda datoteku, osim ako ne želiš što da disk stari duplo brže.

Zamisli da na disku imaš video u kojem se je*eš s bivšom. Našao s novu curu, ne želiš da ona to vidi jer to baš nije ugodno i može imati negativne posljedice na vezu. Video si izbrisao (nebitno jesi li prije negdje backupirao, za slučaj da nekad poželiš baciti dr*icu na bivšu). Cura ti kasnije dođe i stavi skidati seks i grad, doći će joj frendice pogledati. Slučajno se potrevilo da se koristi isti kodek ko na tvojem kućnom uratku i da se fizička lokacija na disku preklapa. Međutim, nestalo je struje i jedan segment videa nije skinut. Kako tvoja cura nije informatički potkovana, nakon dolaska struje i paljenja računala ne pali torrent client za provjeriti da li je download dovršen, već direktno upali video misleći da je završen (a nije ti uključena opcija da dodat !ut ekstenziju u tom slučaju). Ona i frendice gledaju seks i grad, kad odjednom, na pola filma, malo kockica, pa se nakratko pojavi verzija filma bez slova "r" u imenu, kako će te ona i njene frendice od tad početi nazivati, a ti ćeš proklinjati neupisane nule.

Što se tiče zbrke s nazivima, nikako ne može biti točno da samo NTFS5 podržava sparse file, i to iz više razloga:

1.) NTFS i NTFS driver nije isto. NTFS5 ne postoji, pa ne može biti jedini koji podržava sparse file. Podržavaju ga NTFS 3.0 i 3.1

2.) Ako pričaš i driveru, ni to nije točno jer je trenutni popis verzija drivera koje podržavaju sparse file: 5.0, 5.1, 6.0, 6.1, 6.2, 6.3 i 10.0, bez naznake da bi se u budućim verzijama mogla podrška ugasiti

3.) Semantički, dvosmislenost - nije ispravno reći da je podržan samo u NTFS3 jer to dvosmisleno. Kad postoji više podverzija, onda se stavlja oznaka .x, pa bi bilo ispravnije reći NTFS3.x

4.) Semantički, impliciranje - ako kažeš da je nešto podržano samo u verziji 3 ili 3.x, onda to implicira da postoji novija verzija u kojoj je podrška ukinuta ili je takva verzija najavljena. Ispravno je reći da je nešto podržano od verzije 3, od verzije 3.0 ili u verziji 3+, ali onda to ne ide u paketu sa riječju samo.

Zaista si se bezveze raspisao (ako misliš da si s porno primjerom ispao cool ok neka ti, ja to ne snimam), a da nisi pročitao što sam napisao. Ovdje se vodi rasprava jel se podaci upisuju duplo u FAT32 (nema veze sa sparse fileovima niti NTFS5 ili NTFS3 kako želiš). Ja tvrdim da se ne upisuju duplo podaci na fizički disk (prvo da se ispune nulama pa onda stvarnom datotekom), kolega tvrdi da dolazi do duplog fizičkog upisa na disk. Naravno da će se pri upisu datoteke upisati sve nule i jedinice (FAT32!) tako da neće ostati nikakvi dijelovi prijašnje datoteke. Za to nema nikakve potrebe upisati prvo sve nule pa onda datoteku preko toga.

Ukoliko radiš samo formatiranje, binarna datoteka će ostati fizički na disku manje ili više razbacana i može se sastaviti pomoći posebnog softwarea. Kod SSD-ova postoji 'trim' komamda te je nešto teže, ali tema su mehanički diskovi.

p.s.

Kad kažem V5 ili V3 podrazumjevam i sve podverzije (ne kažem samo V5.0 ili V3.0), ali to nema ionako nikakve veze s temom.

Ne brini za curu, neće moći otvoriti nedovršenu datoteku i vidjeti to što si snimao prije jer je tako označena datoteka. Nedovršena se može otvoriti u torrentu, a torrent će prikazivati samo dijelove koji su "skinuti", a ne stare fileove koji su na nedovršenom dijelu.

Mbaxa govori da se ne može stvoriti datoteka, ako se prvo ne upišu fizički sve nule. Ja tvrdim da je to nepotrebno i da se to duplo fizičko upisivanje u datoteku normalno ne radi, potpuno neovisno jel se sekvencijalno upisuje ili ne. Ako torenti to rade, nek rade, tehničkog razloga za to nema.

Ti sada navidiš potpuno drugi, sigurnosni razlog. Moguće, ali tvoji prijašnji podaci su ionako ostali na disku nakon brisanja (kako i sam kažeš), te su jednak sigurnosni rizik.

Financijska izviješća i šifre će u VLC-u biti ionako nešto bezveze sve kada bi nedovršen file i mogao otvoriti - a ne možeš.

Tako da ne vidim neku sigurnisnu prednost u duplom upisivanju.

Na SSD disku ti oupće ne možeš pročitati što se stvarno nalazi na disku, jer će "prepoznati" da se radi o nekorištenom dijelu i prikazati ti sve jedinice (ili nule) iako u stvarnosti fizički NIJE tako. Zato je i rekonstrukcija nakon brisanja u SSD-u teža, ali ne nemoguća.

Dobro objasnio si mi da je V3 a ne V5, strašno bitna stvar koja ionsko nema veze s temom kao niti cijela priča oko sparse datoteka.

Ima i ljudi koji tvrde da je hashiranje lozinki nepotrebno, pa je danas ipak sigurnosni standard.

Na FAT sustavu ne možeš stvoriti datoteku te veličine bez upisivanja nula. To je jednostavno točno. Razlog za to je ograničenje drivera, ne samog filesystema, ali to ne znači da je ta tvrdnja prestala biti činjenica.

Ako zaobiđeš driver, onda možeš stvoriti takvu datoteku, međutim, kao i tvoj primjer s undelete-om, za zaobići driver i, općenito, pristupiti disku u raw formatu (bilo u svrhu manipulacije filesystemom ili u svrhu čitanja raw podataka), trebaš imati privilegije. Na kvalitetno dizajniranom OS-u, userland aplikacija takve privilegije nema. Ona može kreirati datoteku isklkučivo putem drivera i dobiti će zerofill ako napravi rupu pomicanjem pointera, što je bitna sigurnosna značajka.

Što se tiče samog sustava, on i dalje traži zapisivanje - kod svih FAT sustava, svaki sektor sadrži adresu sljedećeg (povezani su u chain). Fizički je nemoguće kreirati datoteku bez da u svaki sektor upišeš adresu sljedećeg, odnosno EOF oznaku u zadnji sektor. S ozbirom da je sektor uvijek sekvencijalan, kad disk zapiše header sektora, upisivanje nula u ostatak sektora ne predstavlja gotovo nikakav overhead, pogotovo ako će disk nastaviti pisati na sljedeći sektor, što se prealokacijom na FAT sustavu također nastoji ostvariti.

 Zašto je sada bitno koliko sekundi? Nisam ja mjerio, nego pročitao šta je čovjek napisao koji je mjerio.

mbaxa:

"Zatim sam ga formatirao exFAT-om, a uTorrentu je sad trebalo minuta i 6-7 sekundi za kreiranje datoteke veličine 1,28 GB ispunjene nulama."

Nemam nikakav članak, imaš ti?

Nisam ništa googlao niti tražio kao što već rekoh, nego je to način kako sam to sam implementirao (bez računala) i sve je izvrsno radilo. Imaš naredbe npr. IDE sučelja, koristiš ih i sve radi bez ikakve potrebe za duplim zapisivanjem. Tehnički nema prepreka za to. Kako to pojedini OS implementira to je druga stvar.

Otkud to da je situacija gdje nije bitno, dapače. Sve rađeno po IDE standardu i sve super radi kada se disk ubaci u računalo.

 Kolega je rekao da ne može biti 6 sekundi nego preko minutu, pa sam mu kopirao da ne kaže da lažem. Jel to problem? Ako je copyright problem, ispričavam se. I ja sam njega pitao zašto je to bitno? I jesu tih 6 sekundi zaista problem čitatelju u pitanju? Mislim da nisu i da mu to ne predstavlja problem.

I ja sam kolegu pitao da mi pošalje link ako ima.

Da, implementirao sam za NTFS. I da nema potrebe da se duplo upisuje (100%) iako si ti tvrdio da se tako mora. Sada navodiš nestanak struje kao razlog.

Take it easy :-)