Új hozzászólás Aktív témák
-
félisten
"akkor sem működik, ha az utolsó partíciót kicsivel a 2 terrás határ előtt akarom létrehozni?" ha nem, akkor miért nem?
Nem, és azért nem amit írtam...A 3Tb-os példád esetén sem tudod kivitelezni, mert csak 1 db 1,5 Tb-os partíciót tudsz majd létrehozni, meg még 1 db 500GB-osat...
A Rocko66 által linkelt példákkal meg nem kell foglalkozni, mert az USB-s meghajtó és mindenféle hibás adatokat lehet USB-ről beolvasni, mindenféle zöldségeket ad vissza a firmware (nézd meg az első képet, ott szerinte 11MB a szabad terület, a foglalt meg 0MB. Pont ennyire értelmetlen az MBR is, mert nem az)
Az USB-s meghajtók firmware-je emulál bizonyos dolgokat, hogy olyan OS "alatt" is lehessen használni, ami amúgy nem is támogatja a pl GPT-t (pl XP sem támogatja semmilyen formában sem a GPT)
Nagy kapacitású meghajtókat (2TiB-nál nagyobb terület is felhasználva) csak speciális particionálással (gyártó adja), jumpereléssel és/vagy szintén gyártó által mellékelt driverrel/utility-vel lehet elérni.
Ilyenkor a meghajtó "hazudik" az OS felé, mert nem tehet mást, de ez nem azt jelenti, hogy az XP kezeli a GPT-t, mert erről szó sincs.[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
félisten
Mert a szektorok száma ÖSSZESEN 32 biten tárolódik. 32 bites szám határozza meg, hogy melyik szektoron kezdődnek, pl
1. partíció 64. szektortól kezdődik és 1000 szektor méretű
2. partíció 1064. szektortól kezdődik és 2000 szektor méretűA partíciók nem fedik egymást, a partícióstruktúra lineáris, azaz ahol az egyik végződik, onnantól kezdődik a másik, nem kezdődhet 2 partíció ugyanazon a szektoron stb, ergo 2 a 32.-en-1 szektor (4GiB-1) lehet a legmagasabb szektor, ahol egy partíció kezdődhet. 2 TiB feletti terület eléréséhez nem elég ez a 32 bit, márpedig MBR-nél ez van.
Ebből meg már remélem egyértelmű, hogy teljesen mindegy hány részre akarod felosztani a HDD-t, MBR esetén akkor is csak 2TiB-t tudsz elérni. (Normális partícionáló progik meg sem engednék, hogy a 2. 1,5TB-os partíciót létrehozd, vagy levágnák 500GB-re...)
[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
félisten
Könyörgöm ne fárasszuk egymást... VIRTUÁLIS GÉP meg Linux meg GParted? Még mit fogtok kitalálni bakker...
Akkor leírom érthetően Windows alatt egy fizikai meghajtó legnagyobb felhasználható kapacitása 2TiB, amennyiben MBR partíció stílus van használva. Ha nagyobb kapacitású a meghajtó, akkor GPT partíció stílust kell használni.UI: A felkiáltójelek meg azért vannak ott, mert nem is lehet formázni. (inaktív a zöld pipa a GParted-ben, amivel a módosításokat alkalmazni tudnád)
[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
félisten
Virtuális gépen semmi sem az, mint aminek látszik, egy illúzió az egész. (Az én HDD -m most SSD-nek mutatja magát virtuális gép alatt, mert azt akartam, de attól még csak egy HDD...)
Éles rendszer alatt ezt nem fogod kivitelezni MBR-elSzóval nem "bajom" van a virtuális gépekkel, csak legközelebb ezt az apróságot említsd meg, hogy virtuális gép alatt particionálnál, meg használnál HDD-t, mert akkor nincs miről beszélni, mert nem érvényesek azok a szabályok alatta, mint éles rendszerek alatt.
[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
félisten
Semmi gáz, én sem olvastam vissza, lévén, hogy egy másik topiktársnak adott válaszom kapcsán írtál először... Azt a HSz-t megnéztem (abban ugye nincs szó virtuális gépről), visszább meg nem olvastam...
Szóval akkor éles rendszer és pl SATA porton fityegő HDD esetéről van szó, akkor annak sincs jelentősége, hogy 32 avagy 64 bites az OS, lévén, hogy semmi köze a dologhoz, mivel az MBR-ben (ami az első fizikai szektor a meghajtón, 512 byte méretű) van tárolva a partíció kezdete (több egyéb dolog mellett) azon a bizonyos 32 bites értéken és ezen nem változtat az OS. 32 bites rendszer esetén is használhat 2TiB-nál nagyobb meghajtó, csak kötelezően GPT partíció stílus kell, hogy legyen.
(Ha egy 2TiB-nál nagyobb kapacitású meghajtót rendszermeghajtónak használnál, akkor kötelező a 64 bites OS, mert csak az képes boot-olni róla UEFI támogatás is kell ilyenkor))Virtuális gépen mindegy, ott bármi lehet, mert lehet GPT-ben telepíteni, miközben a fizikai HDD MBR és lehet Linux-ot is telepíteni Ext4 fájlrendszerrel, miközben a fizikai HDD NTFS fájlrendszerű, stb stb...
[ Szerkesztve ]
Mindenki tudja, hogy bizonyos dolgokat nem lehet megvalósítani, mígnem jön valaki, aki erről nem tud, és megvalósítja. (Albert Einstein)
-
tlac
nagyúr
Fire/SOUL/CD:
megvettem a 3TB-os vinyómat a régi gépemhez, ami nem támogat semmiféle efi-t és rendszervinyónak szeretném majd használni, MBR partíciósémával
gparted-del megcsináltam a particionálást és a formázást, utána win7 alatt is meg tudtam formázni őket hiba nélkül (csak gyorsformázás volt)
ki kellene még találni már tesztet, hogy biztosan jól kezeli-e a windows
[ Szerkesztve ]
-
King Unique
titán
Default cluster size for NTFS, FAT, and exFAT
Windowson az exFAT fájlrendszerű kötetek formázásánál 32 GB felett 128 kilobájt az alapértelmezett lemezfoglalási egység, alapesetben azt javasolt használni. Egyéb esetben opcionálisan el lehet ettől térni +/- irányban és úgy is működhet, de túl kicsi klaszterméretnél (pl. 4 KB) előfordulhat probléma, hibaüzenet, lásd a saját esetedet. Ennyi!
-
King Unique
titán
Az eleve nem jó, az nyilván nem igaz és túlzás, max. nem teljesen naprakész és emiatt kicsit hiányos az a lista, úgy reális az állítás. Ahol a Windows 10-nél, annak újabb verzióinál már valóban 2 MB-ig terjed formázásnál a lemezfoglalási egység, legalábbis NTFS-nél, illetve ez is fájlrendszertől függő, exFAT esetében akár 32 MB is választható.
Le lett már írva, hogy a túl kicsi lemezfoglalási egység is gond lehet, amit a mostani példa is szemléltet. Vagyis tessék nagyobbat beállítani, vagy a Windows által felkínált alapértelmezettet (ami exFAT esetén nyilván nem 4 KB lesz X TB-os kötetnél) használni, ennyi.
-
King Unique
titán
Nem világos, hogy mégis milyen forrás kellene még, amikor már linkelve lett a microsoftos leírás fájlrendszertől és kötetmérettől függően az alapértelmezett, javasolt lemezfoglalási egységekre, valamint pont a saját eseted is szemlélteti, hogy az alapértelmezettől eltérően a manuálisan beállított 4KB-osnál problémázott a Windows. + Akkor ennyi erővel visszafelé is adott lehet a kérdés, hogy milyen forrás van arról, ami azt tagalja, hogy az OS, jelen esetben a Windows által a formázásnál felajánlott kötetmérettől okvetlenül el kell térni, illetve lefelé.
Másrészt alapesetben nem szokás piszkálni formázásnál a lemezfoglalási egységet és jó az úgy, ahogyan azzal lesz formázva a kötet, partíció. Ha már mást állít be a user, akkor meg általában nagyobbat szokás, ha pl. csak nagy méretű fájlok lesznek tárolva a lemezen, ami az adatátviteli sebességre is kedvezően hathat. Kisebb lemezfoglalási egységet meg akkor szokás beállítani, ha csak kis méretű fájlok lesznek tárolva a lemezen, + cél a lemezterület minél jobb kihasználása, ellenkező esetben felesleges, meg eltérni az alapértelmezettől. Persze ha valaki jobban akarja tudni a Microsoftnál is, hogy Windowsnál milyen lemezfoglalási egységgel kell formázni, illetve az előbb leírtaktól függetlenül, akkor végül is beállíthat mást is, aztán vagy / vagy...
Harmadrészt az nem feltétlen mérvadó, hogy mit ír egy másik OS (Linux) és az ottani fájlrendszerellenőrzés, amikor eleve Windowsról volt szó, ott problémázott a rendszer a leírtak alapján az alapértelmezettől eltérő 4 KB-os foglalási egységgel történt formázás után.
[ Szerkesztve ]
-
King Unique
titán
"több, mint 150GB-ot buknék a 2MB-os klaszter miatt, tényleg "jó".."
A formázásnál nyilván nem lesz ennyi lefoglalva, meg hacsak nem X KB-os méretű TXT fájlokkal lesz megpakolva az a nettó 5,2 TB-os HDD, akkor olyan kicsi klaszterméret sem szükséges, mint már említve volt...
"az exfat-ot csak amiatt választanám, hogy könnyen tudjam kezelni az adatokat win, linux és macos alól is"
Az exFAT ilyen célra valóban praktikus, mivel azt mindhárom OS kezeli, olvassa is írja. De ennyi erővel az NTFS-t is kezeli a másik 2 platform rendszerei, Linuxnál adott a natív olvasás+írás, macOS alapesetben csak olvassa, de úgy tudom terminálban és pláne külső programmal írni is képes. Sőt 3rd party programaml is W10 is képes kezelni Ext4, HFS+, APSF stb. fájlrendszereket.
"win10: 2MB
debian: 128KB
macOs: 256KB"Az a 2 MB elég érdekes, amikor a hivatalos leírás alapján is 128 KB a lemezfoglalási egység 256 TB-os kötetméretig. + Látszik, hogy nyilván más OS-ek is nagyobb alapértelmezett foglalási egységgel formázzák kötetmérettől függően az exFAT fájlrendszerű partíciókat, mint 4 KB.
"megfogalmazom másképp a kérdést, milyen limitáció vannak az exfat-nak a klaszterméret beállítására?"
Látszik pl. a fájlkezelős formázásnál is, hogy 512 bájttól egészen 32 MB-ig adható meg a foglalási egység, ahol értelemszerűen a kötetmérettől is függ, hogy mennyi lesz az alapértelmezett érték.
Ha manuálisan megadva a 4 KB-osnál hibát jelez a Windows 10, akkor le lett már írva világosan az előbb, hogy vagy nagyobbat kell manuálisan beállítani, vagy alapértelmezett értéken kell hagyni és úgy formázni, felesleges ezt tovább ragozni, ennyi.[ Szerkesztve ]
-
King Unique
titán
Igen, nincsen, de azok az értékek többnyire az újabb Windows-verzióknál is érvényesek általánosan, még ha nem is teljes a lista mindre és mindenre kiterjedően. Valamint mivel mást nem nagyon találni hivatalos és hiteles microsoftos forrásként, ezért lett az linkelve.
Majd akkor kiderülhet, ha már át lett másolva, hogy tényleg annyi-e. Meg az a 180 000 ezer fájl akkor ezek szerint sok kicsi fájl és nem is HD filmek, nagy méretű lemezképek stb., az előbbinél lehet értelme kisebb klaszterméretnek a lemezterület jobb kihasználása céljából, nem is az utóbbinál.
Az exFAT eleve a Microsoft által bevezetett fájlrendszer, nem feltétlen mondanám, hogy Windowson bugos lenne, meg inkább egyes más OS-eknél lehet téma ez, ahol csak utólag lett megoldva a támogatása.
Az meg ugye mondhatni alap, hogy belső és külső merevlemezeknél adattárolási célra is elsődlegesen naplózó fájlrendszer (pl. NTFS, Ext4, HFS+J) használata javasolt, nem pedig nem naplózó (FAT32, exFAT), ahol az utóbbi a flash-alapú tárolóeszközöknél (pendrive, memóriakártya) használatos a kisebb írásterhelés miatt is. Bár itteni Mac topikokban is többen használnak Windows & macOS dual boot esetén exFAT-ot, szóval nyilván működőképes lehet ilyen célra, még ha nem is feltétlen a legideálisabb.
[ Szerkesztve ]
-
King Unique
titán
Pedig az itteni beszámolók alapján általában megoldható megfelelő 3rd party driverrel/programmal, legalábbis többeknél működött. Meg ennyi erővel ha NTFS-re finnyás a macOS, akkor az exFAT-ra is az lehet, volt már itt a fórumon több olyan eset, amikor nem megfelelően működött oda-vissza a kezelése, holott azt natívan támogatja read + write szinten...
Ha a forrásmeghajtón a fájlok jó része nagyobb méretű fájl, akkor megint nem feltétlen kell annyira kicsi foglalási egységet választani a formázásnál, de mindegy. Az meg nyilván elég alap, hogy a fontos adatokról legyen több helyen biztonsági másolat és ne csak 1 db HDD-n legyenek tárolva.
De mindegy is, a téma már mondhatni ki lett tárgyalva, az egyéb dolgok meg már nem feltétlen ide tartoznak. De ha már macOS és particionálás a téma, akkor az még GPT-s adatlemezeken is létrehoz EFI-rendszerpartíciót (ESP) ahogy nézegettem, ami Windowsok és Linuxok esetén nem jellemző, max. OS-t tartalmazó rendszermeghajtónál, szóval ez érdekes.
[ Szerkesztve ]
-
King Unique
titán
Az egy általános, átlagos kalkuláció, ami valóban reális lehet, viszont hogy adott felállásnál ténylegesen mennyi lemezterület lesz felhasználva, mennyi vész kárba, az a tényleges kipróbálás után derülhet ki igazán pontosan.
Az ESP-t adatlemezen a népszerűbb desktop OS-ek közül csak a macOS erőltetni, ellenben Linuxok és Windowsok nem, ahol elég siralmas ha a másik OS-en particionált merevlemezen lévő partíciót ESP nélkül fel sem tudja csatolni... Ennyi erővel GPT-lemezen az újabb Windowsok is létrehoznak egy MSR partíciót, a Linuxok meg nem, de tudja kezelni és csatolni a Windows MSR nélkül is a másik OS-en inicializált, particionált lemezt.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- KERÉKPÁR / BRINGA / ALKATRÉSZ beárazás
- Call of Duty: Modern Warfare III (2023)
- VR topik (Oculus Rift, stb.)
- Poco X6 Pro - ötös alá
- Kerékpárosok, bringások ide!
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- Alkalmazásbemutató: Keep
- Gaming notebook topik
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...
- IcyBox IB-2812CL-U3 M.2 SSD dokkoló és klónozó - Dobozos, újszerű
- IcyBox IB-1824ML-C31 RGB Illuminated NVMe SSD ház - Dobozos, újszerű
- msata ssdk 16 és 20 gb
- Új bontatlan Sandisk Extreme Portable SSD 2TB és Samsung 2.5 870 Evo 500GB SATA3 (MZ-77E500B)
- ASSMANN Digitus DA-71545 NVMe - Dobozos, használt