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?
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.
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?
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
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.
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
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ść.
Gdzieś coś było. I jeszcze “znacząco”
Pokaż to “coś”. Tylko wiarygodne a nie jak ten Twój wpis.
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.