ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
Solaris 10 10/09 |
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
Nagyon szeretném a Solaris-t ha lassan nem jutnánk el odáig hogy a telepítésért is fizetni kéne. Most, hogy Oracle "biznisz" lesz, még jobban fizetni kell mindenért gondolom. Megértem, de nem esik jól :)
Etetni kell valamiből a sok éhező szájat, az csak egy mítosz, hogy a dióbél csákányosok a dióért csákányolnak.
De miért is kellene fizetni?
Nem kell félned, lesz majd belőle "XE" kiadás... :)
suckIT szopás minden nap! Lefoglalták a warezt hostoló routereket, megállt a magyar internet
Tanulásképp nem sokkal ezelőtt tettem fel a májusi release-t. Azóta patchelgettem, de az nem elég ahhoz, hogy frissüljön az új release-re.
Hogyan tudnám valamilyen egyszerű módon frissíteni úgy, hogy a CD-s frissítés elkerülhető legyen? Mondjuk NFS-ről, vagy helyi fájlrendszerről, ahová az iso-t kicsomagoltam?
__________________________________________________________
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 12.1 | 2.6.26.7-janos
Keress rá a live upgrade-re
--
http://laszlo.co.hu/
Liveupgrade?
Ha ufs-en vagy, akkor kell hozzá egy üres slice, ami ~megegyezik a jelenlegi /-ed méretével. Ha /var, /opt, stb külön van, akkor man olvasgatás lesz a dologból, erre nem térnék ki. :) Ha zfs-en vagy, akkor kevesebb plusz hely kell, meg kevesebb idő :)
iso-t megeteted lofiadm-al (lofiadm -a /path/to/iso/iso.neve)
ezután felmountolod valahova -F hsfs kaCCSolóval
lucreate blabla
luupgrade -u -n [be neve] -s /path/to/os/image (ahova felmountoltad)
luactivate [új be]
Gyors, tiszta, száraz érzés.
...és nem kell cd sem.
szerk: megelőztek... :)
<-------
You can't grep on dead trees.
van egy 80 GB-os ufs diszkem, amin a slice-ok kitöltik az egész rendelkezésre álló helyet. ezen van a rendszer.
azt esetleg megtehetem, hogy a home-ot átteszem máshová, és csökkentem a méretét, és létrehozok a maradék helyen egy új slice-ot az update-hez.
a /opt-om külön slice-on van, mindenféle sunfreeware-es finomsággal.
van még egy alig használt zfs-es második diszkem, nem tudom azt lehet-e használni valamire ilyenkor?
__________________________________________________________
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 12.1 | 2.6.26.7-janos
Mindkettő opció működhet.
Az elsőnél partíció átméretezés-játék lesz, a másodiknál liveupgrade-zfs migrálós játék lesz.
Ha nem zavar, hogy aztán már csak zfs-ről zfs-re tudsz livupgradelni, akkor a második veszélyteleebb lehetőség :)
A második esetben ez (Migrating a UFS Root File System to a ZFS Root File System (Solaris Live Upgrade)) lesz a barátod.
<-------
You can't grep on dead trees.
egyelőre nem migrálom át zfs-re, inkább maradok az ufs-en, és mérezezem át a home-omat.
a zfs-es diszken egyelőre a zfs feature-jeit, és a snapshot készítést próbálgatom.
__________________________________________________________
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 12.1 | 2.6.26.7-janos
Ma nekigyürkőztem a liveupgrade-nek.
Vegyesek a tapasztalataim. A liveupgrade használata viszonylag egyszerű, és végig is ment, csak egy csomagot (SUNWscpr) nem sikerült feltennie. Ezt utána konzolból sikerült feltenni, de semmi extra nem kellett hozzá, csak simán feltettem. Nem tudom miért nem sikerült a liveupgrade alatt frissíteni/feltenni.
Rákerestem a sunsolve-on, hogy mégis mi ez a csomag, és mi lehet ez a hiba, de persze az erről szóló összes cikkekhez support contract kell. :S
Aztán jöttek a hibaüzenetek az iscsi initiator szolgáltatástól, mikor sosem használtam eddigi életemben, és az u7 alatt szintén sosem panaszkodott, de most valamiért hirtelen meggondolta magát. Emiatt kapott egy svcadm disable-t, ahogy a sendmail is.
Az egyik interfészen bekapcsoltam a dhcp-t, és erre minden induláskor összeba*a az /etc/inet/hosts fájlt, és a másik interfész fix ip-jét kitörli, a hozzátartozó hosztnév definíciókkal. Emiatt ki is kapcsoltam a dhcp-t, és letiltottam az interfészt. (Esetleg tud valaki valami okos tanácsot adni ezügyben?)
__________________________________________________________
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 12.1 | 2.6.26.7-janos
Nem tudja valaki, még mindig olyan tetű lassan települ ?
Ezen állítás szerint nem. Most próbáltam az x86-os verziót vmware workstationben és tényleg hamarabb feltelepült egy full rendszer, mint korábban az u7.
--
http://laszlo.co.hu/
Nincs ehhez egy magyar tükör vagy egy .torrent? Nekem nagyon lassan csorog :(
Hivatalos nincs.
--
http://laszlo.co.hu/
Köszi, közben kitaláltam rá egy körbedolgozást (,,workaround'', ékes magyarral) :)
Letöltöm egy szerverre, oda gyorsan megy, aztán magamnak meg erről a szerverről már gyorsan jön.
"Setting ZFS user and group quotas"
Ez végre normális (ufs-hez hasonló) kvótázás?
Valami olyasmi, bár korábban volt szó (http://arc.opensolaris.org/caselog/PSARC/2009/204/) arról, hogy nem lesz tökéletes (pld. késleltetett a kvótázás).
Nem tudom, hogy ami végül megvalósult milyen lett.
suckIT szopás minden nap! FreeBSD: ZFS, vagy UFS a {My,Postgre}SQL alá?
" This decision was made to get the
feature to market in a reasonable time, with a minimum of engineering
resources expended."
hehehe....sőt, höhöhö.... :)
Régebben olvasgattam pár cikket, leírást a ZFS-sel kapcsolatban, mert nem értettem meg elsőre, hogy ha egymilliárd diszkből raidz(2) poolt csinálok, miért lesz egyenlő az egész összteljesítménye egy diszkével.
Szóval míg ennek utánaolvastam, nekem határozottan az az érzésem alakult ki, hogy a ZFS-ben van pár beépített időzített bomba (vagy inkább tervezési hibának kellene hívni?), ami kicsit elhalványítja azt a nagyon modern, nagyon ütős FS-ről szóló marketing képet...
Pld. ez: http://suckit.blog.hu/2009/06/04/a_zfs_esete_too_many_files_szal_magyar_hangja_toth_maria_franciska
ami bár állítólag más FS-ekkel is jelentkezik, UFS-sel konkrétan még nem tapasztaltam (biztos mert az nem olyan modern :).
suckIT szopás minden nap! Linux+MySQL: milyen fájlrendszeren?
es ez freebsd? mert a zfs verzio most valami 14nel tart :-)
Az rc1 8-as FreeBSD -ben és a 7-stable ban 13-as verzió van, a 8.0 és 7.3 azzal jön.
A kedvedért frissítettem az alábbi cikket.
Természetesen nem fogok megharagudni, ha te is létrehozol, és közben folyamatosan törölsz pár millió apró fájlt egy solarisos ZFS-en, majd leállítod a létrehozást, és megvárod, míg minden törlődik (ezt csinálod kb. két napig), és utána eleresztesz egy findot. :)
Legalább kiderülne, hogy mi a helyzet arrafelé.
suckIT szopás minden nap! ZFS funkciók
ha lement a hackathon, es visszajonnek a tesztjeim, megnezzuk. valami opensource cuccot hasznaltal erre, vagy sajat tesztkeszletet?
en a FileBenchet szoktam hasznalni ilyen jellegu tesztekre, tud workloadot szimulalni. esetleg erdemes lenne megnezni ezzel is.
SMTP szervert használtam erre, amibe gyorsabban küldtem a levelet, mint ahogy a pop3 szerverrel el tudtam volna őket olvasni, és utána törölni.
A queue felhízott pármillióra közben, amikor leállítottam az SMTP-s küldést, és hagytam, hogy kiürüljön.
suckIT szopás minden nap! A világ legjobban fizetett vállalatvezetői
ez kiderult a cikkbol is, engem az erdekelt volna, hogy az adatok amiket kuldtel mar letezo levelek voltak vhonnan kiemelve teszt celra, vagy autogeneralted oket valahogy, eseteg egy test-suiteal?
Szerinted ez számít? :)
postallal küldtem, és rabiddal fogadtam, töröltem. Random levelek.
suckIT szopás minden nap! A világ legjobban fizetett vállalatvezetői
szamit, mert nekem nincs elfekvoben 500g levelezesem tesztelni :-)
ezert kerdeztem, h generaltad-e v sem, h en is megismetelhessem a teszteket, es ha valami perf kijon, hogy tenyleg rossz, irhassak a belso discuss listara.
Jujj de izgi. :)
Aszittem a Sun a kommuniti elkötelezett híve, erre jössz itt belső discuss listákkal...
Kíváncsi vagyok mire jutsz.
suckIT szopás minden nap! A világ legjobban fizetett vállalatvezetői
van sunos, kulso zfs-discuss lista is, feel free to post it there. :)
ha reprodukalni tudom konzisztensen es nem 3/4 napot varva, akkor mar orulok, es akkor tudok postolni en is, de erre csak a honap vege fele lesz idom, jelenleg az SCJP tanfolyamot is pusholnom kellett, mert nincs idom :(
A hiba valószínűlg a cow (copy on write) sajátossága (vagy inkább a cow implementáció hibája :) ).
Ugye a cow lényege, hogy aktív adatot nem töröl, és nem ír felül, és elég intenzíven operál meta-objektumokkal.
Több millió fájl létrehozása és törlése esetén rengeteg meta-objektum keletkezik, és nyilván itt lehet valami gixer.
Azt próbáltad, hogy x idő üresjárat után megismétled a find-oka? (Hogy esetleg valami clean-up egy idő után feltakarítja a metákat)
Tesztkörnyezetben nem tudom, hogy működik, viszont az utóbbi 1-2 évben több helyen is használtuk (köztük pl. bankkártyás oracle környezetben), és eddig nem volt vele soha gond (teljesítményben kb. 20%-ot vert rá az UFS-re egy adott adatbázis batch futtatáskor)
Sun cluster alatt állítólag voltak vele régebben nyűgök, de nem emlékszem mi.
Az adatbázis vajon csinál olyat, hogy létrehoz millió fájlt, majd törli őket, és újra és újra?
suckIT szopás minden nap! A világ legjobban fizetett vállalatvezetői
A köré épített cucc elég sok fájlt hoz létre, és töröl az esti batchek folyamán.
A több millió fájl esete egy felhasználási mód, az adabázis meg a másik.
Egyébként meg ez van. Az ufs-ben 20 év után is vannak bugok. Aki nem használ a tesztedhez hasonló workload-ot, azt nem érinti a probléma. Aki meg igen, az már rájött, és használ mást. :)
Több millió apró fájl esetére én speciel még midig a VxFS-t ajánlanám Solaris alá. Bár az kicsit durvadrága...