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

IDE je standard za komunikaciju s diskom. Ti možeš na disk pisati raw podatke bez da imaš ikakvu logičku strukturu u vidu particija i filesystema, to je i dalje u skladu s IDE (odnosno, da budemo precizniji, ATA) standardom, što je u skladu s IDE standardom, a primjenjivo za slučaj diska koji radi u nekom uređaju specijalne namjene i nema potreba direktnom pristupu disku putem računala ili se u slučaju takvog pristupa koristi specijalizirani software.

Ako programiraš neki kontroler koji će koristiti standardni filesystem, onda nije bitno ako ćeš odstupiti od standarda tog filesystema sve dok znaš koje posljedice mogu biti i da iste neće utjecati na sigurnost i pouzdanost, te da će disk biti u "čistom" stanju kad ga ubaciš u računalo. Znači, ako si ti programirao neki mikrokontroler da zapisuje na disk koji služi samo tome, te evenutalni prethodni podaci su ionako samo prethodni podaci tog uređaja i nije bitno ako ostanu na disku, to odstupa od standarda, ali za taj scenarij nije bitno. Iako ne vidim zašto bi unaprijed uopće alocirao veći file jer ne vidim scenarij u kojem bi to bilo korisno.

Međutim, ako radiš u višekorisničkom okruženju u kojem aplikacije nemaju pravo direktnog raw pristupa disku (osim ako se radi o dijelu OS-a ili specijaliziranim alatima koji zahtjevaju privilegirani mod rada), onda je nulliranje unaprijed alociranog prostora pod must (iz razloga koji ti je već ukazan na temi), te se o tome brine driver ili systemski API (što ti je također već pokazano na temi).

Ono što tebe tu vjerojatno buni je upravo to u alociranje unaprijed. Kad pišeš u file normalno, pišeš u buffer, flushaš podatke na disk, te se ti podaci zapišu direktno na disk, bez pisanja nula prije i tu stvarno nema potrebe za pisanjem nula. Međutim, ako pomakneš pointer, ti API-u kažeš "ej, ovaj mi prostor treba, ali u njega ću pisati kasnije", u tom slučaju će API napraviti jednu od dvije stvari:

- ili će na taj prostor upisati nule, ako se ne radi o sparse fileu (sparse file mora biti podržan i zatražen)

- ili će, u slučaju sparse filea, taj prostor u lookup tablici samo označiti da sadrži nule

Ako taj segment pokušaš čitati prije nego u njega pišeš, dobiti ćeš nule, i to iz dva razloga:

- sigurnosni, koji smo ti već objasnili

- konzistencije - uvijek se nastoji da sve operacije imaju poznati rezultat

 Da IDE/EIDE (preciznije verzije ATA standarda) je to što kažeš, ali mora raditi i kada se stavi u računalo sa svom logičkom strukturom i datotečnim sustavom (inače bi bilo trivijalno i beskorisno za ovaj slučaj) što je kod FAT32 naravno još lakše nego kod NTFS.

Ukoliko pristupam samo mikrokontrolerom mogu i bez alokacije (jer samo jedna aplikacija pristupa) u FAT32 npr. naći nekorištene lokacije ispisati datoteku preko postojećih podataka (bez ikakvih nula) pa tek na kraju upisati podatke u tablicu i datoteku "stvoriti" naknadno da bude vidljiva windowsima jer je npr. nepoznata veličina datoteke koju upisujem. Ima još puno detalja ali je nebitno da ne davim više.

 Tako je, moje pitanje je bilo jako jednostavno. Utvrdili smo da se na NTFSu 1.28 GB formira trenutno. Isto tako smo utvrdili da se na FAT32 ta ista radnja odvija kroz minutu i 6 sekundi. Sve je nebitno osim pitanja "Što se to točno odvija tih minutu i 6 sekundi na FAT32?"

Hvala na razumijevanju.

Eto, napokon dolazimo do dijela koji ti nije jasan i zbog kojeg lupetaš gluposti.

Prealokacija ne znači ono što ti misliš da znači - da sektor označiš kao pripadajući datoteci prije nego u njega kreneš pisati. To nije prealokacija, to je standardni način rada.

Prealokacija je kad kažeš "trebati će mi 1000 sektora za ovu datoteku, ali sadržaj koji će tu ići još nemam", pa onda te sektore označiš da pripadaju datoteci, što kod FAT32 znači da ćeš u header tih sektora napisati adresu sljedećeg, dok ne dođeš do zadnjeg u čiji header stavljaš oznaku EOF, dok je kod NTFS-a to organizirano drugačije i ovisi o tome da li podržava sparse file ili ne. Sadržaj takve datoteke bi trebao, prema standardu, sadržavati nule. Kod OS-a, to radi file API/FS driver.

Naravno, ako alociraš sektor u koji odmah pišeš podatke, nećeš prvo pisati nule, pa onda stvarne podatke, ali to nitko nije ni tvrdio. Tvrdnja je bila da ćeš pisati nule (implicitno) isključivo ako ćeš unaprijed alocirati sektore u koje nećeš odmah pisati podatke.

 rade, samo što se sada zovu wd blue

model wd20ezrz caviar blue koji imam u kompu isto radi na sporih 5400rpm, negdje sam čitao na recenziji da je to zapravo stari wd green

vrlo malo se čuje i vrlo rijetko, dok mi je recimo prijašnji blue od 1tb bio poprilično glasniji

nešto ima u tome što je hd isključivo storage, windoze su na ssd-u, igre na drugom ssd-u i hd je uglavnom isključen

Da, upisuje se u tablicu samo ne na taj način kako si napisao da za svaki napišeš sljedeći i na kraju EOF. Ali to su već detalji pa nije ni rbitno.

 Po kojem standardu se moraju upisati nule? Kako taj standrad odlučuje šta je odmah, a šta ne? Hvala.

(ovo sa upisivanjem za svaki sljedeći bi na taj bilo prilično neefikasno kako sam rekao, a na fizičkom nivou ne postoji EOF u tablici niti ti to treba u tablici)

 Aj momak, boga ti draga, skuliraj se više. Nemaš ti  pojma ni čitat, a kamoli prenosit informacije iz postova od jučer.

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

Ovaj detalj tebe jebe još od jučer, jer sam odmah shvatio da MINUTU nisi ni primjetio. Dakle, ponavljam ti moje pitanje, ignoriraj sve osim čistog odgovora na pitanje: Što to disk drlja MINUTU i nešto sekundi na FAT32 particiji, ako ne zapisuje nule?

Hvala.

 Ne, želim da mi ti odgovoriš, jer uporno tvrdiš da znaš bolje od svih. Molim te, pojasni onda u jednostavnim rečenicama, da i ja mogu razumjeti, što to disk melje minutu i 6-7 sekundi na FAT32? 

Hvala.

ja sam isao na full retard mode, HDD je tolko zvrndao da je na kraju visio na SATA kablu i kablu od napajanja, bez ikakvog kontakta sa kucistem. nes ti meni zvrndat vise

 Pa upisuje nule na sam disk. To se već toliko puta ponovilo da sam čak i ja skužio o čemu se radi...Samo u slučaju Fat32 i exFat naravno.

Ako stvarno nakon svega i dalje tvrdiš da su oni rekli 5-6 sek onda mi je jasno zašto i dalje tupiš po svome i ne prihvaćaš činjenice koje su ti toliko puta i toliko lijepo pojašnjenje, zato jer jednostavno ne čitaš uopće niti jedan odgovr nego samo piliš po svome bez obzira što tko piše.

 Pa da, to je tvoja filozofija, ne zanima te ništa šta drugi pišu, ne zanimaju te činjenice, nego ti tupiš po svome i furaš dalje. Super.

Hvala na odgovorima.

Pričamo o FAT sustavu u kojem svaki cluster ima svoj zapis u tablici. Vrijednost upisana u tablici može biti iz raspona specijalnih vrijednosti (prazan cluster, bed cluster, kraj filea, plus neke rezervirane vrijednosti) ili broj sljedećeg clustera u lancu koji sačinjava file.

Da, EOF kao takav u doslovnom smislu ne postoji u tablici, već je službeni naziv EOC - end of chain. Veličina filea ne mora biti djeljiva s veličinom clustera, pa je stvarni kraj filea negdje unutar zadnjeg clustera u lancu, što je opet samo jedan implementacijski detalj o kojem ne ovisi ova priča.

S jedne strane od sugovornika tražiš linkove na specifikaciju, tehnički egzuaktno izražavanje, a s druge strane, lupaš gluposti bez pardona i pokrića, tvrdiš da je mbaksa napisao jedno, iako si i sam citirao i vidljivo je da piše drugo...

Začudo, Wikipedia taj dio pokriva na vrlo razumljiv način: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Cluster_map

S obzirom da, primjerice FAT32 koristi 4 byte-a, te da se koristi little-endian, to u prijevodu znači da je 04 00 00 00 adresa sljdedećeg clustera, te da je ta vrijednost 0x00000004

Vrijednost 0x0FFFFFFF, u tablicu zapisana kao FF FF FF 0F znači da je to kraj chaina.

Oćeš sad stati lupati gluposti bez pokrića?

 -ponovo, sparse-ntfs, dok fat32 nema taj fičer.. to je FS (ne sam os ili normalna app jer os može koristiti razne fsove kao što app može pristupati rawdisku itd.).

disk će se tad ponašati ovisno koj fs se koristi mada može biti npr izmjenjivi-vanjski usb stikić i možemo ga jednako koristiti na raznim osevima i appsima dok će se ponašati ovisno o FSu.