-
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
-
-
xabolcs
őstag
válasz
CPT.Pirk #34968 üzenetére
A "systemctl enable" es "systemctl disable" csak a gepinditaskori automatikus indulast befolyasoljak.
Attol, hogy valami nem indul automatikusan a geppel egyutt, attol meg minden tovabbi nelkul indithato kezzel a "systemctl start" paranccsal.
Amit te szeretnel, hogy kezzel se lehessen inditani, az a "systemctl mask"!
man systemctl-bol:
is-enabled UNIT...
Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if
at least one is enabled, non-zero otherwise. Prints the current enable status (see table). To suppress
this output, use --quiet. To show installation targets, use --full.
Table 1. is-enabled output
┌──────────────────┬───────────────────────────────┬───────────┐
│Name │ Description │ Exit Code │
├──────────────────┼───────────────────────────────┼───────────┤
│"masked" │ Completely disabled, so that │ │
├──────────────────┤ any start operation on it │ │
│"masked-runtime" │ fails (permanently in │ > 0 │
│ │ /etc/systemd/system/ or │ │
│ │ transiently in │ │
│ │ /run/systemd/systemd/). │ │
├──────────────────┼───────────────────────────────┼───────────┤A masik pedig "mask" parancs leirasa:
mask UNIT...
Mask one or more units, as specified on the command line. This will link these unit files to /dev/null,
making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of
activation of the unit, including enablement and manual activation. Use this option with care. This honors
the --runtime option to only mask temporarily until the next reboot of the system. The --now option may be
used to ensure that the units are also stopped. This command expects valid unit names only, it does not
accept unit file paths. -
-
-
-
válasz
CPT.Pirk #34603 üzenetére
[lenry@Echo-Three ~]$ vainfo
Trying display: wayland
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 25.1.3 ()
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileNone : VAEntrypointStats
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointFEI
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointFEI
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointFEI
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointFEI
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD -
Vasti74
senior tag
válasz
CPT.Pirk #34578 üzenetére
Nem tudom, hol és hogyan lehet ezt megnézni?
De csodálkoznék, ha ezzel lenne baj: 90%-ban Youtube videókat nézek, és azoknál elő sem fordulhat olyan formátum, amit ez a DAC nem támogat.
Ráadásul sokszor történik olyan, hogy nézek egy videót, van hangja, megállítom valamiért, és amikor folytatnám, már csak fehérzaj. -
Vasti74
senior tag
válasz
CPT.Pirk #34494 üzenetére
Persze, folyik a tesztelés ;-) Az már biztos, hogy KDE lesz, mert nem érdekel hogy hogyan ;-) , de működik úgy, ahogy az elvárható. Hogy milyen disztribúció, azt kellene már csak kitalálnom. Nem könnyű, mert ugye bármire vannak érvek és ellenérvek, ha megkérdezi az ember egy fórumon ;-)
-
Vasti74
senior tag
válasz
CPT.Pirk #34473 üzenetére
Na még egy lehetőség ;-) Már a Fedora-tól is kezdtem megijedni, de amit az Arch-ról tudok, szerintem jobb, ha bele sem kezdek ;-)
A böngésző hardveres gyorsítása nem a legnagyobb probléma (és nálam pl. az működik is, úgy néz ki) De a VLC még annyira sem működik, mint a böngésző, ha nem 100-200 a skálázás. Mint és Cinnamon alatt legalábbis - KDE-vel használhatónak tűnik, a proci meg dolgozzon csak a van, de nincs hardveres támogatás helyett ;-) -
Vasti74
senior tag
válasz
CPT.Pirk #34455 üzenetére
A hardvernek biztosan nem gond a 4k (az UHD 630 hardveresen egyidejűleg elméletileg három 4k videót tud dekódolni) , Windows és macOS alatt működik is minden teljesen jól.
A laptopom FullHD kijelzőjén minden OK, és az asztali gépem is elvágólag onnantól vacak, hogy lecseréltem a monitoromat 4k-ra: előtte 1920x1200-as volt, azzal gördülékenyen működött minden.
Kipróbálom majd először Ubuntu-val, aztán mással ;-) , mindenképpen megírom, hogy azok hogyan működnek - csak motivációt kell gyűjtenem, hogy egyáltalán nekiálljak ;-)
Már arra is gondoltam, hogy visszateszem a régi monitoromat... De annyira jó képen van ennek a kis LG 24UD58 monitornak, hogy nem nagyon akarnám újra a régit nézni ;-)
Hát, ez van, dolgozok tovább a probléma megoldásán... De ma újra elkezdtem azon gondolkodni, hogy akkor Windows, vagy macOS? ;-) -
Vasti74
senior tag
válasz
CPT.Pirk #34453 üzenetére
Próbálok majd live rendszereket, de szívesen maradnék "debian" vonalon, mert azt szoktam meg.
Két különböző vason próbáltam: Mint Cinnamon az asztalin, Mint MATE a laptopon, és ugyanaz a hiba.
Még gépet is cserélnék (a laptop nem fontos, 90%-ban csak arra használom, hogy Windows alatt a navigációkat frissítsem) , ha biztos lennék abban, hogy az Intel + linux a hiba: de amennyit eddig utánaolvastam, más grafikus kártyákkal és más disztribúciókkal is problémás a 4k felbontás :-(
Csak nem nagyon van kedvem és energiám ezzel szórakozni, már régóta "csak" használni szeretném a gépet úgy, hogy feltelepítem, és működik. Eddig így volt ;-)
Tudom, bennem is nem kevés hiba van ;-) , mert a Windows-t sem bírom "elviselni", és a macOS sem nekem készült, sajnos nagyon megszoktam már a linuxot. Erre most ez a baromság ért utol: huszonév után az van, hogy használnám a gépet, és nem működik rendesen. Gáz ;-) -
-
urandom0
senior tag
válasz
CPT.Pirk #34332 üzenetére
A Github oldalon írnak róla:
The etc directory of the repo contains sample configuration files for different init(1) systems, e.g. FreeBSD's rc.d, Gentoo's openrc, and systemd which is used in most contemporary Linux distros. Those files may be used as templates. They are likely to require adjustments to the actual distribution/installation where they are to be used.
A Github repóból másold ki a /etc/systemd/wsdd.service fájlt, másold be a saját /etc/systemd/system könyvtáradba, a wsdd.defaults fájlt pedig mentsd le egy /etc/default/wsdd nevű fájlba. Aztán mondd neki, hogy
systemctl daemon-reload
, majdsystemctl enable --now wsdd.service
, és elmiletileg már fut is a service. -
sonar
addikt
válasz
CPT.Pirk #34319 üzenetére
Olvasd el ezt hátha segít: WSDD, avagy hálózati felderítés
-
válasz
CPT.Pirk #34319 üzenetére
Windows alatt a mappákban van egy olyan lehetőség, hogy a hálózati mappát hozzá tudod adni. Tudsz neki betűjelet adni, bejelentkezési adatokat megadni meg ilyenek.
[link] Ezt találtam hirtelen.
Nálam mondjuk a 11 tudja alapból. Lehet azért mert a NASomnak van drivere hogy keresse hálózaton a mappákat. -
bambano
titán
válasz
CPT.Pirk #34281 üzenetére
valójában nem teljesen nagyobb írási sebességről szól a történet, hanem konstans késleltetésről. ezt úgy éri el, hogy kevésbé foglalkozik az írási hibákkal, ettől lesz kicsivel gyorsabb. a kamerarendszereknél kevésbé fontos, hogy egy-egy kép részlete megőrződjön, sokkal fontosabb, hogy hiba esetén a többi kép rögzítésre kerüljön.
igaza van ubyegon2-nek, az a diszk csak kamera real time rögzítésére való, másra nem.
-
válasz
CPT.Pirk #34281 üzenetére
Ha másként tudod, akkor OK, én sehogy se tudtam, ezért is idéztem anno a Western Digital nevű cégtől.
Nagyobb írás sebesség az fura, mert vagy 5400rpm vagy 7200rpm, volt 10000rpm-es is WD-nek, de hogy az nem surveillance célra készült, az tuti. Nem is a rendszer futtatása volt nem ajánlott, hanem a desktopban használat, gondolom a fs miatt.
Szóval a WD szerint ez volt...
-
válasz
CPT.Pirk #34277 üzenetére
Mondjuk tök jó, hogy kifejezetten 24/7-es üzemre való, kamerarendszerhez kitalált hdd-t használtam és alig 4 évet bírt ki...
A legdurvább hibát követted el egyébként, sok gyártó le is írja, hogy ne alkalmazza rendszermeghajtónak és azokkal azonos fájlrendszeren futó merevlemezként! Van ugyanis a surveillance merevlemezeknek egy spéci tulajdonsága, viszonylag nagy hibatűrése van a bitek rögzítésénél és ezt a normál fájlrendszerek folyamatos kűzdelemmel próbálják helyrehozni! Az a 4 év így komoly teljesítmény volt!
(az újabbak nem tudom ilyenek-e még, de a régebbiek tuti így működtek, ha jól rémlik AV-GP volt a kategória neve)
Leltem is egy régi bejegyzést most...[link]
Not For Desktop Use - ez a kulcsszó
-
#63718632
törölt tag
válasz
CPT.Pirk #34273 üzenetére
Persze, csak azért mondtam. Ha egy ilyen művelet közben "kotlik" meg végképp, akkor nincs tovább. Viszont, ha túl él egy dd image mentést, akkor végtelenségig lehet próbálkozni.
Tudom a szükség is nagy úr. Nincs mindig épp elég szabad hely valahol, egy ekkora image-nek sem. -
bambano
titán
válasz
CPT.Pirk #34231 üzenetére
nekem az a problémám, hogy ha egy gép nincs publikus hálózaton, nincs vele baj, akkor minek hozzányúlni?
frissíteni? mióta systemd van a legtöbb disztróban? öngyilkosság.
ha nincs olyan sérülékenység vagy hiba, ami téged konkrétan akadályoz és a frissítés megoldja, akkor felesleges frissíteni. főleg, ha "annyi meló van".ismétlem magam: ha nem romlott el, ne akard megjavítani.
-
urandom0
senior tag
válasz
CPT.Pirk #34222 üzenetére
Ilyen célokra érdemesebb hosszabb támogatású disztrót használni. Nem tudom, Canonical háza táján milyen megoldások vannak erre, de az aktuális Rocky Linux security supportja 2032-ig tart.
-
-
Anakin007
aktív tag
válasz
CPT.Pirk #34184 üzenetére
A 24.04.-ben csesztek (?) el valamit szerintem. Lenovo T410-em úgy fejre állt az upgrade következtében, hogy ki sem tud loggolni semmit, azonnal kifagyott, amint X-et indítottam. Furcsa, de kb. 10/1 próbálkozással nem fagyott ki, elindult a KDE is, de még az egér is darabosan mozgott, majd kifagyott. Annyi derült ki, hogy valami a VGA driver-el volt, ami kernel-panic -ot okozott. Másoknak is volt ugyanilyen gondja, de megoldást nem talált rá senki tudtommal.
Csináltam custom kernel-t, 6.9.3-al, de ugyanaz történt. Szerintem a 6.8.xx-es kernelnél lett valami, ami alapból van a 24.04 LTS-ben is. Tovább nem szórakoztam, visszatettem a Kubi 22.04 LTS-t, mivel desktop-nak kell. Esetleg, ha mindenképp 24.04-et akarsz, egy korábbi, 6.6.xx -es kernelt dobj alá, hátha.. Jah, nekem régi Intel-es, integrált VGA-m van, ami ezt okozta. -
-
-
válasz
CPT.Pirk #33822 üzenetére
Ezért is írtam, hogy erősen hardverkörnyezetfüggő a dolog. Ha a kétszeres sebességű PCIe 4.0 nem gyorsabb, mint a feleolyan gyors 3.0, akkor ezzel igazoltuk is, hogy adott régi hardverben a Sata 2 és Sata 3 között sem lesz különbség igazán. De most is a szekvenciális sebességekről beszélünk, holott a rendszerfuttatást az access time érdekli. Fura dolgok meg nyilván vannak, az előbb említett desktopban a Sata3-as 860 EVO 1TB kb 5x olyan gyorsan bootolt, mint a PCIe 3.0 980 1TB!
No de ez nyilván a legacy/EFI miatt volt. Maga a Samsung 860 EVO a régi Elitebookos telepített OS-sel kerül a desktopba, így az legacy install volt nyilván.
-
kovaax
őstag
válasz
CPT.Pirk #33631 üzenetére
A scriptbe bele kéne írni egy rakat környezeti változót, ami terminálban be van állítva, de amikor gui-ból indítod, valamiért nincs. Mondjuk kezdésnek a második sorba beírnám, hogy
set > /tmp/set-gui.txt
, aztán futtatnám gui-ból, majd terminálból, csakset-term.txt
-be, osztdiff
. -
-
csixy
addikt
válasz
CPT.Pirk #33256 üzenetére
Csinálnék egy debian telepítést élesre, ezt úgy kezelném a magam szemszögéből, mintha nem írnék a saját user mappájába soha közönséges mindennapi használat mellett. Megtanítanám neki hogy milyen külső tárolókra hova és hogyan mentsen. Ezután a Linux Live Kittel csinálnék belőle egy konzervet. [link] , [link] Ezt a konzervet telepíteném a megfelelő mennyiségű RAM-mal ellátott munkahelyi gépre és load live to ram opcióval elindítanám. Ha leáll egy áramszünet miatt, akkor is így kell megint elindítani. ... Az eredeti telepítéssel követném a fejlesztéseket frissítéseket és időnként csinálnék belőle egy újabb konzervet. ... Ez így biztosan műköködik, kipróbáltam számtalanszor, de csak a debiánt szereti.
-
válasz
CPT.Pirk #33256 üzenetére
Tegyük fel, hogy szünetmentes táp ellenére is előfordulhat, hogy kihúzzák a tápot vagy egyszerűen nem szabályosan állítják le, csak kinyomják... Ragaszd bele a gép kábelét a szünetmentesbe
(Komolyan)
Ilyesmi működhet, pl. embedded rendszerek esetén rendszeres. A kulcsszó az overlayfs. Az ext4 elég elavult fájlrendszer, lehet érdemes elgondolkozni egy BTRFS-en. Az biztosan feljön crash után, max. elvesznek egyes fájlok. Az ext4 simán lehalhat teljesen.
(#33257) emvy Nem szabad kikapcsolni a page cachet, mert baromi lassú lesz. Inkább limitálni kell, hogy mennyi ideig lehetnek a dolgok a memóriában [link]
-
gregory91
senior tag
válasz
CPT.Pirk #33139 üzenetére
A Hangerőszabályozó kilistázza azokat a folyamatokat amiket lejátszik és külön-külön be lehet állítani azok hangerejét.
Mivel egyes böngézők esetén(elsősorban chromium motor-szerinti) minden egyes fül külön folyamatként működik,így értelemszerűen fülönként külön be lehet állítani azok hangerejét.
Mint ahogy a lenti példám mutatja: -
urandom0
senior tag
válasz
CPT.Pirk #32981 üzenetére
Nagyon szépen fejlődik a KDE, közel sem olyan omlós már, mint régen volt. Ezeket a hibákat, amik nálam előjönnek, szerintem a gép, a kernel vagy valamelyik modul okozza. Pedig nem egy dzsunka vacak laptopot használok, hanem egy Thinkpadet, de akármilyen Linux van rajta, olyanokat csinál, hogy pl. ébredés után másképp érzékeli a touchpad-et, mint közvetlen boot után. Boot után valami Think... valami a neve (most nincs előttem a gép), ébredés után pedig már SynPS/2 Synaptics TouchPad-nek látja az xinput, és ezzel együtt elállítódik az érzékenysége, a kétujjas görgetés, minden.
Sokszor az egeret sem érzékeli ébredés után, de erre már írtam egy scriptet.
Illetve újabban mint ha halkabban lennének a hangszórók, mint korábban, bár lehet, hogy csak az én fülem romlik
Viszont hamarosan jön a KDE 6, reméljük nem lesz olyan nehézkes a váltás, mint 4-ről 5-re
-
urandom0
senior tag
válasz
CPT.Pirk #32970 üzenetére
2-3 naponta új kernel??? Az komoly... igazából nekem nem kellenek annyira friss csomagok, inkább legyen stabil a cucc. Alapvetően egy Debiannal is elvagyok, csak azért jó lenne, ha Xfce-ből nem a 4.16-os lenne benne, hanem legalább a 4.17-es, mert abban már lehet rendezgetni a Thunar eszköztárát
De ha azt mondod, hogy nem kellett kézzel utánadolgozni, akkor szerintem teszek vele egy próbát. -
urandom0
senior tag
válasz
CPT.Pirk #32968 üzenetére
A gyakran jönnek frissítések mit jelent? Hetente többször?
Két gépemen Kubuntu van egy ideje, és az őrületbe tud kergetni azzal, hogy a Discover naponta kicsapja az ikonját az értesítési területre, mert hogy neki frissíthetnékje van
Aztán a legtöbb esetben semmi különösebb indoka nincs rá, csak épp átrajzoltak két pixelt valamelyik telepített icon packban...
Ráadásul sokszor hibára fut a frissítés.Amúgy stabilnak stabil az Ende... szóval a rendszer?
Nem kell faragni a frissítések után? -
vargalex
félisten
válasz
CPT.Pirk #32939 üzenetére
De, ahogy láthatod, nálam nem ezek az értékek, mégsem tapasztalom a problémát...
-
vargalex
félisten
válasz
CPT.Pirk #32936 üzenetére
Minden gyári értéken van. A centisecs és seconds értékek különböznek a tiédtől (de a home szerveremen is ezek az értékek vannak, ami szintén vanilla Arch, de ott csak 4 GB RAM van) :
[gavarga@gavarga-5500 ~]$ sudo sysctl -a | grep dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
-
bambano
titán
válasz
CPT.Pirk #32931 üzenetére
Milyen gyakran változik a memória a gépedben?
Nekem pl. úgy tud változni a memória a gépemben, hogy kihúzom a madzagot több desktopból, utána a racket, ami ezeket a desktopokat tartalmazza, kigurítom, kiveszem a gépet, szétborítom, megváltoztatom a ramot, majd mindezt vissza. közben értelemszerűen takarítok is, mert muszáj.
Ebbe a 2-3 órás procedúrába nekem belefér, hogy még egy szkriptet lefuttatok, bemásolok két fájlt a helyére, majd egy reboot.Azt nem gondolnám jó mérőszámnak, hogy tele van vele a google. Akinek nincs ilyen problémája, az nem írja tele a google-t, vagyis nem egyenletes a statisztika.
-
vargalex
félisten
válasz
CPT.Pirk #32931 üzenetére
Én nem futtattam le az általad említett maxperfwiz-t. Vanila Arch-on vagyok (16 GB RAM van a gépben). Most másoltam dd-vel (4 MB block size-val, oflag=sync kapcsolóval) egy külső 500 GB-os 2,5"-os HDD-re egy 67 GB-os file-t. Folyamatosan tartotta a sebességet, csak a szokásos mértékben lassult, ahogy haladt előre (a lemezen befelé).
-
bambano
titán
válasz
CPT.Pirk #32929 üzenetére
Én nem azzal vitatkoztam, hogy neked mire van szükséged, hanem ezzel: "fel lehetne ezt vetni, hogy ilyesmit be kellene építeni valakinek valahová..." (ezt mondjuk könnyen lehetne látni abból, hogy melyik hsz-re válaszoltam)
két érvem volt ellene:
1. nem építünk be semmit, ami elvi hibás
2. az általa javasolt dolgok nem általános problémák. -
-
bambano
titán
válasz
CPT.Pirk #32923 üzenetére
végignyomogattam, szerintem tévedés az egész.
azzal az alapvető hibával indít, hogy swappinest akar barkácsolni, miközben nincs swap.
a másik, hogy ilyen 200-300 megabyte puffereken vekeng, miközben pl. nekem 128 giga ramom van.
engem valahogy totálisan nem bír felizgatni, hogy jelenleg 9 és fél óra uptime után (ez a desktopom) 122 giga ram van szabadon vagy 120 vagy 125 vagy a franc se tudja, mennyi.ha te boldog vagy vele, használd. de hogy ez default bekerüljön egy disztróba csak azért, hogy default azonnal töröljem, annak sok értelme nincs.
ettől még nyithatunk vitát, hogy rendben van-e a linux block device layer (nincs), de az egy másik kérdés.
-
f_sanyee
senior tag
válasz
CPT.Pirk #32923 üzenetére
az, hogy 1-2 ilyen érték módosításával neked pozitív tapasztalataid vannak, nem jelenti azt, hogy nincs olyan negatív hatása amit te nem veszel észre, vagy más rendszereken nem jön ki.
én pl kb soha nem mozgatok fileokat se másik particióra, pendrivera meg főleg, valamint az általam üzemeltett serverek még csak pendrivet sem láttak.egyébként a fenti scriptet elég egyszer futtatni és elfejeteni.
-
Penty
aktív tag
válasz
CPT.Pirk #32774 üzenetére
Reggel 5 körül ébredtem, valamivel el kellett ütni az időt.
"Az áthelyezés ideje pár százalékot romlott..."
Azt hiszem a pontosabb megfogalmazás itt inkább az lenne, hogy a prompt visszaadás ideje "romlott" valamicskét, maga a művelet a prompt visszaadásával ténylegesen befejeződött. Nincs az, hogy még pár másodpercig (pár tíz másodpercig) a háttérben fut a művelet a prompt visszaadása után.
@ (#32775) ivana
Alapból nem szoktam létrehozni dd-vel ilyen fájlokat és azokat másolgatni ide-oda, ezt most csak egy amatőr próba kedvéért tettem, hogy lássam, hogyan befolyásolják a módosított értékek az írási sebességet és stabilitást. Mindenesetre köszi az infót! -
Penty
aktív tag
válasz
CPT.Pirk #32772 üzenetére
Ez lett a hatása:
Elkezdtem a belső és egy külső usb-s hdd között egy pont 2G-os (dd if=/dev/zero of=test1.dd bs=1M count=2048) anyagot oda-vissza mozgatni többször egymás után 40-60 mp-es "pihenőkkel". A mozgatásra az rsync-et használtam: rsync -ahv --info=progress2 --remove-source-files $source $destination
Ezek voltak tehát az alapértelmezett értékek, amikhez hozzányúlt a script:
vm.swappiness = 60
vm.vfs_cache_pressure=100
kernel.nmi_watchdog=1
vm.dirty_ratio=40
vm.dirty_background_ratio=10
vm.dirty_expire_centisecs=3000
vm.dirty_writeback_centisecs=1500
vm.min_free_kbytes=67584Értékek (rövidítve)
60 100 1 40 10 3000 500 675841. menet
hdd > usbhdd 01:02 33.83M bytes/sec
usbhdd > hdd 00:17 122.74M bytes/sec
2. menet
hdd > usbhdd 00:59 35.50M bytes/sec
usbhdd > hdd 00:04 390.55M bytes/sec
3. menetv
hdd > usbhdd 01:03 33.30M bytes/sec
usbhdd > hdd 00:10 204.57M bytes/sec
4. menetv
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:04 390.55M bytes/sec
5. menetv
hdd > usbhdd 00:27 75.37M bytes/sec
usbhdd > hdd 00:10 204.57M bytes/secHDD-ről az USBHDD-re: Sokszor megakad az áthelyezés, másodperceket vár, majd hirtelen nagy sebességgel megindul, majd megint megáll. A prompt előbb jött meg, mint ahogy a feladat befejeződött volna.
500-600MB/s-ról indul, majd egyre csökken, de nagyon ugrál. Az egyik menetben 27 mp után visszaadta a promptot, de az usbhdd ledje még 30-40 mp-ig villogott jelezvén, hogy a valóságban még tart az áthelyezés. (Tovább kísérletezve vele volt, hogy 4-5 mp alatt visszakaptam a promptot, de persze a külső lemez még dolgozott vagy egy percig!)USBHDD-ről HDD-re: Ugyanez volt megfigyelhető az usbhdd-ről hdd-re másolásnál is. Gyorsan visszakaptam a promptot, de utána még jó pár másodpercig villogott a laptop hdd aktivitást jelző ledje.
500-600 MB/s-ről indul, de a sebesség nagyon ugrált, sokszor 1-2MB/sec, aztán meg +100MB/sec. Nem volt egy nagyjából stabil sebesség.Összegzés: Nagyon ingadozó sebesség, "hamis" befejezettséget jelző prompt visszaadással.
----------
Srcipt futtatása után:
10 75 0 5 5 3000 1500 2324541. menet
hdd > usbhdd 01:01 34.37M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
2. menet
hdd > usbhdd 01:14 28.83M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
3. menet
hdd > usbhdd 00:56 38.02M bytes/sec
usbhdd > hdd 00:23 91.40M bytes/sec
4. menet
hdd > usbhdd 00:57 36.72M bytes/sec
usbhdd > hdd 00:22 95.47M bytes/sec
5. menet
hdd > usbhdd 00:57 36.72M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/secHDD-ről USBHDD-re: Megakadás nem igazán volt.
300-400MB/s-ről indul, majd egyre csökken, végül 20-50 között ingadozik (néha kicsit több, néha kicsit kevesebb).
Lényegesen kevésbé ingadozik, mint az alapértelmezett beállításokkal.
Az áthelyezés ideje nem sokat változott. Az igazi nyereség, az az ingadozás csökkenése, valamint az, hogy a prompt visszakapása után pár mp-ig még villog a led, de lényegesen kevesebb ideig, mint a fenti esetben.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
200-300MB/s-ről indul, majd egyre csökken, végül nagyjából 50-90 között ingadozik.
Ez is lényegesen kevésbé ingadozik, mint a fentebbi az alapértelmezett beállásokkal.
Az áthelyezés ideje elég stabilan 23 mp körül van, nincsenek nagy kiugrások. A prompt visszakapása után 1 másodperccel később a laptop hdd aktivitást jelző ledje is kialszik.Összegzés: Lényegesen kisebb ingadozás, a prompt visszakapása után pár mp-cel ténylegesen befejeződik a művelet.
----------
Általam végzett módosítások
10 75 0 3 3 3000 1500 2324541. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/sec
2. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:26 81.06M bytes/sec
3. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:24 84.24M bytes/sec
4. menet
hdd > usbhdd 01:01 34.93M bytes/sec
usbhdd > hdd 00:23 91.40M bytes/sec
5. menet
hdd > usbhdd 01:00 34.93M bytes/sec
usbhdd > hdd 00:24 84.24M bytes/secHDD-ről USBHDD-re: Megakadás nem igazán volt.
100-200MB/sec-ről indult, majd beállt 20-40MB/sec közé. Még kisebb az ingadozás.
Az áthelyezés ideje nem változott. A prompt visszakapása után 2-3 mp-ig még villog a led.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
200-300MB/s-ről indul, majd egyre csökken, végül nagyjából 50-80 között ingadozik.
Az áthelyezés ideje itt is elég stabilan 23 mp körül van, nincsenek nagy kiugrások. A prompt visszakapása után azonnal kialszik a laptop hdd aktivitást jelző ledje.Összegzés: Még kisebb ingadozás, a prompt visszakapása után ténylegesen befejeződik a művelet a külső hdd-ről a belső hdd-re mozgatásnál, de fordítva is csak 2-3 mp-et kell várni a tényleges befejezésre.
----------
Újabb általam végzett módosítások
10 75 0 1 1 3000 1500 2324541. menet
hdd > usbhdd 01:05 32.79M bytes/sec
usbhdd > hdd 00:23 87.67M bytes/sec
2. menet
hdd > usbhdd 01:05 32.30M bytes/sec
usbhdd > hdd 00:24 87.67M bytes/sec
3. menet
hdd > usbhdd 01:06 32.30M bytes/sec
usbhdd > hdd 00:28 75.37M bytes/sec
4. menet
hdd > usbhdd 01:05 32.30M bytes/sec
usbhdd > hdd 00:26 78.11M bytes/sec
5. menet
hdd > usbhdd 01:05 32.79M bytes/sec
usbhdd > hdd 00:25 81.06M bytes/secHDD-ről USBHDD-re: Megakadás nem volt.
100-150MB/sec-ről indult, majd beállt 28-32MB/sec környékére.
Az áthelyezés ideje 5-6 mp-et romlott, viszont a prompt visszakapása után azonnal megáll a lemezművelet is a külső lemezen.USBHDD-ről HDD-re: Megakadás nem volt itt sem.
100-150MB/s-ről indul, majd egyre csökken, végül nagyjából 65-80 között ingadozik.
Az áthelyezés ideje elég stabilan 24 mp körül van, ami egy leheletnyivel rosszabb mint az előző kettő. A prompt visszakapása után azonnal kialszik a laptop hdd aktivitást jelző ledje.Összegzés: Még kisebb ingadozás, a prompt visszakapása után ténylegesen befejeződik a művelet minden irányban. Az áthelyezés ideje pár százalékot romlott, de cserébe elég stabil a sebesség, nem ingadozik nagyon.
Ahogy elnézem a két érték csökkentésével az ingadozások amplitúdója lesz kisebb és az egész művelet a tényleges áthelyezési sebességhez közelebbi értékről indul el. Talán még majd megnézem az egészet 2-es értékkel is. Akkor talán megmarad a minimális ingadozás, de talán nem romlik az áthelyezési idő azzal a pár százalékkal.
-
Penty
aktív tag
válasz
CPT.Pirk #32762 üzenetére
A kiindulási pont nálam egy Void Linux egy közel 10 éves laptopon, amiben most egy 5200-as HDD van. Az alábbiak voltak az alapértelmezettek itt:
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=40
vm.dirty_writeback_centisecs=500
vm.dirtytime_expire_seconds = 43200A script még ezekhez is hozzányúlt, amiknek ez volt az alapértelmezett értéke:
kernel.nmi_watchdog = 1
vm.min_free_kbytes=67587
vm.vfs_cache_pressure = 100
vm.swappiness = 60A script futtatása után ezek az értékek lettek:
vm.swappiness = 10
vm.vfs_cache_pressure=75
kernel.nmi_watchdog=0
vm.dirty_ratio=5
vm.dirty_background_ratio=5
vm.dirty_expire_centisecs=3000
vm.dirty_writeback_centisecs=1500
vm.min_free_kbytes=232454Az udev-es beállítást átugrottam.
-
Siriusb
veterán
válasz
CPT.Pirk #32767 üzenetére
Ez a gyógyhatású változat, latin nevén Archea Vulgaris. Megtalálható otthonokban és irodákban, általában árnyékos helyen lelhető fel. Megfelelő körültekintéssel kell alkalmazni, jó kezekben idegnyugtató, görcsoldó, ám rosszul használva dührohamot és trágár beszédet okoz.
-
Siriusb
veterán
válasz
CPT.Pirk #32762 üzenetére
Ez lett az új, talán egy kivétellel nem fogadtam el a felajánlott értéket:
Contents of temporary file /tmp/maxperfwiz/99-maxperfwiz.conf:
vm.swappiness=10
vm.vfs_cache_pressure=75
kernel.nmi_watchdog=0
vm.dirty_ratio=3
vm.dirty_background_ratio=3
vm.dirty_expire_centisecs=3000
vm.dirty_writeback_centisecs=1500
Contents of temporary file /tmp/maxperfwiz/66-maxperfwiz.rules:
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}=
"mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
-
-
válasz
CPT.Pirk #32752 üzenetére
Ez de jól jött volna, amikor egy alkalommal két rendőrrel egy órán keresztül néztük egymást malmozva, miközben a térfigyelő kameráink felvételeit másoltam nekik egy pendrivera... Nekem volt kellemetlen, hogy mi a francért olyan tetves lassú, de nem küldhettem el őket, hogy "majd szólok ha megvan"
-
CPT.Pirk
Jómunkásember
válasz
CPT.Pirk #32654 üzenetére
Éééés úgy néz ki a 6.2-es kernellel kapunk megoldást erre a problémára... https://www.phoronix.com/news/AMDGPU-Fix-For-5.19-Bug
Új hozzászólás Aktív témák
- Maximális teljesítmény és biztonság, csak az ARCTIC mx-4-el! Adj új erőt a gépednek!
- BESZÁMÍTÁS! ASUS H170M i7 6700 16GB DDR4 512GB SSD GTX 1660 Ti 6GB KOLINK Observatory Lite TT 500W
- Wilbur Smith könyvek (15 db) egyben
- AKCIÓ! Lenovo Thinkpad T14 Gen 3 üzleti notebook - i5 1245U 16GB RAM 512GB SSD Intel Iris XeW11
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest