Keresés

Új hozzászólás Aktív témák

  • Fire/SOUL/CD

    félisten

    válasz tlac #781 üzenetére

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

  • Fire/SOUL/CD

    félisten

    válasz tlac #783 üzenetére

    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)

  • Fire/SOUL/CD

    félisten

    válasz tlac #785 üzenetére

    Könyörgöm ne fárasszuk egymást... VIRTUÁLIS GÉP meg Linux meg GParted? :W Még mit fogtok kitalálni bakker... :C
    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)

  • Fire/SOUL/CD

    félisten

    válasz tlac #787 üzenetére

    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-el

    Szó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)

  • Fire/SOUL/CD

    félisten

    válasz tlac #790 üzenetére

    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

    válasz tlac #792 üzenetére

    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)

    ez most nem virtuális gép

    ki kellene még találni már tesztet, hogy biztosan jól kezeli-e a windows

    [ Szerkesztve ]

  • tlac

    nagyúr

    válasz tlac #825 üzenetére

    felraktam rá egy win8.1-et, simán bootol
    a 2. partícióra is másoltam egy bő 100 gigát
    szerintem minden működik, használható az MBR 3TB-os vinyónál is odafigyelve

  • King Unique

    titán

    válasz tlac #1604 üzenetére

    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

    válasz tlac #1606 üzenetére

    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

    válasz tlac #1608 üzenetére

    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... :D

    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

    válasz tlac #1610 üzenetére

    "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

    válasz tlac #1612 üzenetére

    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. :D 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

    válasz tlac #1614 üzenetére

    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

    válasz tlac #1616 üzenetére

    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 ]

  • King Unique

    titán

    válasz tlac #1618 üzenetére

    Már amennyire, nálam nem jöttek ki teljesen pontosan azok az értékek, amit a képlet adna, ezért is lehet célszerű ténylegesen is ránézni... De amúgy jó közelítéssel és nagyjából úgy-ahogy stimmel, előzetes kalkuláláshoz végül is megfelelhet.

Új hozzászólás Aktív témák