- Rap, Hip-hop 90'
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- gban: Ingyen kellene, de tegnapra
- Magga: PLEX: multimédia az egész lakásban
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Archttila: SMART tesztelés automatizálva: smartctl poller script Zsh-ban, RPi-re
- tatabike: Vinted - ahol debilnek néznek
-
LOGOUT
LOGOUT
Új hozzászólás Aktív témák
-
Sziasztok!
Régóta használok Linuxot. Néha csak arra vágyok, hogy "csak működjön" (mint például a Mint [kattintok kettős és minden probléma meg van oldva]), viszont az Arch-ban tetszik, hogy frissek a csomagok.
Ha script nélkül is képes vagyok feltenni az Arch-ot, akkor már használni is tudni fogom?
-
I02S3F
addikt
Sziasztok!
Régóta használok Linuxot. Néha csak arra vágyok, hogy "csak működjön" (mint például a Mint [kattintok kettős és minden probléma meg van oldva]), viszont az Arch-ban tetszik, hogy frissek a csomagok.
Ha script nélkül is képes vagyok feltenni az Arch-ot, akkor már használni is tudni fogom?
-
Sziasztok! Adott egy Arch / BTRFS / LUKS / SSD felállású rendszer. Az fstab subvolume mount optionök a következők: defaults,noatime,space_cache,autodefrag
Ez így rendben van? Nem kellene discard-ot (vagy discard=async-et) beállítani? Vagy a mai kernel már automatikusan trimmeli az SSD-ket? Hogy van ez? -
Sziasztok! Adott egy Arch / BTRFS / LUKS / SSD felállású rendszer. Az fstab subvolume mount optionök a következők: defaults,noatime,space_cache,autodefrag
Ez így rendben van? Nem kellene discard-ot (vagy discard=async-et) beállítani? Vagy a mai kernel már automatikusan trimmeli az SSD-ket? Hogy van ez? -
Sziasztok! Adott egy Arch / BTRFS / LUKS / SSD felállású rendszer. Az fstab subvolume mount optionök a következők: defaults,noatime,space_cache,autodefrag
Ez így rendben van? Nem kellene discard-ot (vagy discard=async-et) beállítani? Vagy a mai kernel már automatikusan trimmeli az SSD-ket? Hogy van ez? -
Lenry, Sonja:
Letöröltem a wxgtk2 csomagot. Ezután elindult az update és lecserélte az alábbiakat, de rendben lefutott. Akkor ez így rendben van?:: Teljes rendszerfrissítés indítása...
:: Lecseréli wxgtk-common-t erre: extra/wxwidgets-common? [I/n]
:: Lecseréli wxgtk3-t erre: extra/wxwidgets-gtk3? [I/n]Igen, neked nem volt más.
-
Lenry, Sonja:
Letöröltem a wxgtk2 csomagot. Ezután elindult az update és lecserélte az alábbiakat, de rendben lefutott. Akkor ez így rendben van?:: Teljes rendszerfrissítés indítása...
:: Lecseréli wxgtk-common-t erre: extra/wxwidgets-common? [I/n]
:: Lecseréli wxgtk3-t erre: extra/wxwidgets-gtk3? [I/n]yepp
pontosan ennek kellett történnie -
Ezt egy kicsit részleteznéd? Mert én is belefutottam és nem tudom mi legyen a dependency-vel.
$ sudo pikaur -Syu:: A csomagadatbázisok szinkronizálása...core naprakészextra naprakészcommunity naprakészmultilib naprakész:: Starting full AUR upgrade...Reading repository package databases...Reading local package database...hiba: nem sikerült előkészíteni a tranzakciót (nem sikerült kielégíteni a függőségeket):: wxgtk-common eltávolításával megtörik a(z) 'wxgtk-common' függőség amit wxgtk2 kér -
Ezt egy kicsit részleteznéd? Mert én is belefutottam és nem tudom mi legyen a dependency-vel.
$ sudo pikaur -Syu:: A csomagadatbázisok szinkronizálása...core naprakészextra naprakészcommunity naprakészmultilib naprakész:: Starting full AUR upgrade...Reading repository package databases...Reading local package database...hiba: nem sikerült előkészíteni a tranzakciót (nem sikerült kielégíteni a függőségeket):: wxgtk-common eltávolításával megtörik a(z) 'wxgtk-common' függőség amit wxgtk2 kér -
[link]
wxWidgets 3.2 provides a Qt frontend in addition to the GTK3 one, so packages have been renamed from wxgtk- to wxwidgets-. The GTK2 frontend is no longer provided. If you have wxgtk2 installed, the upgrade will fail witherror: failed to prepare transaction (could not satisfy dependencies) :: removing wxgtk-common breaks dependency 'wxgtk-common' required by wxgtk2
In such case, uninstall wxgtk2 first and then proceed with the upgrade.
Ebbe én is belefutottam. Sajnos pár csomagot le kellett szednem ahhoz, hogy felmenjen, nem volt elég a wxgtk2. De megoldottam.
-
borisz1994
csendes tag
-
Mobulla
csendes tag
Üdvözlök mindenkit. Van mód arra, hogy USB Live módban, a GPU driver-t ne töltse be induláskor?
-
jimmy399
senior tag
Üdvözlök mindenkit. Van mód arra, hogy USB Live módban, a GPU driver-t ne töltse be induláskor?
-
borisz1994
csendes tag
-
Tudom, hogy mi indítja...És pont azért írtam, hogy nem, nem látszik. Amit te bevágtál a status alatt, az nekem nincsen már jóideje, és erre utaltam, és ezért vágtam be a journal logját, mert nekem már csak ott mutatja. És bár notebook ez is, de nekem ez a seed szervereme is, így ritkán van reboot.
-
a service-re persze, hogy azt írja, hogy dead, mert nem önmagától fut, hanem a timer indítja.
én nem is erre utaltam.
ha megnézed, a saját logomat, amit odamásoltam, nekem is azt írja, hogy dead, alatta viszont ott van a journalctl vonatkozó logja, amiben látszik, hogy 6-án hajnal fél2-kor lefutott.
ha kiadod asystemctl status fstrim.serviceparancsot, neked is látszódni fog ugyanaz, amit a journalctl-ban is látsz.
growlernek viszont nem volt ilyen alatta. -
Nálam sem látszik valamiért (most direkt sudo-val futtattam a status-t is):
[gavarga@gavarga-5500 ~]$ sudo systemctl status fstrim.service○ fstrim.service - Discard unused blocks on filesystems from /etc/fstabLoaded: loaded (/usr/lib/systemd/system/fstrim.service; static)Active: inactive (dead)TriggeredBy: ● fstrim.timerDocs: man:fstrim(8)[gavarga@gavarga-5500 ~]$ sudo journalctl -u fstrim.servicejún 06 18:54:47 gavarga-5500 systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...jún 06 18:55:15 gavarga-5500 fstrim[5240]: /boot: 173,4 MiB (181867520 bytes) trimmed on /dev/nvme0n1p1jún 06 18:55:15 gavarga-5500 fstrim[5240]: /srv: 41 GiB (43985354752 bytes) trimmed on /dev/mapper/vgwdc-srvjún 06 18:55:15 gavarga-5500 fstrim[5240]: /mnt: 19,1 GiB (20490309632 bytes) trimmed on /dev/mapper/vgwdc-mntjún 06 18:55:15 gavarga-5500 fstrim[5240]: /home: 12,7 GiB (13597962240 bytes) trimmed on /dev/mapper/vgwdc-homejún 06 18:55:15 gavarga-5500 fstrim[5240]: /: 14,1 GiB (15192903680 bytes) trimmed on /dev/mapper/vgwdc-rootjún 06 18:55:15 gavarga-5500 systemd[1]: fstrim.service: Deactivated successfully.jún 06 18:55:15 gavarga-5500 systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.jún 06 18:55:15 gavarga-5500 systemd[1]: fstrim.service: Consumed 1.504s CPU time. -
a service-re persze, hogy azt írja, hogy dead, mert nem önmagától fut, hanem a timer indítja.
én nem is erre utaltam.
ha megnézed, a saját logomat, amit odamásoltam, nekem is azt írja, hogy dead, alatta viszont ott van a journalctl vonatkozó logja, amiben látszik, hogy 6-án hajnal fél2-kor lefutott.
ha kiadod asystemctl status fstrim.serviceparancsot, neked is látszódni fog ugyanaz, amit a journalctl-ban is látsz.
growlernek viszont nem volt ilyen alatta. -
Ez így ebben a formában nem igaz. Nekem is ugyanazt mutatja az fstrim.service-ra mintha halott szolgáltatás lenne, ennek ellenére mégis lefutott már párszor.
journalctl | grep fstrim
May 30 00:10:43 archlinux fstrim[51704]: /home/Data: 199.7 GiB (214405660672 bytes) trimmed on /dev/sda3
May 30 00:10:43 archlinux fstrim[51704]: /boot: 453.8 MiB (475791360 bytes) trimmed on /dev/sda1
May 30 00:10:43 archlinux fstrim[51704]: /: 16.6 GiB (17787359232 bytes) trimmed on /dev/sda2
May 30 00:10:43 archlinux systemd[1]: fstrim.service: Deactivated successfully.
Jun 06 01:20:15 archlinux fstrim[75988]: /home/Data: 196.4 GiB (210929713152 bytes) trimmed on /dev/sda3
Jun 06 01:20:15 archlinux fstrim[75988]: /boot: 453.6 MiB (475660288 bytes) trimmed on /dev/sda1
Jun 06 01:20:15 archlinux fstrim[75988]: /: 17.3 GiB (18574147584 bytes) trimmed on /dev/sda2 -
ez azt jelenti, hogy nálad ez egyszer se futott le, mert különben írná a legutóbbi futás eredményét, ami úgy néz ki, hogy
lenry@zetetic-elench:~$ systemctl status fstrim.service
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/lib/systemd/system/fstrim.service; static)
Active: inactive (dead) since Mon 2022-06-06 01:33:16 CEST; 2 days ago
TriggeredBy: ● fstrim.timer
Docs: man:fstrim(8)
Process: 3023761 ExecStart=/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported (code=exited, status=0/SUCCESS)
Main PID: 3023761 (code=exited, status=0/SUCCESS)
CPU: 831ms
Jun 06 01:33:02 zetetic-elench systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jun 06 01:33:16 zetetic-elench fstrim[3023761]: /: 25.1 GiB (26995699712 bytes) trimmed on /dev/md0
Jun 06 01:33:16 zetetic-elench systemd[1]: fstrim.service: Succeeded.
Jun 06 01:33:16 zetetic-elench systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab. -
m@mo ~]$ sudo hdparm -I /dev/sda | grep TRIM
[sudo] m jelszava:
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
[m@mo ~]$Furcsa, mert a
systemctl status fstrim.service
parancs, továbbra is csak ezt mutja:○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
Active: inactive (dead)
TriggeredBy: ● fstrim.timer
Docs: man:fstrim(8)
[m@mo ~]$ -
m@mo ~]$ sudo hdparm -I /dev/sda | grep TRIM
[sudo] m jelszava:
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read ZEROs after TRIM
[m@mo ~]$Furcsa, mert a
systemctl status fstrim.service
parancs, továbbra is csak ezt mutja:○ fstrim.service - Discard unused blocks on filesystems from /etc/fstab
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static)
Active: inactive (dead)
TriggeredBy: ● fstrim.timer
Docs: man:fstrim(8)
[m@mo ~]$ -
m@mo ~]$ sudo systemctl status fstrim.timer
[sudo] m jelszava:
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2022-06-08 14:54:54 CEST; 2min 1s ago
Until: Wed 2022-06-08 14:54:54 CEST; 2min 1s ago
Trigger: Wed 2022-06-08 15:52:11 CEST; 55min left
Triggers: ● fstrim.service
Docs: man:fstrim
jún 08 14:54:54 mo systemd[1]: Started Discard unused blocks once a week.
[m@mo ~]$ sudo fstrim /dev/sda3 -v
fstrim: /dev/sda3: not a directory
[m@mo ~]$ sudo fstrim -v /
fstrim: /: the discard operation is not supported
[m@mo ~]$
Külső UASP + trim támogatású USB3-as házban lévő SATA3 SSD Manjaroval telepítve.Jaj de b@lf@sz vagyok, block device-t nem is lehet trimmelni
Na mindegy, látom megtaláltad hogy csatolási pont alapján kellene.
Ezt futtasd le:
# hdparm -I /dev/sda | grep TRIM(előtte csekkold hogy ez-e az a meghajtó)
-
-
-
trim támogatású USB3-as házban
azért én megpróbálnám rendesen, SATA-ra kötve is ugyanezt a műveletet, mert a hibaüzenet alapján mégsem annyira trim támogatású az a ház
nálam ugyanez lefuttatva:
lenry@so-much-for-subtlety:~$ sudo fstrim -v /
/: 117.1 GiB (125736411136 bytes) trimmed
(igen, nemrég töröltem egy tonnányi szemetet) -
m@mo ~]$ sudo systemctl status fstrim.timer
[sudo] m jelszava:
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Wed 2022-06-08 14:54:54 CEST; 2min 1s ago
Until: Wed 2022-06-08 14:54:54 CEST; 2min 1s ago
Trigger: Wed 2022-06-08 15:52:11 CEST; 55min left
Triggers: ● fstrim.service
Docs: man:fstrim
jún 08 14:54:54 mo systemd[1]: Started Discard unused blocks once a week.
[m@mo ~]$ sudo fstrim /dev/sda3 -v
fstrim: /dev/sda3: not a directory
[m@mo ~]$ sudo fstrim -v /
fstrim: /: the discard operation is not supported
[m@mo ~]$
Külső UASP + trim támogatású USB3-as házban lévő SATA3 SSD Manjaroval telepítve. -
Én Arch-on az Ext4-es partíciókra kilövöm az fstab-ban a discard kapcsolókat és belövöm az ütemezett trimmelést. Ezt tenném NVME meghajtókkal is.
Csak abba gondoljunk bele, ha azonnali/online trimmelés van és esetleg egy nem jól irányzott törlés után realtime lefut. Akkor nincs lehetőség visszaállításra. Mondjuk ettől a kuka használat megvéd, de mi van ha nem használod? Ütemezett trimmelésnél meg van egy heted, mert ez a default beállított periódusa a heti terimmelésnek. -
#63718632
törölt tag
Igen, hát mondjuk ez a trimmelés téma Arch Linuxon nem is annyira triviális. Mivel a filozófia meg hagyja a user-nek a döntés szabaságát, hogy mit használ. Meg milyen szolgáltatásokat állít be a rendszerén.
Erre volt ma egy jó példám.
Cimbimnek anno egy kis fos AMD C-70-es notikára tettem egy Arch rendszert, mert azzal viszonylag jól megy. Ennek két éve már. Tegnap csörög, hogy nyomtatni szeretne. Mondom semmi gond, Xfce>Nyomtató beállítások és minden fasza lesz, meg szkenneléshez Skanlite vagy Szkennelés progi.
Majd negyed óra mulva csaptam a fejemhez, hogy állj ne csinálj semmit. Mert szinte biztos, hogy nyomtató csoporthoz kell adni a user-t. Be kell lőni a CUPS service-t és egyéb nyalánkságok.
Másik öreg notiján egy Deb alapú Neptune van. Na azon nyomhatod nyugodtan, amit a GUI ad nyomtatókra és szkennerekre. Azzal elboldogulsz, biztos.
A lényeg, hogy a cimbi abszolute nem érdekelt, a dolgok hátterének megértésében. Csak működjön.
Na ezzel csak azt szertettem volna sugalni, minden disztrón kicsit más minden is.
-
Koszonom mindenkinek!
Tehat ha majd NVME M.2 SSD-re telepitek olyan rendszert, amelyiken
alapertelmezetten nincs engedelyezve az idozitett trim - akkor
engedelyezem.Ui. Hogy ezt igy tisztaztuk, gondolom nem csak nekem hasznos !
számomra mindenképp hasznos volt, mostmár tudom, hogy bizonyos dolgokat rosszul tudtam
-
Ezek szerint en felreertem a helyzetet.
Ha engedelyezem akar az azonnali, akar az idozitett trimet,
az csak a SATA (ATA)-s csatolofeluletu SSD-re "van hatassal"
Az NVME M.2 SSD-k csatolofeluleten ez nem is "megy at"
Az NVME M.2 csatolofeluletu SSD-knek sajat / beepitett megoldasa
van a trimre. - Vagy nem ?Lényegtelen! A végeredmény ugyan az, ha ütemezett, ha realtime/online. Ha SATA, ha NVME.
Értsd úgy, hogy robbanó motoros autón a gázpedált nyomod a gyorsításhoz. Elektromos autón meg az előrehaladást pedált.
Csak a név más, a jobb lábaddal rátaposol a pedálra és megyen.
Lényegében mindkettő a karosszéria szekrény gyorsulását okozza.
Kvázi a fajin kis SSD-d, csatoló felülettől függetlenül le lesz trimmerelve így vagy úgy. Attól függ melyiket választod. -
nem.
olvasd el még egyszer BoB hozzászólását:
"az fstrim parancs az eszköznek megfelelő parancsot fogja küldeni amivel trimmelni fog a meghajtó. Ez a felhasználó számára transzparens."
azaz: te kiadod az fstrim parancsot, az op.rendszer meg az SSD vezérlője meg majd lematekozzák, hogy ténylegesen mit is kell csinálni, neked ezzel már nem kell foglalkoznod.igen, külön fajta megoldása van a SATA-nak meg az NVME-nek a trimmelésre, de mindkét esetben ugyanazt az fstrimet kell elindítani, ugyanúgy
Koszonom mindenkinek!
Tehat ha majd NVME M.2 SSD-re telepitek olyan rendszert, amelyiken
alapertelmezetten nincs engedelyezve az idozitett trim - akkor
engedelyezem.Ui. Hogy ezt igy tisztaztuk, gondolom nem csak nekem hasznos !
-
Archttila
veterán
-
Ezek szerint en felreertem a helyzetet.
Ha engedelyezem akar az azonnali, akar az idozitett trimet,
az csak a SATA (ATA)-s csatolofeluletu SSD-re "van hatassal"
Az NVME M.2 SSD-k csatolofeluleten ez nem is "megy at"
Az NVME M.2 csatolofeluletu SSD-knek sajat / beepitett megoldasa
van a trimre. - Vagy nem ? -
-
-
NVME-t ugyanúgy kell trimmelni, annak nyilván nem a TRIM SATA parancs megy ki, hanem az nvme deallocate, ami ugyanazt csinálja.
Te is meggyőződhetsz róla NVME esetén, csinálj egy fstrim-et, hozz létre egy 1GB-os fájlt, töröld le, majd újra fstrim. Látni fogod hogy pont 1GB lett trimmelve.
Az NVME és SATA SSD belső működése ugyanaz, csak az interfész más.
Lényeg, hogy az fstrim parancs az eszköznek megfelelő parancsot fogja küldeni amivel trimmelni fog a meghajtó. Ez a felhasználó számára transzparens.
De ezt a Wiki is írja: [link]
-
Kozben ratalaltam Ubyegon2 blogjara ahol az NVME SSD-rol ertekezik.
[link]
Ha jol ertelmezem, NVME M.2 SSD-re telepitett rendszeren, akar le is
lehet tiltani (inaktivalni) az esetleges alapertelmezetten aktiv TRIM-et
Mivel a TRIM SATA-s parancs - ugy sincs hatassal a nem SATA
csatolofeluletu NVME M.2 SSD-re.
Az NVME M.2 SSD:
"Az eszköz saját Dataset Management parancskészlete, pontosabban annak deallocate utasítása folyamatosan hajtja végre a TRIM-nek megfelelő műveletet adatmozgatás közben, quasi online TRIM-melést végez."
Szoval, kulso beallitas nelkul "hazon belul" elintez mindent. (?) -
Kozben ratalaltam Ubyegon2 blogjara ahol az NVME SSD-rol ertekezik.
[link]
Ha jol ertelmezem, NVME M.2 SSD-re telepitett rendszeren, akar le is
lehet tiltani (inaktivalni) az esetleges alapertelmezetten aktiv TRIM-et
Mivel a TRIM SATA-s parancs - ugy sincs hatassal a nem SATA
csatolofeluletu NVME M.2 SSD-re.
Az NVME M.2 SSD:
"Az eszköz saját Dataset Management parancskészlete, pontosabban annak deallocate utasítása folyamatosan hajtja végre a TRIM-nek megfelelő műveletet adatmozgatás közben, quasi online TRIM-melést végez."
Szoval, kulso beallitas nelkul "hazon belul" elintez mindent. (?) -
Nálam kicsit bonyolult a helyzet, mert LVM-et használok LUKS-on, nehogy túl egyszerű legyen. Én a periodikus trim mellett döntöttem.
Más: frissült a mirrorlist – s habár mostanság nem volt probléma a sebességgel –, úgy döntöttem generálni kellene egy új listát. Találtam egy reflector névre hallgató csomagot, parancssorból lehet készíteni egy listát különféle szempontok figyelembevételével, szóval egész hasznos. Ráadásul a kidolgozott utasítás ott figyel az előzményekben most már, csak vissza kell rá ugranom, ha új mirrorlist kellene.
-
Anno körbejártam az SSD/Trimmelés/Linux témát, amikor megvettem az első SSD-met (SATA). Én azt szűrtem ki, hogy vagy
discardazfstab-ba, vagysystemd service. Ez disztrónként változik, ki melyiket preferálja. Az tény, hogy Arch-on tényleg rád van bízva, hogy melyiket választod.
Aztán van olyan is, hogy atrimmparancs az SATA szabvány. Az NVME/PCIE szabványhoz meg adiscard(online/realtime trimmelés) áll közelebb.
Ezt a témát lenne jó körbe járni, mert már nekem is vannak M.2 SATA/NVME SSD-im is.
Szóval jó témát vetettél fel. -
Anno körbejártam az SSD/Trimmelés/Linux témát, amikor megvettem az első SSD-met (SATA). Én azt szűrtem ki, hogy vagy
discardazfstab-ba, vagysystemd service. Ez disztrónként változik, ki melyiket preferálja. Az tény, hogy Arch-on tényleg rád van bízva, hogy melyiket választod.
Aztán van olyan is, hogy atrimmparancs az SATA szabvány. Az NVME/PCIE szabványhoz meg adiscard(online/realtime trimmelés) áll közelebb.
Ezt a témát lenne jó körbe járni, mert már nekem is vannak M.2 SATA/NVME SSD-im is.
Szóval jó témát vetettél fel.Nálam kicsit bonyolult a helyzet, mert LVM-et használok LUKS-on, nehogy túl egyszerű legyen. Én a periodikus trim mellett döntöttem.
Más: frissült a mirrorlist – s habár mostanság nem volt probléma a sebességgel –, úgy döntöttem generálni kellene egy új listát. Találtam egy reflector névre hallgató csomagot, parancssorból lehet készíteni egy listát különféle szempontok figyelembevételével, szóval egész hasznos. Ráadásul a kidolgozott utasítás ott figyel az előzményekben most már, csak vissza kell rá ugranom, ha új mirrorlist kellene.
-
Nemreg telepitettem az Arch alapu ArcoLinuxot SATA-s SSD-re
Engedelyeztem az fstrim.timert, - ellenoriztem - fut !
Viszont a mas rendszeren megszokott kezi Trim (sudo fstrim -av)nem fut le.
Annyit sikerult kideritenem, hogyha az fstab-ba beirnam a discard
parametert, akkor elkepzelheto hogy a kezi TRIM is lefutna.
Kerdesem: Nem lehetne valahogy megis futtatni kezi TRIM-et ugy
hogy csak az idozitett trim van engedelyezve ? -
Mivel Arch linuxról beszélünk, ezért kell külön foglalkozni vele.
Nincs trim folyamatosan automatikusan, csak ha magadnak beállítottad (másképpen kifejezve a discard nem kerül be az fstab-ba csak úgy magától).
Sem a periodic trim nincs beállítva.
Azaz neked kell választanod hogy melyiket használod, vagy nem használod egyiket sem (bár nem látom ez miért lenne jó).
SATA vs NVME között valóban nincs különbség a felhasználó szempontjából ilyen téren.
A véletlen törlések ellen meg nem az a megoldás hogy az ember kikapcsolja a trim-et (ez elég kókány géza lenne
) -
szia
egyrészt nem kell külön foglalkozni vele, a fájlrendszer folyamatosan csinálja (continous trim), emiatt nem feltétlenül ajánlott még külön a periodic trimet bekapcsolni (amit az általad írt parancs csinál) - de a lényeg, hogy csak az egyik legyen bekapcsolva.
másrészt ebből a szempontból a SATA és az NVME közt nincs különbség, egész pontosan nem itt van a különbség. a trim a flash cellák karbantartása miatt fontos. az, hogy aztán az SSD milyen kapcsolaton keresztül csatlakozik a gép többi részéhez (SATA v NVME) ebből a szempontból irreleváns.
lsblk --discardparanccsal tudod ellenőrizni, hogy működik-e most is a trim. az SSD-k esetében a DISC-GRAN oszlopban nem nulla értéket kell hogy visszakapj.tldr: a mai rendszerek automatikusan kezelik az SSD-k sajátosságait, semmi külön teendő nincs már velük.
ezekkel a 10 évvel ezelőtti machinációkkal nem kell ma már foglalkozni (és a szerény véleményem az, hogy már akkor is túl volt misztifikálva a dolog)Mivel Arch linuxról beszélünk, ezért kell külön foglalkozni vele.
Nincs trim folyamatosan automatikusan, csak ha magadnak beállítottad (másképpen kifejezve a discard nem kerül be az fstab-ba csak úgy magától).
Sem a periodic trim nincs beállítva.
Azaz neked kell választanod hogy melyiket használod, vagy nem használod egyiket sem (bár nem látom ez miért lenne jó).
SATA vs NVME között valóban nincs különbség a felhasználó szempontjából ilyen téren.
A véletlen törlések ellen meg nem az a megoldás hogy az ember kikapcsolja a trim-et (ez elég kókány géza lenne
) -
-
szia
egyrészt nem kell külön foglalkozni vele, a fájlrendszer folyamatosan csinálja (continous trim), emiatt nem feltétlenül ajánlott még külön a periodic trimet bekapcsolni (amit az általad írt parancs csinál) - de a lényeg, hogy csak az egyik legyen bekapcsolva.
másrészt ebből a szempontból a SATA és az NVME közt nincs különbség, egész pontosan nem itt van a különbség. a trim a flash cellák karbantartása miatt fontos. az, hogy aztán az SSD milyen kapcsolaton keresztül csatlakozik a gép többi részéhez (SATA v NVME) ebből a szempontból irreleváns.
lsblk --discardparanccsal tudod ellenőrizni, hogy működik-e most is a trim. az SSD-k esetében a DISC-GRAN oszlopban nem nulla értéket kell hogy visszakapj.tldr: a mai rendszerek automatikusan kezelik az SSD-k sajátosságait, semmi külön teendő nincs már velük.
ezekkel a 10 évvel ezelőtti machinációkkal nem kell ma már foglalkozni (és a szerény véleményem az, hogy már akkor is túl volt misztifikálva a dolog)Koszonom !
Talan meg annyit: A folyamatos TRIM nem teszi lehetetlenne a
veletlen torlesek visszaallitasat ? -
Sziasztok !
SSD TRIM-el kapcsolatban kernek megerositest, ill. helyesbitest.
Tudomasom szerint:
- SATA SSD: Szuksege van TRIM-re (Arch alapu kiadasokon altalaban
ezt kulon engedelyezni kell. --> sudo systemctl enable fstrim.timer --now
- NVME M.2 SSD: Nem kell foglalkozni a TRIM-el.
Jol tudom ? -
Ismét elakadtam.
Szeretnék a laptopomon az Intel és Nvidia VGA-k között váltani.
Az lenne a terv, hogy alapban az Intel van használatban, de szükség esetén az Nvidia is használható legyen. neofetchFelraktam az "optimus-manager" csomagot, de indítva az alábbi üzenetet kapom:
$ optimus-managerERROR: a GPU setup was initiated but Xorg post-start hook did not run.Log at /var/log/optimus-manager/switch/switch-20220513T212209.logIf your login manager is GDM, make sure to follow those instructions:https://github.com/Askannz/optimus-manager#important--gnome-and-gdm-usersIf your display manager is neither GDM, SDDM nor LightDM, or if you don't use one, read the wiki:https://github.com/Askannz/optimus-manager/wiki/FAQ,-common-issues,-troubleshootingCannot execute command because of previous errors.A log ezt mutatja:
$ nano /var/log/optimus-manager/switch/switch-20220513T212209.log17] INFO: # Xorg pre-start hook[17] INFO: Previous state was: {'type': 'pending_pre_xorg_start', 'requested_mode': 'integrated', 'current_mode': None}[17] INFO: Requested mode is: integrated[1169] INFO: Available modules: ['nouveau', 'nvidia', 'nvidia_drm', 'nvidia_modeset', 'nvidia_uvm'][1169] INFO: Unloading modules ['nvidia_drm', 'nvidia_modeset', 'nvidia_uvm', 'nvidia'] (if loaded)[1173] INFO: switching=none, nothing to do[1197] INFO: Writing to /etc/X11/xorg.conf.d/10-optimus-manager.conf[1197] INFO: Writing state {'type': 'pending_post_xorg_start', 'switch_id': '20220513T212209', 'requested_mode': 'integrated'}[1197] INFO: Xorg pre-start hook completed successfully.Mi lehet a gond? Hogyan lehetne rendbetenni?
-
Kis segítséget szeretnék kérni.
A macbook air laptopomra felraktam a zen kernelt, de nem tudom beállítani, hogy azt használja.
Ez alapján próbálom, de nálam nincs a /boot alatt "loader" könyvtár. Ott csak EFI és grub könyvtárak vannak és a kernel fájlok.A gépben lévő wifi-t próbálom életre kelteni, de a "broadcom-wl-dkms" csomag felrakása után sem tudom használni, nem látszik a gnome beállításokban. Az lspci listázza.
-
Kis segítséget szeretnék kérni.
A macbook air laptopomra felraktam a zen kernelt, de nem tudom beállítani, hogy azt használja.
Ez alapján próbálom, de nálam nincs a /boot alatt "loader" könyvtár. Ott csak EFI és grub könyvtárak vannak és a kernel fájlok.A gépben lévő wifi-t próbálom életre kelteni, de a "broadcom-wl-dkms" csomag felrakása után sem tudom használni, nem látszik a gnome beállításokban. Az lspci listázza.
-
Volna egy nyomtatós problémám.
A cups telepítve van, de amikor hozzáadnám a nyomtatót (gnome) akkor a Xerox Phaser 3140 nyomtatóra azt mondja, hogy kellene külön driver.
Eddig ezzel a két csomaggal próbálkoztam: [link] [link]
Természetesen cups restart volt mindegyik után, de úgyanúgy azt mondja, hogy kell valami külön driver.
Itt van egy régi driver, de nincs az Arch feltünteve.
Hogyan tudnék telepíteni valami drivert? -
Nem próbáltam, de tényleg eszembe juthatott volna. Tényleg logikus root-ként is akkor megadni.
Archttila:
Szuper, köszi. Beírtam az EDITOR=nano kulcs-érték párost és a sudo a nano-t használja alapértelmezetként.
Kivettem a ~/.bashrc-ből is az export EDITOR=nano sort. Így már az sem kell. -
Annyiban pontosítanék, hogy .desktop fájl a ~6.config/autostart path-on elindul, de kb. 1mp-ig látható, mivel a gnome ezután tölti be a saját cuccait gondolom.
Szóval sleep-et rakva a script-be ugyan működik a dolog, de ez azért elég tákolós megoldás. Egyelőre itt tartok.Más:
A bashrc-ben tettem egy export EDITOR=nano sort, ami jól működik, ha a user indít mondjuk egy MC-t. Viszont sudo esetén már nem használja ezt a bash paramétert és a sudo mc esetén most nincs editor F4 billentyűre. Az mc internal edit ki van kapcsolva, de nincs beállítva a nano defaultnak.
Hogyan tudnám sudo esetén is a nano-t használni default editornak? -
Annyiban pontosítanék, hogy .desktop fájl a ~6.config/autostart path-on elindul, de kb. 1mp-ig látható, mivel a gnome ezután tölti be a saját cuccait gondolom.
Szóval sleep-et rakva a script-be ugyan működik a dolog, de ez azért elég tákolós megoldás. Egyelőre itt tartok.Más:
A bashrc-ben tettem egy export EDITOR=nano sort, ami jól működik, ha a user indít mondjuk egy MC-t. Viszont sudo esetén már nem használja ezt a bash paramétert és a sudo mc esetén most nincs editor F4 billentyűre. Az mc internal edit ki van kapcsolva, de nincs beállítva a nano defaultnak.
Hogyan tudnám sudo esetén is a nano-t használni default editornak? -
Ezt tudom, de sajnos nem működik.
Csináltam már desktop fájlt, pl. az imwheel-t így indítom, de valamiért az xrandr-t nem szereti.
Próbáltam direktben indítani, azaz a desktop fájlba írni a paramétereket a paramétereket is, de próbáltam a script-et is, amit jelenleg kézzel indítok folyton. Egyik megoldással sem tetszik neki.
Igazság szerint jó volna valami DE-től független megoldással indítani, mert ha feldobok esetleg egy i3-at vagy bármi mást, akkor ne kelljen ezzel külön foglalkozni.
És persze user független is jó volna.
Nincs valami systemd paraméter arra, hogy várjon a DE betöltésre és csak azután fusson le egy xrandr paraméterezve? -
Gnome? Jáááj
Szal Gnome esetén 2 lehetőséged biztos van. Az egyik, hogy régen volt (meg gondolom most is van) egy gnome tweaks csomag (közben megnéztem van: gnome-tweaks). Ezzel grafikus felületen lehet szabályozni az autostart funkciót. Aztán a Gnome kezeli az XDG féle autostartot is alapból mindennemű plusz program nélkül, úgyhogy azt is csinálhatod, hogy a /etc/xdg/autostart mappá alá létrehozhatod a saját filenév.desktop fájlodat. Egyébként ez ugyanúgy működik, mint Debian alatt. Ha csak egy bizonyos userre akarod ezt, akkor meg /home/user/.config/autostart mappa alá kell tenni).
A desktop fileok felépítéséről pedig itt találsz infót: https://wiki.archlinux.org/title/desktop_entries#File_example
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)Új hozzászólás Aktív témák
- Új MSI 16 Vector WQXGA 240Hz i9-13950HX 24mag 32GB 1TB SSD Nvidia RTX 4080 12GB 175W Win11 Garancia
- BESZÁMÍTÁS! AMD Ryzen Threadripper 7960X + ASUS Pro WS TRX50-SAGE +128GB 6400MHz DDR5 garanciával
- Apple Watch Ultra 2 49mm Titanium Case Sapphire Glass Karcmentes 91% akkumulátor 2027.04.09-ig garan
- Bomba ár! Lenovo X1 Carbon 3rd I i5-5G I 8GB I 180SSD I 14" QHD Touch I Cam I W10 I Garancia!
- Jonsbo RGB 24pin / Lian Li Strimer Plus V2 12VHPWR 320mm RGB tápkábelek
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest