Hirdetés
- gban: Ingyen kellene, de tegnapra
- Mr Dini: Mindent a StreamSharkról!
- Luck Dragon: Asszociációs játék. :)
- btz: Internet fejlesztés országosan!
- juhi11: Karácsony esély, hogy észrevegyük: mások is valakik - még Isten is
- hege8888: Retro Kocka Kuckó harmadjára Hódmezővásárhelyen
- GoodSpeed: Munkaügyi helyzet Hajdú-Biharban: észak és dél
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Torda: Így lehet fillérekből prémium okosotthon rendszert építeni 2025-ben
Új hozzászólás Aktív témák
-
brd
nagyúr
válasz
fsb1000
#4099
üzenetére
Elméletben 4-8 K, esetleg 16 K-s stripe mérettel jársz a legjobban, a cluster size-t úgy beállítva, hogy egy-egy cluster a 2 (vagy több) háttértárolón legyen teljesen elosztva (vagyis minden cluster olvasása/írása egyszerre több háttértárolóról történhessen, ehhez az kell, hogy a cluster size annyiszorosa legyen a stripe-nak, ahány háttértárolóból áll a tömb). A sebességi sorrend, csökkenő sorrendben, szintén az elmélet szerint:
FAT16->FAT32->NTFS.
A gyakorlatban pedig valószínűleg a következő felálás hozza a legjobb eredményt az általad válaszott célra:
16-32-64 K stripe (32 K a legesélyesebb), 4-8 K cluster size, NTFS, rendszeres töredezettségmentesítés mellett.
Azért van így, mert maga az I/O parancsok átvitele terheli a gépet (az egybefüggő adatblokkok átvitele kevésbé, ezért ebből a szempontból jobb a nagyobb stripe size), és valahol valószínűleg szűk keresztmetszet lesz, ha nagyon kicsi lesz a stripe size. Ezért nincs mese, le kell tesztelni, az a biztos.
A filerendszerek sebessége meg ma már marhára nem számít (esetleg pagefile-t érdemes FAT16-ra tenni, ha az lesz az egyetlen file a partíción), egyedül az NTFS esetén +-ban ki lehet kapcsolni a Last Access Update-et (sok értelme amúgy sincs a funkciónak).
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest

