32bit és 64bit kompatibilis az adatfájlok szintjén?

UNIX kezdő

Nem tudom jó helyre nyitom-e a topicot, ez tűnt a legjobbnak.

Engem az érdekelne, hogy a 32bites és a 64bites rendszerek kompatibilisek-e egymással adatfájlok szintjén, avagy sem. Magyarul cserélgethetem-e szabadon a különböző verziókat egy gépen, úgy hogy közben a (bináris) adatfájlokat másolgatom? Az adott programtól függ, vagy globálisan kijelenthető hogy nem lehet gond, esetleg egyáltalán nem ajánlatos ilyet csinálni?

  • 4483 megtekintés

( vl v | 2011. 12. 27., k – 22:59 )

Az adott programtól függ

Ennyi. Ezt kár ennél tovább ragozni.

Persze, de ez a felhasználó szemszögéből alapvetően csak indikatív dolog.

Hány emberről/cégről hallottál, aki aszerint választ az Oracle, a Sybase, meg mondjuk a DB2 közül, hogy melyiknek hordozhatóak a bináris adatbázisfájljai szóhossz-, endianness- és cpu-architektúra-függetlenül? Ez nem életszerű.

Pontosan.
Annál is inkább nem életszerű, mert ahol tényleg kiszolgál a szerver, ott a sebesség sosem kielégítő (ahol az, ott sem az), így aztán bűn volna azzal terhelni a feldolgozást, hogy a 32 bites megoldások overheadjét fojtony nyögje a 64 bites kód (elég bajuk van az adatfeldolgozóknak a multibájtos karakterkészletekkel). Az egyszeri migráció/konverzió tisztább, szárazabb érzés.

Elmeletben konnyu ezzel dobalozni, a valosagban amig nincs serializer api tamogatas pl akarcsak a pid tipushoz, addig eleg nehez ezt a fajta igenyesseget elvarni. Ki tudja milyen tipus az 32 vagy 64 biten vagy akarmilyen architekturan, plane elore latni hogy 2 ev mulva jonnek a 256 bites gepek ahol a pid a mostaninal 4x nagyobb lesz ;)

De lehet zoldseget mondok mert szerencsere ezer eve nem kellett raneznem ilyen temaban :)
--
cythoon

> a valosagban amig nincs serializer api tamogatas pl akarcsak a pid tipushoz

printf ...

> Ki tudja milyen tipus az 32 vagy 64 biten

/proc/sys/kernel/pid_max (since Linux 2.5.34)
This file specifies the value at which PIDs wrap around (i.e., the
value in this file is one greater than the maximum PID). The default
value for this file, 32768, results in the same range of PIDs as on
earlier kernels. On 32-bit platforms, 32768 is the maximum value for
pid_max. On 64-bit systems, pid_max can be set to any value up to 2^22
(PID_MAX_LIMIT, approximately 4 million).

( bodobacs | 2011. 12. 28., sze – 00:06 )

Szerintem elvárható, hogy ugyanaz legyen az adatfile. Ha pl kép az adat akkor sincs 32, meg 64 bites verzió. Ha valami cache szerű dologról volna szó akkor elképzelhető, hogy nem foglalkozik az átvihetőséggel a programozó.

+ Ha "váratlanul" leforgatnak egy 32-bites programot 64-re vagy fordítva, akkor előfordulhat, de linuxra írt programnál elég ciki lenne.

Ha a memória ide vonatkozó részét egy az egyben mented file-ba, az értelemszerűen nem hordozható különböző rendszerek (amik különböznek byte order és word length szinten) között, de mondjuk úgy, hogy ez a lehető legbutább megoldás amit el lehet képzelni (a leggyorsabb is, de ez már más tészta:)). Valamit valamiért

:)

Szó sem volt semmilyen byte orderről, meg hordozhatóságról.
A felettem szóló azt kifogásolta amikor a postgres-el példálóztak, hogy adatfájlokról kérdezett, és nem adatbázisokról.
Erre válaszoltam azt, hogy az adatbáziskezelők is általában adatfájlokban tartják az adataikat, tehát a példa amit felhoztak, megállja a helyét.

Egyébként meg pont, hogy az adatbázisoknál az elsődleges szempont a gyorsaság, tehát valószínű, hogy egy db engine fejlesztő nem a verziók közötti byte szintű kompatibilitást fogja szem előtt tartani, amikor az adatfájl kezelését írja.

Kerdes, hogy az adott DB tervezesenel mi volt a lenyeg. Ha a sebesseg, valoszinuleg - ilyen szinten - nem hordozhato. Valoszinuleg ugyis van valami hordozhato formatuma, pl. verzio update-re, innentol kezdve felesleges is.
Mas kerdes, hogy DB eseten altalaban az IO alrendszer a szuk keresztmetszet, szoval a proci igazabol foglalkozhatna az on-the-fly konverzioval, van ra ideje. Ebben az esetben lehet hordozhato a formatum (meg ugye kodot karbantartani is konnyebb, ha minden architekturan ugyanugy nez ki a file).

--
Das "N" in RTL steht für Niveau... -Tuamo/Reel (?)

( pinyo_villany | 2011. 12. 28., sze – 00:20 )

Csak egy egyszeru pelda:

long

Irj ki egy long valtozot 64 bit-en, es olvasd be 32 biten, de ha meg meg is akarod fuszerezni, akkor ird ki SPARC-on a 64 bit-est es olvasd be x86-on 32 bit-en. ;)

Jo szorakozast.
___
info

( pinyo_villany | 2011. 12. 28., sze – 00:52 )

amugy a megoldas:

#include < stdint.h >

es az abban definialt tipusok hasznalata.

___
info

sys/endian.h

NAME
bswap16, bswap32, bswap64, be16toh, be32toh, be64toh, htobe16, htobe32,
htobe64, htole16, htole32, htole64, le16toh, le32toh, le64toh, be16enc,
be16dec, be32enc, be32dec, be64enc, be64dec, le16enc, le16dec, le32enc,
le32dec, le64enc, le64dec -- byte order operations
___
info

afaik az nem hordozhato

de lenyegeben: fix endiannessel (celszeruen LE, az a trendy), fix bitmerettel kell tarolni, paddingre vigyazva pl.: __attribute__ ((__packed__))
erdemes tovabba bovithetore tervezni a formatumot, ha hozza kell adni/modositani kell

--
NetBSD - Simplicity is prerequisite for reliability

A leheto legrosszabb otlet adatot (pl structot) direktben mappelni, akkor is ha ovatos vagy alignmenttel es egyebekkel. Az stdlib tamogatas szart sem er, max egyes mezokre lehet kenyelmes.

Ugyanis az alignment platformfuggo (sparc pl azonnal szarraszall egy ilyenen), tehat neked kell _elore kitalalni_ hogy mit is akarsz tamogatni. Az ahoka altal emlitett bovithetoseg es hasonlok (pl verzio informacik egyeb meta adatok) miatt pedig vegkepp nem erdemes osszemosni az adattarolas formajat a memoriaban valo tarolas modjaval, mert csak onmagad szopatod.
--
cythoon

( uid_4263 v | 2011. 12. 28., sze – 18:53 )

Ez a kérdés ebben a formában nem megválaszolható, lásd kommentek. Ki kell próbálnod az adott alkalmazásokat. A Firefox profil formátuma a tapasztalatom szerint könnyedén átvihető oprendszerek és 32 illetve 64 bites környezet között, de ez sajnos nem válasz a kérdésedre.

--
http://neurogadget.com/