Írtam egy programot, ami annyit csinál, hogy egy fájlba ír uint64_t számokat. (pontosabban prímszámokat, egy jó nagy fájlt csinálnék, amiben prímszámok vannak). kb. 2 hét alatt eljutott odáig, hogy a fájl mérete 2GByte lett, és nem íródik bele semmi. Érdekes, mert úgy viselkedik, mintha írna a fájlba, semmi leállás, csak a fájl nem növekszik, megállt 2147483647-nél. (minden 100000. prímnél kiírja a számot, és azt hogy hányadik).
Azt hittem, hogy ez a 2GB mérethatár már a régmult problémája. Ubuntu 18.04 32bit, ext3 fájlrendszer, gcc-7.5.0 a rendszer. Nem hiszem, hogy a rendszer korlátozná a 2GB-nál nagyobb fájlokat, hiszen ennél jóval nagyobb fájlok is vannak használva másegyéb programokkal.
A gcc/glibc cuccnak lenne ilyen határa, vagy esetleg valami fordítási direktíva kéne még?
- 1182 megtekintés
Hozzászólások
Milyen fordítási opciókat használsz? A -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE és -D_LARGEFILE64_SOURCE közöttük van?
- A hozzászóláshoz be kell jelentkezni
semmilyet... csak simán
gcc prim.c -o prim
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
- A hozzászóláshoz be kell jelentkezni
Ubuntu 18.04 32bit, ext3 fájlrendszer
Ha 32 bites a rendszered akkor kellenek ezek az opciok, amit irt GCS kollega fentebb:
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
Vagyis, en ezt a fenti ket opciot szoktam megadni hordozhato programok eseten, ez igy egyben mindenhol is jol megy (Linux/GCC, Linux/CLang, FreeBSD es MacOS alatt tesztelem ezeket a cuccokat kiadas elott, 32-bit es 64-bit, vegyesen). Ezen opciok nelkul 32 bites rendszernel nem fogsz tudni 2G-nel nagyobb fileokat csinalni. A sizeof(off_t)-vel tudod ellenorzni hogy mekkora is a file pointered. Es az off_t az elojeles tipus, ezert 2G a limit es nem 4G.
- A hozzászóláshoz be kell jelentkezni
Akkor próba indul... lefordítva, elindítva, kb 2 hét mulva kiderül, vagy beborul :)
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
- A hozzászóláshoz be kell jelentkezni
Szerintem probald ki elobb rovidebb futasidovel :) Pl nem minden 100ezredik prímet iratod ki hanem minden ezrediket. Akkor 1-2 oran belul kiderul mi a helyzet!
- A hozzászóláshoz be kell jelentkezni
Vagy ne is teszteljen prímre csak írassa ki az összes számot 1-től végtelenig (na jó, valami biztonsági feltételt megadva) :D
- A hozzászóláshoz be kell jelentkezni
Igenigen :) csak olyan tesztet akartam itten javallani ami tenykeg minimalis modositas a meglevo programhoz kepest. Sot, idealis esetben (pl command line argumentumok hasznalataval) konkretan semmi modositas nem kell :)
- A hozzászóláshoz be kell jelentkezni
Az `nm -g exe | grep 64` kimenete is segíthet.
- A hozzászóláshoz be kell jelentkezni
Programozási oldalról nem tudok hozzá szólni, semmihez nem állítottam még elő programból ekkora állományokat. Üzemeltetés terén viszont felmerül, hogy ha elérted a 2 GB-ot, akkor el fogod érni a 4 GB-ot is, ami már több fájlrendszernek korlátja. Ha mozgatni kellene valamikor az állományt, erre érdemes figyelni már most.
Esetleg az ilyen korlátoknak elébe lehet menni beépített darabolással, hogy mondjuk 1 GB elérésekor (nem is kell byte pontosan) új állományba kezd írni.
Meg az merült még fel bennem, hogy aztán mire fogod használni a keletkezett állományokat? Ha csak szekvenciálisan olvasod majd, akkor mindegy a formátum, de ha valami olyan kellene, hogy X számjegyből álló prímek listája, vagy mennyi prím szám van X értékig, akkor megint csak érdemes lenne a formátumon is elgondolkodni a méret kérdés során.
- A hozzászóláshoz be kell jelentkezni
Így 2023-ban elég ciki olyan filerendszert használni ami megdeglik 4G filektól...
- A hozzászóláshoz be kell jelentkezni
Igaz, ez nem fájlrendszerre vonatkozik, de így csinálják a nagyok: https://learn.microsoft.com/en-us/previous-versions/iis/settings-schema…
maxAllowedContentLength
Optional uint attribute.
Specifies the maximum length of content in a request, in bytes.
The default value is 30000000.
uint |
0 to 4,294,967,295 | Unsigned 32-bit integer |
Azaz 4GB.
- A hozzászóláshoz be kell jelentkezni
Ez régi verzió. A kurrens: https://learn.microsoft.com/en-us/iis/configuration/system.ftpserver/se…
maxAllowedContentLength |
Optional int64 attribute.
Specifies the maximum length of content in a request, in bytes. The default value is |
Szóval így csinálják a nagyok.
- A hozzászóláshoz be kell jelentkezni
Én HTTP-t írtam, nem FTP-t.
Aktuális doksi alapján most is: https://learn.microsoft.com/en-us/iis/configuration/system.webserver/se…
maxAllowedContentLength |
Optional uint attribute. |
- A hozzászóláshoz be kell jelentkezni
Jajj, keversz itt dolgokat.
Meg igy csinaljak a masik nagyok:
Syntax: client_max_body_size
size
;Default: client_max_body_size 1m;Context: http
,server
,location
Sets the maximum allowed size of the client request body. If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client. Please be aware that browsers cannot correctly display this error. Setting
size
to 0 disables checking of client request body size.
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body…
Szoval akkor mennyi az annyi?
- A hozzászóláshoz be kell jelentkezni
Mit keverek? Attól, hogy az nginx tudja, az IIS nem tudja.
- A hozzászóláshoz be kell jelentkezni
Én az állomány hordozhatóságot firtattam, tehát pl. pendrive-ra milyen FS kerüljön, hogy ne legyen 4G limit és kompatibilis legyen sok OS-sel, eszközzel? Ja, olyan nem nagyon van.
exFAT licencköteles, így sok eszköz (és OS) alapból, vagy egyáltalán nem támogatja, extX FS-ek Linux-only (nincs másra teljes körű támogatás tudtommal), NTFS Windows-only (kevés OS, még kevesebb egyéb eszköz támogatja rendesen), akkor mit?
- A hozzászóláshoz be kell jelentkezni
Le vagy maradva 4 évvel. 2019 óta az exFAT-ot nyugodtan lehet implementálni és használni, a Microsoft elérhetővé tette.
https://en.wikipedia.org/wiki/ExFAT#Legal_status
https://cloudblogs.microsoft.com/opensource/2019/08/28/exfat-linux-kern…
- A hozzászóláshoz be kell jelentkezni
Hát, akkor nem csak én, mert egy csomó eszköz nem támogatja a mai napig (nem PC-re meg laptopra gondolok, hanem bármi másra, amibe USB dugható és állományokat ér el rajta).
De köszi, legalább most már ezt is tudom.
- A hozzászóláshoz be kell jelentkezni
Igen, ebben igazat adok neked. Hiába nem licencköteles most már nagyon hosszú ideje, sok gyártó egyszer kihozza az eszközt, meg a firmware-t, és soha többé nem nyúl hozzá, és ezek közül sok még abban a korban született, mikor licencköteles volt az exFAT. Ezért hardveresen elég kevés eszköz támogatja. Meg igazából előnye sincs, hacsak az ember nem windowsos rendszerek felé akar kompatibilitást tartani, de arra meg szintén jó az NTFS.
A másik oldala a lustaság. Médialejátszók is általában mp3, wma-t támogatnak, a ogg/Vorbis hiába nagyon régi, és volt mindig is FOSS, meg nyílt szabvány, nem nagyon támogatják, de ugyanez a helyzet sok eszköznél az opus, flac, stb. formátummal is. A gyártó úgy van vele, hogy az mp3 majd úgyis lefedi a use case-ek 80-90%-át, az meg elegendő nekik.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Nem tudom, milyen hardverekről beszéltek. Az én kvázi noname tévém is ismeri az exFAT-ot és az NTFS-t is, ha jól emlékszem, 2014-ben vásároltam.
- A hozzászóláshoz be kell jelentkezni
Vagy 10 éve romlott el a fiam pendrive/médiajátszója, amely flac formátumot is tudott.
Az exFAT-ot régebben főként a kamerák és fényképezőgépek használták. Meg én is XP-n, mert csak FAT32 és exFAT volt - tavalyelőttig. ;)
- A hozzászóláshoz be kell jelentkezni
A C szabvány szerint egy fájlban az elérhető pozíció az long méretű lehet, az ftell és fseek ezt kérdezi le/állítja be. 32 biten GCC-ben a long az úgyanúgy 32 bites, mint az int tudomásom szerint.
Szóval az, hogy 2 gigabyte-os lesz a fájl maximum mérete, teljesen természetes, és a C szabvány előírásából és a 32 bites GCC-ből következik.
- A hozzászóláshoz be kell jelentkezni
Pont ezt akartam írni én is, hogy ilyen sok gigát kiíró projektnél nem kéne 32 bithez ragaszkodni. Prímszámokhoz okés lenne, de nem ilyen sok gigabájt terjedelemben. Gondolom az Ubuntu is azért ősi verzió, mert a 18.04-es volt az utolsó, ami támogatta. A gcc 7.5 is ennek megfelelően ősi, már 13.1-nél jár. Az ilyeneket jobb lenne tényleg modern, 64 bites rendszereken programozgatni. Nem véletlen, hogy a 32 bitet mindenhol irtják tűzzel-vassal, csomó idegesítő limitáció, meg fenntartani miatta minden libet 32 bites formában is a 64 bites mellett, ezt nem akarja a háta közepére se senki. Régen, míg az volt elterjedt meg megfizethető, addig szenvedtek vele, a mostani hardverek és hardverárak mellett már nem éri meg senkinek. Nem csak az x86, de az ARM világ is váltott már 64 bitre.
Nekem kicsit az ext3 is fura, bár most jelen esetben nem az felelős a korlátokért, blokkmérettől függően 16 GiB-tól 2 TiB-ig terjed a max fájlméret. Az ext4 kellően stabil, érett, már 10 éve is az volt, nincs rá ok, hogy valaki ne azt használja. Ha nem kell journaling, akkor ext2, esetleg ha valami SSD, vagy SD kártya, az f2fs bepróbálható.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni