vas csere, 32 => 64 bit

Linux-kezdő

Sziasztok!
A kerdes/problema a kovetkezo": adott egy vas (konkretan amd k7, duron proc), amit jo lenne modernizalni. Mondjuk egy amd64-es dualcore-ra (tehat szinten amd, az egyszeruseg kedveert). Ha az oprendszer (linux, debian) alatt az ember kicsereli a vasat, 32-rol 64 bitesre, akkor ez mennyire mehet siman? Ket diszk is van a gepben, raid-del, sok minden vacakkal, ido" nincs sok, szoval jo lenne, ha (ujra)install nelkul megusznank a dolgot. Erre van esely? Mondjuk ha fela'll az uj gep, akkor egy dist-upgrade (me'g mindig sarge van fent), uj kernellel, debian eseten az apt/dpkg tud-e ilyet (arch-ot valtani), mennyire szivas egy ilyen dolog, vagy esely sincs ra', es csak komplett installal lehet csak megoldani a dolgot?
A.

  • 1563 megtekintés

( bastya_elvtars | 2007. 08. 12., v – 23:04 )

Miért akarod 64 bitesre váltani az oprendszert? 4 giga fölött van/lesz a RAM?
It doesn't matter if you like my song as long as you can hear me sing

Ezt én sem tudom, de mivel ezek 32 bites módban tökéletesen futnak (sőt azzal legalább nem szopsz), ezért ha kicseréled alatta a vasat, és distro-/vanilla kerneled van, nagy eséllyel menni fog.
szerk.: azaz nagy esélyel SEMMIT nem kell csinálnod a linuzoddal.
It doesn't matter if you like my song as long as you can hear me sing

k7-es re optimalizált kernel k8-on vagy k9-en? szerintem jobb teljesítmény érhető el.
Amugy meg multkor szereltem egy AMD-s gépet és avval a default k7-es kernel nem nagyon tetszett forgattam egy ujabbat és jó lett (lehet, hogy a vassal volt gond, de a kernel megoldotta).

szerk.:

és ezt irta: "egy dist-upgrade (me'g mindig sarge van fent), uj" ennek meg lehet nem tetszik annyira az ujabb nforce mert, ha stock kernel-t haszál akkor 2.6.8-as van benne.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

( pinyo_villany | 2007. 08. 12., v – 23:15 )

az FS-ek on-disk format-ja (elvileg és gyakorlatilag is) ugyan az minden rendszer alatt, legyen az 32 vagy 64 bites X86os vagy más arch.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

akkor s/"az FS-ek on-disk format-ja (elvileg és gyakorlatilag is) ugyan az minden rendszer alatt, legyen az 32 vagy 64 bites X86os vagy más arch."/"a linux-os fs-ek nagyrészének on-disk format-ja (elvileg és gyakorlatilag is) ugyan az minden rendszer alatt, legyen az 32 vagy 64 bites X86os vagy más arch."

de a föbb linuxos fs-ek haszálnak a adatkonverzió

XFS "All data is stored in big-endian byte order"
EXT{2,3} "All data is stored in little-endian byte order"
ReiserFS "All data is stored in little-endian byte order"
Reiser4 SZVZ, ha 3-as tudta akkor ez is
Minix "Minix is always little-endian"
UFS* can be little-endian or big-endian, depending on the architecture of the vendor

* UFS -> ellenpélda
/*a amugy szokásomhoz híven XFS-böl indultam ki, az meg tudja, mint a linux-os fs-ek többsége*/

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

linux-2.6.20/include/linux/raid/bitmap.h: 


/* the superblock at the front of the bitmap file -- little endian */
typedef struct bitmap_super_s {
        __le32 magic;        /*  0  BITMAP_MAGIC */
        __le32 version;      /*  4  the bitmap major for now, could change... */
        __u8  uuid[16];      /*  8  128 bit uuid - must match md device uuid */
        __le64 events;       /* 24  event counter for the bitmap (1)*/
        __le64 events_cleared;/*32  event counter when last bit cleared (2) */
        __le64 sync_size;    /* 40  the size of the md device's sync range(3) */
        __le32 state;        /* 48  bitmap state information */
        __le32 chunksize;    /* 52  the bitmap chunk size in bytes */
        __le32 daemon_sleep; /* 56  seconds between disk flushes */
        __le32 write_behind; /* 60  number of outstanding write-behind writes */

        __u8  pad[256 - 64]; /* set to zero */
} bitmap_super_t;

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.1-pancs1-wifi1 - 2.6.22.1 kernel madwifivel itt

( n0gabor | 2007. 08. 13., h – 09:50 )

mivel a sarge-nak jopar eves a kernele, ezert van ra esely hogy vmi nem fog mukodni egy viszonylag uj chipsettel rendelkezo X2-es konfiggal.

( Oscon | 2007. 08. 13., h – 10:12 )

Mondjuk ha fela'll az uj gep, akkor egy dist-upgrade (me'g mindig sarge van fent), uj kernellel

Úgy tudom van az etch-ben olyan virtuális csomag hogy kernel-image..., így frissíteni fogja a sarge-ban levő 2.6.8-abszolut-agyonpacsált kernelt 2.6.18-közepesen-agyonpacsált-ra. :-)

Ha saját magad által fordított kernelt használsz, akkor pl. nvidia-kernel-source -t se felejtsd el. (vagy ha van más "kernelen kívüli" modulod, nézz utána, lehet már bent van a kernelben. Pl. 2.6.8-hoz még asszem volt nvidia nvnet zárt kódú meghajtó az integrált hálókártyához, etch féle 2.6.18-ban már a benne levő forcedeth modult kell használni.

Azért egy partimage mentést én csinálnék a motyóról, mert az ördög sosem alszik. backup mindenek felett. :))

----------

Nem a zsömle kicsi, a pofátok nagy...

( turul16 v | 2007. 08. 13., h – 10:20 )

SMP kernelt tégy fel, ha mind két magot szeretnéd használni.

( maniac | 2007. 08. 13., h – 10:35 )

Azert arra figyelj, hogy a kernelben meglegyenek az ATA/SATA meghajtohoz levo dolgok, ill a chipkeszlethez valo modulok. A procicsere maga nem nagy gond, inkabb az alaplapcsere.

( csuhi | 2007. 08. 13., h – 11:26 )

Tapasztalat: linux simán veszi az akadályt 32bites váltásnál, talál pár új hardvert és műxik, ennyi.

Ha dual core a cucc, és szeretnéd mind2 magot használni, akkor kernelt kell fordítani vagy a disztró smp kernelét használni. Ezenkívül nem árt, ha van annyira új a kernel, hogy ismerje az alaplapon levő hardvert. Gondolom a vinyók IDE-sek és az maradnak az új gépben is, akkor nincs gáz a Satával és a szoftveres RAID-el, csak ugyanoda pakold őked ahol a régi gépben voltak.

Egyébként 64bites rendszeren 32bites oprencert futtatni kb annyi értelme van, mint commodore 64 emulátort, de ha kényes a cucc a rendelkezésre állásra, és nem akarsz sokat variálni, akkor inkább maradj 32biten.

( -Atis- | 2007. 08. 13., h – 12:25 )

attól, hogy amd64, még nem felejtett el 32 bites üzemmódban működni

a 32 bitet nem emulálja, hanem - egyelőre - igazából abban lehet jól használni (felhasználói szempontból, ahhoz jobban van támogatás, programok, driverek, stb.), hacsak - mint már korábban említették - nincs szükség nagy memóriára, meg 1-2 64 bites fícsörre (otthon ennek relatíve kicsi az esélye)

meghogy ezek igazából nem 64 bites processzorok, hanem 32 bitesek, csak van nekik 64 bites üzemmódjuk is (történelmileg így alakult)
tehát a 32 bites módban üzemeltetés nem "visszalépés", hanem a 64 bites kiegészítés egy előrelépés, ami egyelőre inkább szerver-jellegű felhasználásnál jöhet jól

( cappa72 | 2007. 08. 13., h – 14:25 )

Azt olvastam,
http://linux.hernadizoltan.hu/
amiben az áll, hogy
"Ezekkel kapcsolatban megjegyezném, hogy egyelőre nem javaslom a 64 bites rendszerek telepítését, mert sok probléma lehet velük miközben teljesítményben nem nyújtanak többet a 32 bites változatoknál. A 64 bites processzorral rendelkezők is nyugodtan telepíthetnek 32 bites rendszert."

azt inkabb ugy mondanam legfeljebb, hogy teljesítményben EGYELORE nem nyújtanak többet a 32 bites változatoknál. azert a ketszer annyi regiszter kell, hogy szamitson. pl. a john the ripper vagy mi (a jelszo toro) az konkretan tudom, hogy gyorsabb, pont a tobb regiszter miatt.

- Use the Source Luke ! -

( emberk | 2007. 08. 14., k – 11:36 )

Hát én csak annyit tennék hozzá ha egy 64-bites vasra 64-bites rendszert teszel akkor valamivel gyorsabban fut mit a 32-bites rendszer. Ha desktopra használod valóban nem éri meg, mert max 10-15%-al lesz gyorsabb a géped, viszont szívsz a flash-al a java-val, és rakhatod fel a chroot-ot 32-bitre, és az annyit visszafog a gépen mert megeszik egy csomó memóriát, így nem éri meg. Vagy miultilib, ott meg konfigolhatsz ezerrel, és vadászhatod a probléámákat, hogy pl a hangkártyát melyik 32-bites program fogta meg, amit nem igazán látsz 64-bit alól (ill látni lehet, de kiszedni neccesebb), és rengeteg zárt kódú program van amit nem fordítanak le 64-bitre. Vioszont ha sokat tömörítesz, vagy filmet rippelsz akkor nagyon jól jön a 64-bites mencoder, én pl szimulációkar futtatok, ami full matek, na ott a c++ --march=athlon64 kapcsolója igen csak jól jön. Ott kb 40%-ot visszafog a futási időn.

Igen, ezt hallottam, hogy desktopon nem trivialis a 64bit. De nem arra kell, hanem dzsunkaszervernek, igy halistennek se java, se fless, se egyeb marhasagok.

pl szimulációkar futtatok, ami full matek, na ott a c++ --march=athlon64 kapcsolója igen csak jól jön. Ottkb 40%-ot visszafog a futási időn
na, ez viszont jo, ilyen futtatasok biztos lesznek itt is ;]

A.