-
Fototrend
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
bambano
titán
A filerendszer típusát mindig az határozza meg, mennyi idő van egy probléma utáni újraindulásra. Ha nem kritikus a reboot ideje, akkor minden esetben kizárólag ext2.
Ha kritikus a reboot ideje, akkor nem tudom, leginkább ext3, de gyakorlatilag mindegyik filrendszerre volt panasz mostanában, a reiser fő alkotója éppen feleséggyilkosság vádjával sitten van, a többinek is voltak ilyen-olyan bajai.
Kernel verziótól is függ.
A raid1 nekem nem gyorsított semmit, annyi előnye van, hogyha bedöglik egy diszk, nem 0 eséllyel marad meg az adatod, ámde sokkal nagyobb valószínűséggel borul meg tőle a gép. Úgyhogy ha nem félsz a diszk hibától (mert bízol a diszkben vagy mert nem tartod értékesnek a rajta tárolt dolgokat), akkor ne használj raidet és ne használj ext3-at, mindkettő nagyban egyszerűsíti a rendszert és nagyon sokat csökkent azon programkód mennyiségén, amiben hibát lehet találni.
Ha igazán sokat akarsz kockáztatni, akkor tedd az összes adatod raid-re, lvm-re vagy evms-re és használj xfs-t vagy reiser4-et lehetőleg a legújabb kernelekkel. Ez a tutti módja annak, hogy legnagyobb rizikó felvállalása mellett legvalószínűbben összeboruljon a géped.
Tudom, hogy amit ide írtal, az szembe megy a mainstreaim véleménnyel, ennek ellenére a személyes tapasztalataim alapján ezt tudom javasolni (én is kerülöm a raidet és csak ext2-m van, ha lehet).Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Az lvm nem filerendszer, hanem volume manager.
Az ext3 általában fele olyan gyors, mint az ext2. Ha nincs szükséged a naplózásra valami nyomós okból, akkor szerintem nem éri meg kézifékes fájlrendszert választani.
Bajod majd akkor lesz a raid1-gyel, amikor elromlik egy diszked.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz rokefeller #3473 üzenetére
Először is a csúnya nagy fagyás még nem indok a gondolkodás nélküli resetre. Attól, hogy a kernel és/vagy az oprendszer nagyrésze lefagyott, még lehet menteni az adatokat, a magic sysrequest dologgal. Ez szerencsés esetben akár jelentős adatvesztést is megakadályozhat.
Nekem még nem volt rossz tapasztalatom ext2-vel, amit éppen akkor ír a rendszer, mikor fagy, az természetesen megy a levesbe, más nem szokott. Nem zárom ki, de nem valószínű.
Én nem mondom meg senki helyett, hogy neki a journal erőforráspazarlás-e, sőt, azt se, hogy egy gépen mi neki a jobb. A journal egyértelmű előnye, hogy akár sok száz gigás partíciót is pillanatok alatt felmountol a rendszer, még összeomlás után is, viszont a journal metadata írása pont ugyanolyan írás, mint a többi, ez peches esetben simán lefelezi a teljesítményt. Ami nagy méretű filmek írásakor jól jöhet, tehát még az is simán előfordulhat, hogy valakinek egyik gépe ilyen, másik olyan vagy egy gépen belül egyik partíció ilyen, másik olyan.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
''mindezt csak véleménycsereként nem kötekedés vagy okoskodás'': ne aggódj, majd hétfőn felébrednek a linux fanok és fogok kapni hideget-meleget, hogy rosszat mertem szólni a kernelre
''azért nem gondolom hogy túl nagy veszteség lenne a naplózó történet'': naplózó filerendszer elképzelésem szerint kétféleképpen működhet:
1. - jön adat, leteszik az adatot a metadata (a journalba) területre
- leteszik a szükséges rendszerterület változtatást a metaadat területre (inode-ok, clusterek, stb).
- átmásolják a metaadat területről az adatot a rendes helyére
- átmásolják a metaadat területről a rendszerterület változtatásokat a rendszerterületre
- adminisztrálják a journalt
2. - jön az adat, leteszik a végleges helyére
- a rendszerterület változtatást leteszik a metaadat területre
- a rendszerterület változtatást végrehajtják a rendszerterületen
- adminisztrálják a journalt.
Ezzel szemben az ext2-nél lerakják az adatot a végleges helyére és lerakják a rendszerváltozásokat a végleges helyükre. Ez pont fele annyi lemezio művelet.
Ami már nem az én elképzelésem, hanem az én mérésem, hogy ez nagyságrendileg 40-50% teljesítményvesztés, minél kisebb gépen és minél gyengébb hdd-vel nyomod, annál látványosabban lassú a naplózás. Én pont a felét mértem a gépemen. Amíg valaki nem mutat egy 200MB/sec fölötti írási végeredményt bonnie++ kimenetben, addig pesszimista vagyok a naplózós rendszerek írásával kapcsolatban. Az olvasás vélhetőleg nem lassul jelentősen, tehát egy ext3-ról fat32-re másolás az simán lefuthat teljes sebességen.
Elfogadom, ha azt mondod, hogy neked a felezett teljesítmény nem észrevehető, irigyellek a gépedért. De ne szvsz legyen hanem konkrét mérés.
Szerintem a hw nem előzött sehova, a kernel simán kihajt mindent a vasból, ami benne van.
A raid, lvm, ext3, xfs, reiser4 használata esetén azt lehet állítani, hogy ha és amennyiben a tisztelt programozók nem rontottak el semmit az adott alrendszer programkódjában, akkor az adott alrendszer a tőle elvárt előnyöket nyújtja.
Na ezen szokott megbukni a dolog, mostanában annyi ótvaros pocsék kód került a kernelbe, hogy sírhatnékom van. Ennek van pl. olyan eredménye, hogy megdöglik a raid1 kötet második diszkje, ami lehúzza az egész gépet, elérhetetlen, használhatatlan lesz tőle minden. Pedig a raid1-nek elvileg a rendelkezésre állást is javítania kellene diszkhiba esetén, de nem, hanem ettől omlik porba a gép.
Vagy: diszk hiba miatt megdöglik raid1, szabályosan kicserélem a diszket, újraindítom a gépet és pillanatok alatt felbootol. Majd pár óra múlva megomlik az egész. Alapos vizsgálat után kiderül, hogy a frissen berakott lemezt a raid1 nem szinkronizálta, maradt üresen. Minden olvasási művelet, ami a második lemezen zajlott, 0-val feltöltött szektorokat olvas be, ettől a bináris programokban folytonossági hiba keletkezik és értelmezhetetlen problémák kerülnek elő. Végül az egész összeborul. Visszabootolva egy korábbi kernelt, pár óra alatt lemegy a szinkronizálás és utána megy minden korrekten.
Vagy: mostanában valami olyan baja van a raid kódnak, hogy ha kidöglik a diszk alóla, megpróbálja szinkronizálással helyrehozni. Na ettől szépen megáll az egész blokkos eszköz, mint a szög.
Nem merném azt állítani, hogy minden fejlesztő mindig gondolkodik és mindig helyes eredményre jut. Szoktunk néha agyhalottazni, nem minden ok nélkül. Fentiek megtörtént esetek, tehát aki vitatkozni akar vele, annak azt kell bizonyítania, hogy vak vagyok vagy hazudok. Meg azt is, hogy az általam leírt hibára a hivatalos kernel changelogban adott magyarázat nem igaz.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
A system map arra jó, hogyha valami kernel programozási hiba miatt összeborul a kernel és szeretnéd bejelenteni a fejlesztőknek a hibát, akkor a system mapra szükség van ahhoz, hogy kideríthessék, merre járt a kernel, amikor eldobta az agyát. Régebben mintha a ps is használta volna, de ez nem mostanában volt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
No, hogy ne hiedelmek meg mítoszok alapján beszéljünk, csináltam most egy mérést. A feltételezés ugye az, hogy minél ócskább a gép, annál lassabb a naplózó filerendszer az ext2-höz képest. További feltételezés még, hogy ez a lassulás akár 40-50%-ot is elérhet.
Itt egy izompacsirta gépen, bonnie++-szal mérve az ext2 98243K/sec-cel írt, az ext3 88054 K/sec-cel, az xfs 82827K/sec-cel, a reiserfs pedig 87764 K/sec-cel (ez utóbbi gondolom reiser3 lehet, a debian csak reiserfs-nek hívja, viszont van külön reiser4 csomag).
98243/82827=1.18612, tehát az eredeti feltételezés majdnem fele megvan. Ez egy két diszkes raid1 volt, ami az átlapolódó műveletek miatt szerintem gyorsabb, mint a gyalog diszk, illetve ez a gép sokkal jobb hardver, mint amit otthon használok fájlok tárolására. Az egy 233Mhz-es p1, 128M rammal, 250Gs samsung pata diszkekkel, ez egy 930D, 2G ddr2/800-as rammal, wd400ks sata diszkekkel. A p1-es gép nem hibás, hanem simán régi.
Nincs most kéznél önálló diszk, pedig lehet, hogy volna értelme nem raid0-n hanem egy darab diszken is tesztelni ugyanezt.
Úgy gondolom, továbbra is maradok annál a véleménynél, hogy minél ócskább gép, annál inkább lassú a naplózó filerendszer az ext2-höz képest.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
-
bambano
titán
Tehát akkor mégegyszer: az mx rekord domain NÉVRE mutat, nem domainre, ezt ne keverjük. A domain nevet és a helyes ip címet kell bevésni a hostsba. Kétségeim vannak afelől, hogy a sendmail képes-e figyelmen kívül hagyni a hosts filet, ugyanis az a rezolver dolga, hogy foglakozik-e vele vagy sem, nem a sendmailé. Ha a /etc/nsswitch.conf jól van kitöltve, akkor szerintem a sendmail nem nagyon tudja kikerülni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
ott kell lennie, hogy:
hosts: files dns
Amikor a sendmail kézbesíteni próbál egy levelet, akkor kiderítni, hogy ki az mx-e az adott domainnek és utána vagy a hostsból vagy a dns-ből kideríti, hogy hol az a gép.
Ha küldessz egy nev@akarmi.com-ra, akkor először megnézi, hogy az akarmi.com-hoz van-e ip cím rendelve (szerintem nem jó szokás domainhez ip címet rendelni, de elvileg lehet). Ha nincs, megnézi, van-e mx rekord akarmi.com-hoz, ez utóbbi lépést mindig a dns-ben nézi. Ha talált olyat, hogy akarmi.com-nak mx-e a gepnev.akarmi.com, akkor már a gepnev.akarmi.com-ot fogja kikeresni. Ha megtalálja a hosts-ban, akkor odaküldi, ha nem, akkor kikeresi dns-ből.
tehát megnézed, hogy a
host -t mx akarmi.com
utasítás milyen mx-eket sorol és az mx gépeket kell korrigált ip címmel és eredeti névvel bevésni a hosts-ba.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Ez így egy kicsit tág. A courier az teljes levelező rendszer, ahhoz nem kell postfix. Ha postfixet raksz fel, akkor a couriert csak részlegesen kell felrakni.
Nekem van courier imap+postfix+postgresql gépem. Szerintem nem egy doksiból csináltam, de nem volt nagy varázslás.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Jó lenne, ha megírnád, mi a probléma, mert én ennek nem sok értelmét látom. Mármint annak, hogy bemegy egy smtp kapcsolat egy gépbe meg kijön belőle egy smtp kapcsolat. Akkor már egyszerűbb egy tcp tunnelt használni.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Szerintem a webmail kliensek nem mysql-ből autentikálnak, hanem a courier imapd-t használják erre a célra. Tehát bármelyiket lehet használni, amelyik kompatibilis az imapd-vel (asszem a courier 4.1-es imap protokollt tud, de nem vagyok biztos benne). Amelyik tetszik. Nekem mókus van, de nagyon ritkán használom.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Ezzel szemben a fapados debianban van dbus és hal, udev-vel, meg gnome volume manager. kioslave is volna benne, de még sose használtam kde-t, így ezt nem teszteltem. A debian valóban fapadosnak tűnik, főleg, ha az 5-6 éves verzióit nézzük.
Az lvm2 pedig kezelhető windows alól: [link]Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz ngabor2 #3572 üzenetére
Az a link 2001. 40. hetéből való. Eléggé nem sanszos, hogy a kerneled olyan régi, de ha elárulnád, hogy milyen kernel van a gépen, talán tudnánk segíteni. Meg azt is, volt-e valami hibád, van-e software watchdogod, ilyenek. A mostani kernelek elég meredek dolgokat tudnak csinálni raiddel, vagy ha hálózati problémád van, stb.
milyen az a web ÉS http szerver?Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz VladimirR #3581 üzenetére
Minden olyan processz szeret fejreállni, mint a szög, amelyik dns szervert használ, ha elmegy a hálózat. Az a jobbik eset, ha ilyenkor magától rebootol a gép, ilyet a watchdog csinálhat, a rosszabbik eset, ha ilyenkor úgy megkavarodik az agya, hogy nem lehet rebootolni.
Ez személyes tapasztalat. Illetve mostanában látok gyakran olyat, hogy kis terhelésen elgurul a cucc, de ha megtolják alatta a hálózatot, akkor fejreáll az ethernet kártya drivere. Ilyen régebben realtek kártyáknál volt, mostanában marvell kártyákra jellemző, illetve minden olyanra, amit sky2 driverrel kell hajtani.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Ehhez képest az etch úgy települ, hogy megkérdezi, mire akarod használni a gépet (egy kérdés, 5-6 lehetséges válasszal) és arra a feladatra optimalizált, fullos csilivili rendszer települ. Ergo a fapadozás nem indokolt.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Kezdésnek pl. azt lehet csinálni, hogy elárulod, milyen cuccokból áll a gép.
És persze azt, hogy sürgősen eldöntöd, melyik fórumban kérdezel, mert a két fórumos párhuzamos hibakeresés az kitolás mindenkinek.
[Szerkesztve]Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Van itt egy ilyen gép:
00:00.0 Host bridge [0600]: Intel Corporation P965/G965 Memory Controller Hub [8086:29a0] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation P965/G965 PCI Express Root Port [8086:29a1] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 02)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 [8086:2847] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev f2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller [8086:2810] (rev 02)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) SATA AHCI Controller [8086:2824] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 02)
01:00.0 VGA compatible controller [0300]: nVidia Corporation G70 [GeForce 7600 GS] [10de:0392] (rev a1)
02:00.0 SATA controller [0106]: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller [197b:2363] (rev 02)
02:00.1 IDE interface [0101]: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller [197b:2363] (rev 02)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
lsmod|grep snd
snd_hda_intel 17332 4
snd_hda_codec 137856 1 snd_hda_intel
snd_pcm_oss 38368 0
snd_pcm 68676 4 snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_mixer_oss 15200 1 snd_pcm_oss
snd_seq_dummy 3844 0
snd_seq_oss 28768 0
snd_seq_midi_event 7008 1 snd_seq_oss
snd_seq 45680 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_timer 20996 3 snd_pcm,snd_seq
snd_seq_device 7820 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd 47012 15 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_pcm,snd_mixer_oss,snd_seq_oss,snd_seq,snd_timer,snd_seq_device
soundcore 9248 1 snd
snd_page_alloc 9640 2 snd_hda_intel,snd_pcmEgy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz ngabor2 #3631 üzenetére
[link]
Eszerint a kotta szerint digitális adatbusz van rajta, tehát a capture csak úgy működik, ha az analóg-digitális átalakítás már megtörtént valahogy. Szóval ez nem csak egy csatlakozó rádugását jelenti, annál lényegesen bonyolultabb.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz ngabor2 #3675 üzenetére
Ha köréraksz egy olyan környezetet, ami a hangup szignált elkapja, akkor nem lép ki. Erre van kész shell parancs, vagyis ha így indítod a programot:
nohup programnev &
akkor nem fogja eldobni, ha kilépsz. A nohup.out fileba rakja bele a kimeneteket.
De a screen, az at és a cron is jó erre.
Szerk: bocs, olvasás terén kihívásokkal küzdök.
[Szerkesztve]Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
A pam nem kezeli a DISPLAY-t. Ez architekturális tévedés. Ergo nem kellene belepiszkálni és pláne nem kellene rossz tanácsokat osztogatni.
Van helyette jó megoldás, itt is elhangzott. Ne szoktassuk rá a kezdőket téves megoldásokra.
Most pl. ráklikkeltem a menüre és két lehetőséget is találtam:
- nested X szerver, teljes root sessionnal
- rendszergazda terminál, minden trükközést megold a menü
Minek kell kotorászni a pamban, ahol esély van rá, hogy porbadöntöd a rendszert, mikor kész megoldás van a gépen, kettő is???Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Nem, az a baj, hogy a kedvedért felraktam a programot én is, (kérem higyjétek el, hogy be tudom állítani az X-et) és nekem is megrohadt ugyanott, ahol neked.
Mivel az én gépem nem mai gyerek (jó eséllyel másfajta darabokból van, mint a tied), valami generális bajba sikerült belecsápolni.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Nézem ezt a Clint Eastwood filmet pont most az rtlen, épp kikérdez egy tanút. Nekem meg az üti ki a szemem, hogy RedHat Linux 6.1-es doksi van a tanú munkaasztala mellett a polcon...
Neeeem, nem vagyok kockaEgy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
én régebben használtam, de a gnu awk-ban annyi hiba volt, hogy egy idő után leszoktam róla. azóta megtanultam mindent bashban, amit eddig awk-ban írtam.
meg debianon sose tudhatod, hogy mawk, nawk vagy gawk van felrakva, aztán csak vakaródzás van, hogy valami miért nem működik.
ez persze nem zárja ki azt, hogy mondjuk akár video kazetta kölcsönzés nyilvántartást vagy internet szolgáltató adminisztrációt is megcsináljon benne az ember...Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
Tehát akkor ismételjünk: ahhoz, hogy egy gépen grafikus felületet használó programot futtass, nem kell a gépen grafikus felület. A unixok egyik nagy előnye a MáSik világhoz képest, hogy hálózattranszparens a grafikus felületük, tehát arra a gépre kell felrakni az X-es miskulanciát, ami előtt ülsz, nem a sambás szerverre és hálózaton keresztül minden működni fog.
Szerintem a windowsok mindig rawban küldik a cuccot, sajnos. De régebben volt egy magicfilter nevű cucc, annak bármit küldhettél, kinyomtatta. Nem tudom, mostanában cupshoz létezik-e ilyen.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Motoros topic
- Hálózati / IP kamera
- A fociról könnyedén, egy baráti társaságban
- Tetőfokára hág a tavasz, és ezt a hardverek is érzik
- Ukrajnai háború
- Programozás topic
- Villanyszerelés
- exHWSW - Értünk mindenhez IS
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Vigneau interaktív lokálblogja
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest