- bitpork: Augusztus 2- szombat jelen állás szerint.
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Chosen: Canon 5D II - portrézás 2025-ben
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Fogkefe: elektromos vagy manuális?
- Magga: PLEX: multimédia az egész lakásban
-
LOGOUT
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
-
Üdv!
Történt, hogy a számítógép használatban kevésbé rutinos családtag leformázta a merevlemezét egy véletlen folytán, Windows recovery disk rossz helyre ment ezzel legyalulva a partíciókat és egy FAT32-t hagyott a windows telepítő fájloknak. Kértem, hogy ne írjon rá többet és csatolja le, így nagy adatvesztés a Windows telepítőn kívül nem történhetett. Csak a partíciók vesztek el.
Futtattam rajta egy testdisket, meg is találta a vélhetően hiányzó NTFS partíciót:
A kérdésem az, hogy merjem-e futtatni a testdisket, hátha visszaállítja a partíciókat? Vagy egyenest vegyek egy másik 2 TB HDD-t és photorec-kel próbáljam meg menteni a dolgokat? Csak a képekre lenne szüksége, viszont félek, hogy a partíciók létrehozása csak még több kárt okozna. Tudom, az lenne a legoptimálisabb, ha egy másik HDD-re tükrözném ennek a tartalmát és úgy kisérleteznék, de csak ezért nem akarok beruházni ennyi HDD-be.
Ui.: bocs, ha egy picit off, természetesen Linux alól próbálom helyreállítani a lemezt egyébként...
-
át szeretném irányítani egy Pi naplózását a home szerveremre, hogy ez se az SD kártyát koptassa, ha nem muszáj.
amit képtelen vagyok elérni (mert nyilván valami hülyeségen elsiklok), hogy ne ömlesztve vegye át egy fájlba a naplózást a szerver.
mert ugye van a syslog, meg az auth.log, meg a kern.log és társai, de ezek egy fájlba folynak össze a szerveren, holott az lenne az ildomos, hogy ugyanúgy szeparálva jelennének meg, mint a Pi-n.rsyslog és Debian fut mindkét eszközön
A Pi-n a következő módosult:
az /etc/rsyslog.conf végére biggyesztettem, hogy*.* @szerverIpje:514
ebben mondjuk van egy ilyen rész, hogyauth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
és úgy érzem, hogy valahol itt lesz a kutya elásvaA szerveren meg annyi történt, hogy
/etc/rsyslog.d/10-remote.confModLoad imudp
$UDPServerRun 514
$AllowedSender UDP, otthoniAlhálózatom/24
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/.log"
*.* ?RemoteLogs
& ~most így létrejön egy .log nevű fájl a /var/log/remote/%HOSTNAME% mappában és abba kerül minden
-
OddMan
őstag
válasz
f_sanyee
#30391
üzenetére
Lehet hiányos, csak példaként raktam be. Engem most csak a meta kulcsszó működése érdekel az nftables esetében.
Szóval akkor a lényeg, hogy a meta-val úgy kereshetek, mintha string-ben keresnék agy adott előfordulást?
Bár akkor gondolom érdemes a meta kulcszót csak akkor használni, amikor feltétlenül szükséges, mert lassabb lesz az adott szabály feldolgozása, mintha csak a payload-ban lévő adatokra match-elnék? -
-
inf3rno
nagyúr
válasz
Frawly
#30383
üzenetére
Talán olvasd el, ami a képhez van írva, "1 bit flipped". Teljesen mindegy, hogy ez HDD, SSD vagy RAM esetében történik, az eredmény ugyanaz lesz. Ha annyira érdekel milyen sűrűn van, akkor keressél tudományos cikket a témában, van egy jó pár, ami foglalkozik a gyakoriságával. Ezen kívül a row hammer miatt is erősen ajánlott az ECC, mert annak a többségét is kivédi. Szerintem egyáltalán nem hype, de senki nem kötelez rá, hogy használjad. Megszoktuk már, hogy szeretsz különcködni.
-
Frawly
veterán
válasz
inf3rno
#30378
üzenetére
Értem, szóval a bitflip még mindig urban legend, mindenki hallott róla, csak még senki nem tapasztalta. Amit a képen mutatsz, olyat én is láttam már, az nem bitflip, hanem okozhatja meghibásodott háttértár, rossz letöltődés. Persze RAM hiba is, de nem bitflip, hanem en bloc kaka RAM. Ezért kell CRC-ről meg redundanciáról gondoskodni, mert nem csak a RAM lehet hibás, meg nem csak bitflip fordulhat elő, önmagában az ECC sem tesz csodát, csak plusz egy védelmi intézkedés a sok közül.
Félre ne értesetek, nem az ECC RAM ellen vagyok, ha a platformja támogatja és valaki tud szerezni olcsón (pl. DDR3-ból még olcsóbb is az ECC, mert sok szerverből kukázott RAM-ot árulnak használtan), akkor miért ne, plusz egy védelmi vonal, senkit nem vitt még el a mentő, mert ECC-set használt. Én arról beszélek, hogy ez a divathájp, meg tömegpánik, hogy ZFS, jajjaisntem, csak-ECC, jajjmerhamivanhabitflipvanezeréventeegyszer hiszti csak ilyen marketingesek által felfújt baromság. Nem szabad neki bedőlni, van élet az ECC-n túl is.
-
inf3rno
nagyúr
válasz
I02S3F
#30380
üzenetére
Már minek? A hibás memóriának vagy a bitflipnek? Kicsit is komolyabb helyen szerintem nem megengedhető, hogy csak úgy változzon, hogy mi van a memóriában, azért van ECC. Nem drágább, mint a normál, a CPU és az alaplap a drágább, ami tudja kezelni, de az se vészes. Én workstation lapot és egy Xeont vettem itthonra, teljesen jól megy, és megvoltam kicsivel 100k alatt ezzel a részével. Szerver lappal viszont húzós lett volna az ára, az tény.
-
inf3rno
nagyúr
válasz
Frawly
#30377
üzenetére
Nem bitflipről beszéltem, hanem hibás a memóriáról. A bitflip általában csak bitrotot okoz, pl recsegős lesz egy zene fájl vagy szétmegy néhány pixel egy képfájlon.
[link]
Ez is lehet gond, de nem akkora, mint a hibás memória. Ha a lemezen történik, akkor ha van redundancia a ZFS vissza tudja állítani az eredeti képet. Ha a memóriában történik mielőtt kiírnánk, akkor esetleg backupról lehet visszaállítani, de a változtatások elvesznek, és csinálhatjuk újra. Viszont elég ritka ahhoz, hogy ezzel komolyan számolni kellene. Talán egy emberöltő alatt elvisz 1 napi munkát.
Az oprendszer működésénél szerintem nagyon szerencsétlennek kell lenni, hogy valami komoly hibát okozzon. -
Frawly
veterán
válasz
inf3rno
#30375
üzenetére
De milyen adatvesztéshez? Tegye már fel itt a kezét, aki bitflip miatt vesztett adatot. Mondom kizárólag bitflip miatt, nem teljesen hibás RAM, bedöglött háttértár, villámkár, kártevő miatt, hanem tényleg csak is kizárólag bitflip miatt. Na, ugye, hogy senki.
Arról nem is beszélve, hogy a tömörített fájlok, médiafájlok (kép, videó, audió), SQL adatbázisok, torrentek, komoly fájlrendszerek (mint a Btrfs, ZFS, és társaik, meg az összes többi fájlrendszer, ami használ tömörítést vagy titkosítást) stb. eleve valamilyen szinten mindig használnak valamiféle CRC megoldást, alapból. Tehát maximum nagyon alap fájlrendszereken lévő plain text fájloknál, és binárisoknál vagy kitéve, hogy a bitflip miatt félremehet valami. De binárisoknál is elméleti az esélye, mert ha egy bit is félremegy, az már másik opcode, azonnal crashel a program, vagy fagy az egész gép, nem marad észrevétlen. Plain text fájlokban, úgy, hogy tömörítve sincsenek, azokban nem tárol senki kritikus fontosságú adatot. Forráskódok általában fent vannak git-en, helyileg pedig megint tömöríteni szokták őket. Így maximum logokról meg CSV fájlokról tudom elképzelni, hogy csak így plain text-ben vannak hagyva, natúron.
-
válasz
Frawly
#30374
üzenetére
Simán képes "összefirkálni" a fájlrendszert amikor kiíródik a page cache. Nem véletlen, hogy minden szerverben és kritikus rendszerben ECC ram van. Arról nem is beszélve, hogy a kernel képes lapokat hibásnak jelölni, így hibás RAM esetén is biztosítható a folyamatos működés.
-
inf3rno
nagyúr
válasz
Frawly
#30373
üzenetére
Nem ajánlás, mert ténylegesen vezethet adatvesztéshez, ha hibás memória marad a rendszerben valahogyan. Indulásnál volt már, hogy átment a memória teszten nekem rossz memória. Utána csak az OS tudja megfogni, de ahhoz azt hiszem az kellene, hogy kernelt vagy ilyesmit töltsön rá, amit ténylegesen ellenőriz. Ha sima fájlok mennek bele pl másolásnál, akkor a másolat köszönőviszonyban sem lesz az eredeti fájllal. A ZFS-nél még ott van az automatikus javítás, amit azt csinálja, hogy checksumot ellenőriz, aztán felülírja a hibás blokkot a jóval. Itt is kaphatsz hibás checksumot egy blokkra, aztán ha talál jó checksumosat, akkor felülírja a blokkodat ugyanúgy szeméttel. Ami miatt redundanciát vesztesz. Elvileg van valami threshold, hogy egy lemezen mennyi hibás checksum lehet, de gondolom jó magas, úgyhogy el tudsz lenni redundancia nélkül egy jó darabig. Meg írhatod ugyanúgy a hibás backupokat is egy másik lemezre. Aztán amikor elszáll a lemezed, ami az egyetlen jó másolatot tárolta az adatról, akkor csak pislogsz, hogy mi van. Nyilván ehhez az kell, hogy ne vedd észre egy darabig, hogy nyüzsögnek a checksum errorok, és valami gond van. Azt nem tudom, hogy az egyetlen jó checksumos blokkot is felül tudja e írni hibás memória miatt. Erre a triviális mód egy checksum collision lenne. ZFS alapból fletcher2-t használ, amiről kb. semmit nem tudok, de valszeg messze nem collision mentes. Át lehet állítani, hogy sha-256-ot használjon, azzal biztosan nem írja felül a jót, de jóval lassabb lesz. Ezen felül viszont nem ismerem eléggé a fájlrendszer felépítését, hogy tudjam máshol milyen károkat okozhat a hibás memória. Elvileg minden blokk felett van valami szülő blokk, ami tárolja a checksumot hozzá, és legfelül van valami über block, amiről több másolat készül. Ha az über block és a másolatai átírásra kerülnek, akkor az egészet lehet kukázni jó eséllyel. Szóval szerintem valós veszélyt jelenthet a nem ECC memória. De nagyjából annyi a tudásom a témáról. Valaki biztos meg tudja magyarázni, hogy megéri a kockázatot az olcsóbb alaplap és processzor, ami nem támogatja az ECC-t, mert az adatok amúgy sem érnek annyit.
-
Frawly
veterán
Igen, de ha nem tudok róla, meg nem volt belőle adatvesztés, akkor miért számítana? Általában egy RAM vagy jól működik, vagy nem. Utóbbi esetben sokkal durvább jelei vannak, mint a bitflip. Ha meg működik, akkor meg a bitflipnek nincs gyakorlati jelentősége, annyira ritka.
-
-
válasz
bambano
#30364
üzenetére
történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő
De, bőven előfordulhat.
(#30366) Frawly
Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál. Erről nem tudsz a szoftveres rétegben gondoskodni. Bőven fut olyan kód a rendszeren, amihez nem lehet plusz ellenőrzést rakni (pl. egy interrupt handler a kernelben).
Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Volt bőven, csak nem tudsz róla
(#30368) inf3rno Nagyon ritkán előfordulhat, hogy nem detektál egy több bites hibát, de ennek az esélye minimális. Ha unrecoverable error van akkor meg jön a fatal machine check és a kernel pánik.
-
inf3rno
nagyúr
válasz
bambano
#30364
üzenetére
"de nem ez számít, hanem az, hogy történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő."
Ez jó, akkor kukázom a memtest-et, nem is értem a sok hülye miért futtatja mindig. Azt se vágom miért hangsúlyozza mindenki, hogy használjunk ECC memóriát ZFS-hez. Én is csak pár bejegyzést olvastam arról, hogy valakinek teljes adatvesztése volt belőle. Kicsi a kockázat.
Amennyire én tudom az ECC is csak single bit flip ellen véd, esetleg 2 bit flip ellen, de 3-nál már az is csődöt mond. Wikipedia szerint row hammer-nél volt már példa 3-as flipre, amit nem detektált.
-
Frawly
veterán
válasz
bambano
#30364
üzenetére
Egyetértek. Erről szoftveres rétegben kéne gondoskodni, hogy az ellenőrző-összeg nyilván legyenek tartva, meg összehasonlítva eltárolásnál.
A DDR5 állítólag megszünteti ezt a mizériát, mert abból csak ECC-s lesz, még desktopon is. Megszüntetik ezt a kettős vonalat.
De elvileg a DDR4 vezérlésében már most is vannak olyan elemek, amik valamilyen szintű hibajavításról gondoskodnak, ettől még a non ECC DDR4 RAM nem lesz ECC-s, azt teljesen nem váltja ki, de a semminél jobb.
Egyébként mióta PC-zek, kb. 32 éve, nekem sose volt ilyen bitflip hibám. Volt olyan, hogy a RAM vagy az alaplap volt teljes kaka, akkor sem bitflip volt, hanem azonnal fagyott az egész OS-estől, vagy be sem bootolt, olyan szinten volt hibás. Vagy HDD lett bad sectoros, vagy áramszünet miatt sérült az adatintegritás. De bitflipből még sose lett gondom. Amikor meg nagyon ritkán mégis előfordul valakivel, annak a kivédésére jók a szoftveres megoldások. Ez az ECC-mánia túl van spilázva. Ilyen szintű biztonság max. bankoknál, hadseregnél, CIA-nél, stb. indokolt.
-
válasz
bambano
#30364
üzenetére
Lehet, de egyrészt ilyen nem volt beállítva, másrészt igen valószínűtlen hogy pont azt a 600+ torrentet töröljék, ami nálam seedben volt.
Igazából ez lett gyanús, miután sehol nem volt semmi hibaüzenet vagy napló, ami nyomra vezetett volna, hogy hová lettek az adatok és miért pont az tűnt el, ami.
Beléptem a torrentbe és az tűnt fel hogy nem az van hogy 600-szor ki van írva hogy "missing files", hanem hogy tök üres az egész... 0 betöltött torrent. -
bambano
titán
van ecc-s notebook ram, de nincs rá szükség.
az ecc-s ram annyival jobb, mint a sima ram, hogy egy bit hibát ki tud javítani. de nem ez számít, hanem az, hogy történhet-e memória hiba detektálatlanul, és az a sima ramnál sem fordulhat elő.a seedben levő dolgok úgy is el tudnak tűnni, hogy a torrent kliensben be van állítva, hogy unregistered torrentet töröljön az adatfájlokkal együtt és a trackeren kitörlik a torrentet.
-
-
válasz
bambano
#30312
üzenetére
csak hogy meglegyen a follow-up...
egyszerű LVM kötetbe volt szervezve 5 db 2TB-os HDD-m.
pár óránként jött a dmesg-be a fentihez hasonló üzenet, hogy most az ata5 esett le egy pillanatra, aztán az ata6, stb, de egy másodpercen belül már újra elérhető volt.
aztán egyik nap eltűnt 4TB-nyi adat, ezen felbuzdulva úgy láttam, hogy igazad volt*, és ez így nem mehet tovább, viszont gyanús volt, hogy egyébként a lemezek jók, a hiba máshol lesz.
lementettem mindent a kötetről, és az egészet átszerveztem egy ZFS kötetté, egész pontosan RAIDZ1-é (ami kb RAID5-nek feleltethető meg, egy lemez kiesését tolerálja). Azóta egyetlen esetben sem jött elő a fenti hibaüzenet.
úgy gondolom, hogy a SATA vezérlő nem tudott valamit elég gyorsan és / vagy jól csinálni, amire az LVM-nek igénye volt, aztán időnként feladta, és eldobta a lemezt, a ZFS meg talán hatékonyabb és nem fut bele ugyanabba a korlátba.* a torrentkliens webfelülete nem volt lejelszavazva, szerintem ott jött be valaki vagy valami, és egyszerűen kitörölte amit talált, mert kizárólag a seedben lévő dolgok tűntek el minden hibaüzenet nélkül.
-
b3Ro
senior tag
Szerintem meg van a beallitas vegre, ezzel a cpu pihen, gpu dolgozik:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i CONVERT.mp4 -vf 'scale_vaapi=w=2560:h=-2:format=nv12' -c:v h264_vaapi -qp 18 -c:a copy VIDEO.mp4Bar igy is kapok, par fura dolgot:
Driver does not support some wanted packed headers (wanted 0xd, found 0).Driver does not support packed sequence headers, but a global header is requested.No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers). -
b3Ro
senior tag
válasz
Frawly
#30354
üzenetére
fent van. kdenlive alatt megy rendesen, es vainfo alapjan is minden jo.
Kozben probaltam a kovetkezovel:ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i INPUT -c:v h264_vaapi -profile:v high -level 41 -vf "format=nv12|vaapi,hwupload,scale_vaapi=w=2560:h=1440:format=nv12" -c:a copy OUTPUTDe ezt kapom vissza:
[h264_vaapi @ 0x55b7251877c0] No quality level set; using default (20)
[h264_vaapi @ 0x55b7251877c0] Driver does not support some wanted packed headers (wanted 0xd, found 0)
[h264_vaapi @ 0x55b7251877c0] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x55b7251877c0] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input
Error initializing output stream 0:0 --
Conversion failed! -
b3Ro
senior tag
Sziasztok
ffmpeg-el szeretnek upscale-elni egy videot, de nem tudom ravenni a GPU-t, h besegitsen.
OS: Manjaro KDE
GPU: RX 5700
CPU: 3300x
Ezeket probaltam:ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i CONVERT.mp4 -vf scale=2560x1440:flags=lanczos -c:v libx264 -preset slow -crf 21 VIDEO.mp4ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i CONVERT.mp4 -vf scale=3840:2160:flags=neighbor -c:v libx264 -profile high -preset slow -rc vbr_2pass -qmin 17 -qmax 22 -2pass 1 -c:a:0 copy -b:a 384k VIDEO.mp4ffmpeg -i CONVERT.mp4 -vf scale=3840:2160:flags=neighbor -c:v h264_amf -profile high -preset slow -rc vbr_2pass -qmin 17 -qmax 22 -2pass 1 -c:a:0 copy -b:a 384k VIDEO.mp4Egyik sem hasznlaja a GPU-t, a CPU viszont 100%-on teker.
Mit rontok el ?
Segitseget elore is koszonom.
-
Frawly
veterán
A JMS 578 megfelelő chip, az elvileg támogatja az UASP módot, TRIM-et, és SMART-tot is. Nekem is van egy, igaz a SMART talán nem megy, de a TRIM és az UASP mód igen. De rég próbáltam, lehet minden menne ma már vele.
Az fstrim-nek ez a működése. Ha újrabootol a rendszer, akkor a felcsatolt partíciókon az egész szabad helyet végig TRIM-ezi (vagyis nem teszi, csak kiküldi a TRIM parancsot ezekre a szektorokra az SSD vezérlője felé). Viszont ha nem bootolsz újra, akkor második-harmadik, stb. futásnál megjegyzi, és nem TRIM-ezi meg az egész üres szabad helyet, hanem csak azokat a szektorokat, amik a legutolsó fstrim futása után szabadultak fel.
-
#30351
lionhearted
őstag
Dißnäëß
#30349
-
vzozo
senior tag
válasz
Dißnäëß
#30349
üzenetére
Nem fogok farokméregetési versenybe kezdeni, hogy ki mennyi LB-vel dolgozott már az év(tized)ek alatt, de azért vegyük már észre, hogy egy Layer4 LB-vel túl sokat itt nem tudsz tenni source IP affinity beállításán kívül vagy SSL termináláson (de az meg L7, és általában nem load balancernek, hanem proxy-nak nevezzük.)
Persze ha megosztod a megoldásod, azzal mindenki előrébb lesz.
-
#30347
vzozo
senior tag
lionhearted
#30342
vzozo
senior tag
válasz
lionhearted
#30342
üzenetére
Köszönöm a válaszod - igazából ez a nagyvonalakbeli működés úgy-ahogy tiszta volt számomra is. Amit nem értek, hogy pontosan mi is történik, mivel itt pár másodperc alatt lezajlik az akció akár a 64 gigás SD kártyára, akár a 200 gigás SSD-re.
A teljes fájlrendszer összes blokkja a memóriában van mountolás után, és ezért fut ez le ilyen gyorsan?
-
-
Dißnäëß
nagyúr
Sziaszok,
van arra ötlete valakinek, milyen irányban kellene-lehetne tovább menni.. ? Adott pár célgép, amikre sftp-vel akarnánk kliens oldalról feltölteni fájlokat. A célgépek identikusak, előttük egy load balancer dobálgatja a forgalmat ide-oda. Mivel a kliens oldalon csak 1 virtuál ip és 1 hostname látszik mindegyik tényleges host-ot illetően, viszont a valóságban mikor melyik host-on végződik a kapcsolat, változik a host RSA key, ami oké a kliensnek, ha éppen random a nála eltárolt key-ű host szolgálja ki a kapcsolatot, minden egyéb esetben errort dob és nincs kapcsolódás. Ezen ellenőrzés kikapcsolása kliens oldalon nem megoldás. A host-okra egységesen 1 kulcsot rátenni (mindre ugyanazt) szintén elég hülye lenne (még ha működne is, valaki így csinálta és megy). SSL terminálás a load balanceren szintén nem megoldás, ha onnan titkosítás nélkül megyünk a célgépekre. Lehet kapcsolódó kliens oldalon kellene vmit script-elni, vagy megoldható a címzett oldalon valami ügyes trükkel ? Úgy tudom, egy kliens oldalról látszó host-hoz csak 1 key rendelhető (ha lehetne többet is, az megoldaná instant a fejfájást). Köszi.
-
#30342
lionhearted
őstag
vzozo
#30341
Röviden: nem írja ki, csak megjelöli szemétként, amit a GC egyszer csak törölni fog.
Hosszan: az fstrim megkérdezi a fájlrendszert, hogy melyik fájlrendszer szektor üres, majd a szektor - LBA táblából átadja az eszköznek azon LBA tereket, amik valójában már üresek/szemetek. Az eszköz az LBA - belső címzés alapján bejelöli azokat a pageeket, amik szemetet tartalmaznak. Legközelebb, mikor:
* vagy az egész block (több page) invalid lesz és jön rá egy GC törlés
* vagy újrafelhasználva írni akar a pagere, akkor ugye törölni kell a blockot, majd vagy ott, vagy máshol (dinamikus WearLeveling dönti el) kiírja, akkor már nem viszi magával az invalid paget, helyére új kerülhet
* vagy a statikus WearLeveling úgy dönt, hogy túl sokáig állt ott az adat és áthelyezi, akkor kivágja az SSD a fenébe ezeket a pageeket, nem viszi őket tovább. -
#30341
vzozo
senior tag
lionhearted
#30340
vzozo
senior tag
válasz
lionhearted
#30340
üzenetére
Nekem még mindig nem tiszta, hogy pontosan mit csinál az fstrim. Ilyen rövid idő alatt nem tud ~200 gigát kiírni, tehát pontosan hova, hogyan mondja el az SSD-nek, hogy akkor azok üres blokkok?
-
#30340
lionhearted
őstag
vzozo
#30339
-
vzozo
senior tag
válasz
Frawly
#30337
üzenetére
Köszi mindkettőtöknek. Qrva sok szívás van az USB-SATA miatt, de az SBC-knek ez a borzasztó hátrányuk, már ezerszer megbántam, hogy ebbe vágtam a fejszémet. Ugyanakkor a lakásban jelenleg nincs olyan zug, ahová elrakhatnék egy "rendes" x86 alapú vasat, asszony meg nyilván nem szeretné se a nappaliban, se a háló- vagy gyerekszobában látni. Paff.
Itt (https://forum.manjaro.org/t/solved-trim-not-working-on-a-usb-3-0-drive/45585/33) azt állítják hogy a JMS 578 támogatja a trimet.
Ami érdekes az fstrim-mel, hogy amikor először futtattam 19-én a posztolás után, akkor trimmelt kb. 220 gigát. Majd pár órára rá néhány megát.
Most délelőtt újra futtattam, és:
root@odroidn2:/home/vz# fstrim -a -v/var/log: 39.3 MiB (41156608 bytes) trimmed on /dev/zram0/media/mmcboot: 56.7 GiB (60854341632 bytes) trimmed on /dev/mmcblk1p1/: 226.8 GiB (243520970752 bytes) trimmed on /dev/sda1kb. fél órával később:
/: 69.3 MiB (72646656 bytes) trimmed on /dev/sda1Volt a hétvégén néhány restart, lehet amiatt trimmelte újra az egész SD-t és az SSD-t is? Fura...
-
Frawly
veterán
Igen, tedd be a /etc/fstab-ba az adott partíciókhoz a discard paramétert. Vagy futtasd időnként kézzel az fstim-et, vagy ütemezd be systemd service-ként systemctl-lel.
Azért létezik a két megoldás együtt, mert kezdetben egyik fájlrendszer ezt a megoldást támogatta, a másik a másikat. Ma már kb. minden fájlrendszer támogatja mindkét módszert, így mára az maradt, hogy ki melyik módszerre esküszik. A Linux disztrók zöme fstrim-et használ systemd-vel beütemezve, az Arch Linux és a rá épülő disztrók fstab discard-ot. Mindegy melyiket használod.
Ami gond lehet még, az az USB-SATA adapter. A TRIM parancsot nem mindegyik engedi át az SSD felé. Az adapterchiptől függ.
-
vzozo
senior tag
Adott egy Odroid N2, és USB-SATA adapteren keresztül egy SSD-ről fut a rendszer. Szeretnék biztosra menni, hogy a TRIM használva van, mivel a SMART adatok szerint a wear level elkezdett durván növekedni szinte nulla használat mellett
Titt nem látok discard opciót az fstab-ban:
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)/dev/sda1 on /var/log.hdd type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)Legalább van noatime.
Ugyanakkor maga a diszk elvileg támogatja:
root@odroidn2:/home/vz# lsblk --discardNAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZEROsda 0 4K 4G 0└─sda1 0 4K 4G 0sdb 0 0B 0B 0└─sdb1 0 0B 0B 0mmcblk1 0 4M 3.5G 1└─mmcblk1p1 0 4M 3.5G 1zram0 0 4K 2T 1zram1 0 4K 2T 1root@odroidn2:/home/vz# hdparm -I /dev/sda | grep TRIM* Data Set Management TRIM supported (limit 8 blocks)Innen ti merre indulnátok tovább? Simán tegyem be a "discard" opciót az fstab-ba? Illetve olvastam az "fstrim" toolról, de őszintén szólva nem tiszta, hogy mi volt a gond a "discard" mountolással, miért kellett új valamit kitalálni?
-
I02S3F
addikt
Sziasztok! Ha érdekl a Linux és szeretném behatóbban megtanulni, akkor egy Linux rendszergazda, vagy Linux rendszerüzemeltető pozi e cél elérésére alkalmas lenne? (Fél év múlva ehhez lesz papírom, mérnökinfó felsőoktatási szakképzés) Mit gondoltok?
(Most a cél pozi érdekelne és nem a learning path) -
válasz
bambano
#30317
üzenetére
Gondolom nem teljesen haladó a kérdésem, de tudnátok segíteni?
Ez parancssorból simán lefut és küld szép emailt:clamscan -i -r /home |& mail -s "Az új szerver home vírusellenőrzése lezajlott" rootA cronból viszont megint ezt kapom:
Cron <root@szerverneve> clamscan -i -r /home |& mail -s "Az új szerver home vírusellenőrzése lezajlott" rootjún. 13., Szo 4:30 címzett: root/bin/sh: 1: Syntax error: "&" unexpectedMit rontok el?
-
radi8tor
MODERÁTOR
Ugyanazt írja utána is. Feltette a kérdést első alkalommal, Y nyomtam.
root@gp-wifi-01:/home/admin# apt-get update
Ign:1 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:5 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:7 http://archive.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Err:5 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Hit:8 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease
Fetched 256 kB in 2s (165 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Failed to fetch http://repo.mongodb.org/apt/ubuntu/dists/xenial/mongodb-org/3.4/Release.gpg The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@gp-wifi-01:/home/admin# apt update
Ign:1 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Get:2 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:3 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Hit:4 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:5 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Err:3 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Get:7 http://archive.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:8 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease
Fetched 256 kB in 1s (182 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Failed to fetch http://repo.mongodb.org/apt/ubuntu/dists/xenial/mongodb-org/3.4/Release.gpg The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Some index files failed to download. They have been ignored, or old ones used instead. -
radi8tor
MODERÁTOR
Egy ideje ezt írja minden frissítés ellenőrzésnél. Mit lehet/kellene ezzel csinálni?
root@gp-wifi-01:/home/admin# apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-security InRelease
Ign:6 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Get:7 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:8 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Err:8 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Get:5 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease [3,010 B]
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
E: Repository 'https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease' changed its 'Suite' value from 'oldstable' to ''
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
root@gp-wifi-01:/home/admin# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. -
-
lehet valahogy az egérmozdulatokat eseményként értelmezni?
tehát pl amíg mozog az egér X irányba, addig fusson le ez. ha megállt, akkor az, ha -X irányba, akkor amaz. -
Jester01
veterán
válasz
szoke12
#30318
üzenetére
Ha beállítottad a default gatewayt és engedélyezve van az ip forward akkor nyilván fogod látni a másik címet is mivel a csomagod akkor a gatewayhez megy mint ismeretlen cím. Ütközésből szerintem nem lesz probléma ha nem akarsz azokra a címekre forgalmazni.Ha zavar akkor tűzfal szabállyal megmondhatod, hogy dobja el az ilyen csomagokat (már ha a default gw vagy az ip forward kikapcsolása nem járható). Vagy kliens oldalon is csinálhatsz olyan route táblát ami nem küldi ki a másik tartománybeli csomagot.
-
-
szoke12
őstag
Sziasztok!
Keresgéltem a fórum keresőjében, de nem találtam egyértelmű választ a kérdésemre.
Nem túl régóta kezdtem a hálózati dolgokkal foglalkozni linuxon, úgyhogy elnézést, ha buta kérdésem lesz.Adott egy gép (konkrétan egy debian linuxon futó lxc - ebben kell megoldanom), és van benne 2 hálókártya. Tehát:
LAN1 (192.168.0.0/24 - DHCP) <> (192.168.0.x) LXC (192.168.1.90) <> LAN2 (192.168.1.0/24)
Miért van az, hogy ha a LAN1-re csatlakozok, és ott nem dhcp-től kérek címet, hanem 1-es tartománybeli statikus címet használok, akkor látom az lxc LAN2-beli IP-jét?
Vagyis a LAN1-ben eléthető a 192.168.1.90.
A baj az, hogy egy hálózatba kellene tennem sok ilyen kis lxc-t ugyanolyan konfigurációval.Előre is köszönöm a válaszokat!
-
Ubuntu 20.04 szerver. Megkértem a cron-t, hogy futtassa a clamscant és küldjön az eredményről levelet:
0 4 1 * * clamscan -i -r /MENTES | mail -s "Az új szerver MENTES vírusellenőrzése lezajlott" root
Kapok is levelet:Az új szerver MENTES vírusellenőrzése lezajlott2020. jún. 1. 6:23 (8 nappal ezelőtt)címzett: root/MENTES/Tablet/moborobo.exe: Win.Malware.Installcore-6951886-0 FOUND----------- SCAN SUMMARY -----------Known viruses: 7108171Engine version: 0.102.3Scanned directories: 2600Scanned files: 41235Infected files: 1Data scanned: 55997.88 MBData read: 289179.30 MB (ratio 0.19:1)Time: 8593.090 sec (143 m 13 s)A gond, hogy kapok egy másikat is ha a clamscan-nek gondja akadt:
Cron <root@szerverneve> clamscan -i -r /MENTES | mail -s "Az új szerver MENTES vírusellenőrzése lezajlott" rootjún. 1., H 6:23 (8 nappal ezelőtt)címzett: rootLibClamAV Warning: Bytecode run timed out in interpreter after 261030000 opcodesLibClamAV Warning: Bytecode 35 failed to run: CL_ETIMEOUT: Time limit reachedLibClamAV Warning: Bytecode run timed out in interpreter after 260935000 opcodesLibClamAV Warning: Bytecode 35 failed to run: CL_ETIMEOUT: Time limit reachedLibClamAV Warning: cli_scanxz: decompress file size exceeds limits - only scanning 27262976 bytes
Az utóbbit miért kapom, és miért a teljes parancssor a levél címe? -
-
lordkolya
újonc
Sziasztok!
Remélem jó helyre írok,kis segítséget kérnék hátha van valakinek ötlete a problémámra.
Bind9 DNS szervert használnék a domain-em kezelésére. Teszt jelleggel a modem/routert bridge módba raktam meg is kapta a szerver a Public IP címet. Minden tökéletesen is működött, 15 percen belül frissültek is mindenhol a DNS rekordok. Ezzel kiderült hogy a szolgáltató nem blokkolja az 53-as portot.
Vissza tettem a modemet és így már nem frissülnek a rekordok.. beállítottam a port forwardot, nmap, telnettel teszteltem el is éri a szervert, listázta hogy az 53-as port nyitva. Dig Any <sajatdomain.hu> @<az én public IP címem> fel is oldja látom az összes rekordot, de ha csak Dig A <sajatdomain.hu> @<az én public IP címem> vagy dig SOA <sajatdomain.hu> @<az én public IP címem> ezeket már egyenként nem. -
#30308
lionhearted
őstag
Lenry
#30306
-
#30305
inf3rno
nagyúr
lionhearted
#30304
inf3rno
nagyúr
válasz
lionhearted
#30304
üzenetére
Nem igazán jött össze a linkelés...
-
#30304
lionhearted
őstag
kovaax
#30301
válasz
kovaax
#30301
üzenetére
Nem tértek, és jobb is így. Az említett docker is igen parádésan viselkedik mondjuk egy CentOS8 firewalld+nftables környezetben....
A lényeg amúgy is az, hogy ezeket már többnyire backendnek tekintik, ez elé teszik az ufw/firewalld/egyéb szolgáltatásokat.
Ezért szomorú, hogy az erre buzdító hozzászólásomat gyakorlatilag mindenki ignorálta. A probléma, és néhány megoldása: [link]
Bár akkor gondolom érdemes a meta kulcszót csak akkor használni, amikor feltétlenül szükséges, mert lassabb lesz az adott szabály feldolgozása, mintha csak a payload-ban lévő adatokra match-elnék? 
Új hozzászólás Aktív témák
Hirdetés
- Kínai és egyéb olcsó órák topikja
- Medence topik
- Kerékpárosok, bringások ide!
- Villanyszerelés
- Motoros topic
- A fociról könnyedén, egy baráti társaságban
- Befutott a megígért HRV-mérés a Withings órájára
- Stellar Blade
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- PlayStation 5
- További aktív témák...
- BESZÁMÍTÁS! XFX MERC 310 RX 7900 XTX 24GB videokártya garanciával hibátlan működéssel
- Bomba ár! Lenovo ThinkPad T480s - i7-8GEN I 16GB I 256GB I 14" WQHD I HDMI I Cam I W11 I Gari!
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Lenovo ThinkPad L16 Gen 1 Prémium
- DELL Precision 7540 - Intel Core i9-9980HK, RTX 3000 (nagyon erős GPU-val)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest