Jak Windows wybiera miejsce zapisu na dysku?


(XOR) #1

Zastawiam się na jakiej podstawie system Windows (ewentualnie inny system operacyjny) wybiera, w których wolnych sektorach dysku zapisać dane? Czy wybiera pierwsze wolne miejsce w kolejności czy jest to bardziej "losowy" proces?


(system) #2

Zależy, np FAT zapisuje w pierwszym wolnym licząc od początku dysku, dlatego powstaje fragmentacja. (nie dotyczy SSD + trim).

 

Możesz sam zaobserwować proces. Jakaś pusta partycja. Nagrać 100 pliczków, skasować co któryś i nagrać 1 duży.


(bachus) #3

Jak wspomniał Wredotka, zależy od systemu plików - te Windowsowe (FAT32, NTFS) zaczynają od pierwszego wolnego i tak zajmują miejsce.

@Wredotka: od kiedy nie ma fragmentacji na SSD i co ma do tego TRIM?


(system) #4

 

Chodzi o problem kolejkowania.

Zwykle jest tak, odczyt głównego katalogu, następnie zapis w wolne pozycje (ale po kolei w wolne dziury), nawet jak w czasie operacji zapisu wielkiego pliku system skasuje malutki na poczatku dysku to i tak wielki zostanie zapisany tak jakby tej operacji kasowania nie było.

 

Przy trim system uzyska natychmiastowo informacje o wolny sektorze i może tam to zapisać nie robi mu to różnicy w szybkości.

Przy HD nie robi się tego bo to wymusza ruch głowicy a to wiadomo spowalnia, zużywa itp


(kamil004) #5

Może inaczej

-Na SSD jest zawsze fragmentacja (pomijam jeden ciągły zapis na nowym dysku i nie większym niż jego pojemność)

-Na SSD fragmentacja plików nie ma żadnego znaczenia w wydajności odczytu i zapisu

co dziwne w przypadku pendrive ma, a niby zasada taka sama działania.

-SSD nie da się zdefragmentować, przeczy to logice samego dysku.

-Dysk bez Trimowanej “pamięci” działa wolniej. (widać to szczególnie na smartfonach) ponadto jeśli kontroler dysku SSD uzna że na tej i tej komórce trzeba coś zapisać a będzie ona nie ztrimowana to najpierw musi wykonać operacje czyszczenia jej i dopiero zapisać dane. Po to jest Trim aby kontroler nie musiał czyścic komórki przed zapisem i zrobił to szybciej.

 

Jeśli chodzi o główny topic to nie robiłem testów ale, czy faktycznie na HDD system/dysk zawsze zapisuje od pierwszego wolnego miejsca to się nie zgodzę.

inaczej w defragmentatorze nie było by porozrzucanych plików nie kopiując nic nowego ani nie kasując, tak czy tak da się to zaobserwować i moge zaryzykować stwierdzenie że robi to troszeczkę losowo z uwagą na pierwszy wolny sektor.


(cinkibolek) #6

To chyba zależy od sposobu tworzenia plików w programie. 

LPCTSTR lpfname = TEXT("d:\\test.tmp");
LONG lsize = 1000000000; 
DWORD dwErr;
HANDLE file = CreateFile(lpfname,
GENERIC_WRITE,
FILE_SHARE_WRITE,
NULL,
CREATE_NEW ,
FILE_ATTRIBUTE_NORMAL,
NULL);
dwErr = GetLastError();
if (dwErr 0) {
cout "Error Code: " dwErr endl;
}
SetFilePointer(file, lsize, 0, FILE_BEGIN);
SetEndOfFile(file);
CloseHandle(file);

Natomiast tworzenie plików programem Filler (akurat taki miałem pod ręką) zawsze powoduje defragmentacje.

 

Tutaj to znalazłem http://stackoverflow.com/questions/917309/how-can-i-limit-file-fragmentation-while-working-with-net


(bachus) #7

Wierutna bzdura powtarzana wszędzie jak to fragmentacja SSD nie wpływa na wydajność / czas dostępu do danych. Czas chyba na jakiś wpis na blogu o tym i o przykładach na podstawie baz danych, oraz kilka innych możliwości jak fragmentacja SSD znacząco wpływa na wydajność.


(Cedar) #8

Gdzieś coś było. I jeszcze “znacząco”

Pokaż to “coś”. Tylko wiarygodne a nie jak ten Twój wpis.


(system) #9

Co do fragmentacji SSD, to czy wpływa na wydajność czy nie, zależy od zastosowanej organizacji pamięci i w jaki sposób ma zorganizowany dostep do tej pamięci jego kontroler.

Ale to są tak futurystycznie małe wartości, że nie wyobrażam sobie aby to mierzyć w domowym piekarniku.

 

To jest takie samo stwierdzenie, że 4Gb ramu działa szybciej niż 32Gb. Bo działa szybciej, dlatego timingi są takie jak są. A wynikają z tego, że trzeba przełączać więcej banków.