SSD-systeemilevy?

11 views
Skip to first unread message

Jukka Lahtinen

unread,
Jun 5, 2020, 3:16:25 AM6/5/20
to
Toukokuussa tarinoin IO-erroriin jämähtäneestä system-upgradesta
10-vuotiaassa koneessa.
Nyt olisi tarkoitus tilata uusi kone mieluummin tänään tai viimeistään
maanantaina.
Mitä raati on mieltä sellaisesta ajatuksesta että ottaisi systeemilevksi
SSD:n ja laittaisi /home -partition perinteiselle pyörivälle levylle?

SSD ilmeisesti on nopeampi ja sillä softat latautuisivat nopeammin.
Toimiiko käytännössä, kestääkö, mitä erityistä pitäisi ottaa huomioon?
Miten kannattaisi esim. SSD:n TRIM:iä käyttää?

--
Jukka Lahtinen

Arto Järvinen

unread,
Jun 5, 2020, 4:00:17 AM6/5/20
to
En muusta tiedä, mutta Samsung 850 EVO SSD 250 Gt on reilut 5 vuotta nyt
ollut käytössä ja vielä toimii :)

Onhan se nopeampi ja hiljaisempi kuin "perinteinen", vanha satalevy on
mulla pelkästään varmuuskopiointia varten...


TRIMmiä joskus kattelin, mutta en siitä oikein tajunnut mitään.. Jostain
netistä kattelin ohjeita ja sen mukaan koitin säätää..


--
Arto Järvinen
ars...@gmail.com

Anssi Saari

unread,
Jun 5, 2020, 9:46:22 AM6/5/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

> Toukokuussa tarinoin IO-erroriin jämähtäneestä system-upgradesta
> 10-vuotiaassa koneessa.
> Nyt olisi tarkoitus tilata uusi kone mieluummin tänään tai viimeistään
> maanantaina.
> Mitä raati on mieltä sellaisesta ajatuksesta että ottaisi systeemilevksi
> SSD:n ja laittaisi /home -partition perinteiselle pyörivälle levylle?

Riippuu varmaan mitä siellä homessa on? Mulla on pyörivät datalevyt
erikseen isompia tiedostoja varten. Mutta esim. webbiselaimet ja
mailiohjelmat cachettavat kyllä kovasti kalaa kotihakemistoon eli
turhaan hidastat konettasi tuolla idealla.

Monet tuntuivat ajattelivan SSD:n tullessa että ne ovat jäätelöä joka
sulaa heti koneessa ja parempi pitää pakkasessa tai muuten varoa
käyttämästä normaalisti. Mutta normaalia käyttötavaraa ne vaan ovat.

> SSD ilmeisesti on nopeampi ja sillä softat latautuisivat nopeammin.
> Toimiiko käytännössä, kestääkö, mitä erityistä pitäisi ottaa huomioon?

Aika vähän pitää ottaa huomioon. Esim. relatime on nykyään oletus
ext4:ssä mutta jos on vanhoja tiedostojärjestelmiä tai Linux-asennuksia
niin kannattaa katsoa mitä optioita käyttää.

> Miten kannattaisi esim. SSD:n TRIM:iä käyttää?

Vähän riippuu, kuranteissa asemissa ei liene enää kauheasti bugeja mutta
mulla sattuu olemaan 800-sarjan Samsungeja joissa ongelmia on ja niinpä
käytäntönä on ajaa fstrim ajastimella ja muutenkin aina joskus kun
koneet ei ole aina päällä. Toki modernit Linuxit tuntevat ongelma-asemat
eivätkä lähetä dataa rikkovia komentoja bugisille asemille.

Ari Saastamoinen

unread,
Jun 5, 2020, 12:08:04 PM6/5/20
to
Anssi Saari <a...@sci.fi> writes:

> Joku muu wrote:
> > Miten kannattaisi esim. SSD:n TRIM:iä käyttää?

Jos TRIMmiä ei käytä, niin levy ei pysty kierrättämään eraseblokkeja,
ja levy kuluu nopeammin (Tosin nykyiset härpäkkeet kestävät jo sen
verran monta erasointikertaa, että mahtaako tuolla olla ihan oikeasti
ongelma)

> Vähän riippuu, kuranteissa asemissa ei liene enää kauheasti bugeja mutta
> mulla sattuu olemaan 800-sarjan Samsungeja joissa ongelmia on ja niinpä
> käytäntönä on ajaa fstrim ajastimella ja muutenkin aina joskus kun
> koneet ei ole aina päällä. Toki modernit Linuxit tuntevat ongelma-asemat
> eivätkä lähetä dataa rikkovia komentoja bugisille asemille.

Mitenkäs toi levyssä oleva bugi muka käyttäytyy eri tavalla jos fstrim
ajetaan erikseen verrattuna siihen, että filesysteemi trimmaa
automaagisesti? Mä näkisin, että noitten erona on lähinnä se, että
automaattitrimmi saattaa hidastaa levykirjoituksia ennustamattomana
ajankohtana, ja tuon manuaalitrimmin saa ajautumaan aina haluttuun
aikaan.

--
Arzka oh3mqu+...@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje

Harri

unread,
Jun 5, 2020, 12:08:04 PM6/5/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> wrote:
> Mitä raati on mieltä sellaisesta ajatuksesta että ottaisi systeemilevksi
> SSD:n ja laittaisi /home -partition perinteiselle pyörivälle levylle?

Laita sekä / että /home SSD:lle, niin nopeuttaa kivasti käyttöä.

> SSD ilmeisesti on nopeampi ja sillä softat latautuisivat nopeammin.
> Toimiiko käytännössä, kestääkö, mitä erityistä pitäisi ottaa huomioon?

SSD on uusi normaali. Kysymyksesi on vähän kuin 10 vuoden takaa. :-)

> Miten kannattaisi esim. SSD:n TRIM:iä käyttää?

Kerran viikossa TRIM. Komento Linuxissa on "/sbin/fstrim -a". Mutta
selvitä ensin, ajaako käyttöjärjestelmäsi sen jo vakiona kerran viikossa.
Esim. Debian Buster tekee tämän automaattisesti, joten manuaalisesti
sitä ei lisäksi kannata ajaa turhaan.

Jos sen sijaan pitää ajaa se manuaalisesti, niin se kannattaa ajastaa
Croniin. Esim. /etc/cron.d/local:iin rivi:
@weekly root /sbin/fstrim -a

--


Harri

Anssi Saari

unread,
Jun 6, 2020, 12:45:49 PM6/6/20
to
Ari Saastamoinen <oh3mq...@hyper.fi> writes:

> Mitenkäs toi levyssä oleva bugi muka käyttäytyy eri tavalla jos fstrim
> ajetaan erikseen verrattuna siihen, että filesysteemi trimmaa
> automaagisesti?

TRIM-komennon voi ajaa "jonoutettuna" tai ilman. Ilman tarkoittaa
tahmautumista koska mitään ei voi tehdä ennen kuin trim on valmis, jonon
kanssa se on yksi komento muiden joukossa eikä pitäisi hidastaa
elämää. Mutta juuri tähän ne bugit kasautuivat, TRIM ja NCQ oli dataa
sotkeva yhdistelmä joissain levyissä.

Mun läppärissä oleva Samsung 850 löytyy tuolta kernelin mustalta
listalta kohdasta
/* devices that don't properly handle queued TRIM commands */
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c

> Mä näkisin, että noitten erona on lähinnä se, että automaattitrimmi
> saattaa hidastaa levykirjoituksia ennustamattomana ajankohtana

Tällä ei ole juuri merkitystä enää jos TRIM onnistuu jonoutettuna.

> ja tuon manuaalitrimmin saa ajautumaan aina haluttuun aikaan.

Edellyttäen että kone on aina päällä. En tiedä miten nykyiset systemd:n
ajastimet toimivat mutta en erityisesti haluaisi että fstrim ajetaan
heti bootin jälkeen jos kone on ollut unessa tuona haluttuna
aikana. Vaikka toisaalta, sen ajaminen ei yleensä kestä muutamaa
sekuntia pidempään.

Ari Saastamoinen

unread,
Jun 7, 2020, 12:48:32 PM6/7/20
to
Anssi Saari <a...@sci.fi> writes:

> Ari Saastamoinen <oh3mq...@hyper.fi> writes:
>
> > Mitenkäs toi levyssä oleva bugi muka käyttäytyy eri tavalla jos fstrim
> > ajetaan erikseen verrattuna siihen, että filesysteemi trimmaa
> > automaagisesti?
>
> TRIM-komennon voi ajaa "jonoutettuna" tai ilman. Ilman tarkoittaa
> tahmautumista koska mitään ei voi tehdä ennen kuin trim on valmis, jonon
> kanssa se on yksi komento muiden joukossa eikä pitäisi hidastaa

Kumpikos noista jonottaa tai jättää jonottamatta? Filesysteemin
autotrimmi vai fstrim-komento?

Mutta blokin tyhjennys on huomattavasti hitaampi komento kuin ihan
vain levylle kirjoitus, joten kyllä se jonotettunakin hidastaa, jos
levyio:ta on niin paljon, että se ei kerkiä kirjoitusten välissä
tekemään niitä trimmejään. Niin sitten trimmaamattomien blokkien
loppuessa, sen levyn on pakko alkaa uusiokäyttämään blokkejaan (siis
tyhjentämään niitä kirjoitusten yhteydessä.)

Tähän vastaavaan ongelmaan saattaa törmätä nykyään myös pyörivillä
kiekoilla olevilla levyillä, jotka käyttävät SMR-tekniikkaa
kapasiteetin kasvattamiseksi, ja WD:hän on nyt haastettu oikeuteenkin
siitä, kun eivät mitenkään kerro sitä, että onko levy SMR vai ei, kun
jotkut RAID-toteutukset hajoaa levyjen resyncin aikana, kun levyn
nopeammin kirjoitettavat bufferit tulevat täyteen, ja se on pakotettu
järjestelemään dataansa uudestaan ja minissa RAIDeissa oletuksena
olevan minuutin timeoutit paukkuu ennenkuin levy saa toteutettua
kirjoituksen, mutta käyttäjällä ei ole mitään tietoa siitä, että levy
ei sovellu RAIDiin.

> elämää. Mutta juuri tähän ne bugit kasautuivat, TRIM ja NCQ oli dataa
> sotkeva yhdistelmä joissain levyissä.

Hmm.. eikö oikeampi kysymys tavallaan olisi se, että kannattaako
SSD-levyjen kanssa käyttää yhtään mitään muuta
jononkäsittelyalgoritmia kuin NONE:a (Ja sama juttu
esim. virtuaalikoneiden (guesteissa), ja raidatuissa levyissä (raidin
yläpuolella) yms. , joissa se ylemmän tason kerros ei näe sitä alemman
tason levygeometriaa

Anssi Saari

unread,
Jun 11, 2020, 3:46:34 AM6/11/20
to
Ari Saastamoinen <oh3mq...@hyper.fi> writes:

> Kumpikos noista jonottaa tai jättää jonottamatta? Filesysteemin
> autotrimmi vai fstrim-komento?

Autotrimmi jonottaa.

> Mutta blokin tyhjennys on huomattavasti hitaampi komento kuin ihan
> vain levylle kirjoitus, joten kyllä se jonotettunakin hidastaa, jos
> levyio:ta on niin paljon, että se ei kerkiä kirjoitusten välissä
> tekemään niitä trimmejään. Niin sitten trimmaamattomien blokkien
> loppuessa, sen levyn on pakko alkaa uusiokäyttämään blokkejaan (siis
> tyhjentämään niitä kirjoitusten yhteydessä.)

Näin. Tosin Wikipedia antaa ymmärtää että tyypillinen rajoitus
tyhjennettäville lohkoille on kilo jolla maksimiviive on 20 ms mikä
tuntuu vähintäänkin oudolta. Ikään kuin se tyhjennys ei olisi pakollista
myöskään suorittaa heti koska 1000 blokkia ei millään taida tyhjentyä 20
ms:n aikana.

> Tähän vastaavaan ongelmaan saattaa törmätä nykyään myös pyörivillä
> kiekoilla olevilla levyillä, jotka käyttävät SMR-tekniikkaa
> kapasiteetin kasvattamiseksi, ja WD:hän on nyt haastettu oikeuteenkin
> siitä, kun eivät mitenkään kerro sitä, että onko levy SMR vai ei, kun
> jotkut RAID-toteutukset hajoaa levyjen resyncin aikana, kun levyn
> nopeammin kirjoitettavat bufferit tulevat täyteen, ja se on pakotettu
> järjestelemään dataansa uudestaan ja minissa RAIDeissa oletuksena
> olevan minuutin timeoutit paukkuu ennenkuin levy saa toteutettua
> kirjoituksen, mutta käyttäjällä ei ole mitään tietoa siitä, että levy
> ei sovellu RAIDiin.

Joo, tuskaista on SMR:n kanssa. Sentään Geizhals ilmeisesti listaa mitkä
levyt on SMR ja mitkä eivät mutta törkeää ja typerää kyllä
levyvalmistajilta, ei kai WD ole ainoa vaan kaikki (tai onko se molemmat
nykyään?) valmistajat tekevät samaa. Pitäisi joskus jaksaa saada
aikaiseksi päivittää pientä levypalvelinta mutta asiaa ei edistä se
ettei ole täyttä varmuutta että levyt on asiallisia siihen käyttöön.

Ari Saastamoinen

unread,
Jun 11, 2020, 10:13:41 AM6/11/20
to
Anssi Saari <a...@sci.fi> writes:

> nykyään?) valmistajat tekevät samaa. Pitäisi joskus jaksaa saada
> aikaiseksi päivittää pientä levypalvelinta mutta asiaa ei edistä se
> ettei ole täyttä varmuutta että levyt on asiallisia siihen käyttöön.

hdparm:n tekijät ovat todenneet, että tuota ei saa katsottua edes
mistään firmiksen flageistakaan, mutta jos levy tukee TRIMiä, niin
sitten se on SMR, mutta kaikki SMR:t ei ehkä välttämättä tue TRIMmiä.

Jukka Lahtinen

unread,
Jun 15, 2020, 12:12:15 PM6/15/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

> Yksi asia mitä rupesin miettimään, on merkistökoodaus.
> Olen aina käyttänyt Linuxissa ISO-8859-1:tä, eikä oikein huvita nytkään
> mennä utf:ään.
> Kun otin /etc/locale.conf:ista pois .UTF-8 -lopun ja lisäsin
> .bash_profile:n loppuun komennon unicode_stop, se saikin tämän
> aikaan virtuaalikonsoleilla, mutta kun käynnistän X:n ja avaan
> Konsole-ikkunan ja sanon siellä locale, näkyykin monen lokaalimuuttujan
> lopussa taas .UTF-8 enkä ole vielä löytänyt mistä se tulee.

Tuohon syy löytyi lopulta tänään:
~/.config/plasma-localerc oli sellainen tiedosto josta löytyi .UTF-8
-loppuisia määrityksiä. Muutin ne ja käynnistin X:n uudestaan,
ja nyt localet näyttävät enemmän siltä mitä odotinkin.
Kesti aikansa ennen kuin hoksasin tuota .config -hakemistoa ruveta
tutkimaan.

> Sitten on vielä ongelmana miten saan kakkoskoneeksi jääneen laitteen
> levyjaot näkymään nfs:llä uuteen koneeseen, mutta se taitaa olla oman
> threadin asia..

Enää tuo on varsinaisena ongelmana ja siis toisessa threadissa tarkemmin
kuvailtu, siihen en ole vielä löytänyt ratkaisua.

--
Jukka Lahtinen

Ari Saastamoinen

unread,
Jun 15, 2020, 5:06:30 PM6/15/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

> ja nyt localet näyttävät enemmän siltä mitä odotinkin.
> Kesti aikansa ennen kuin hoksasin tuota .config -hakemistoa ruveta
> tutkimaan.

Itse olen tullut siihen tulokseen, että nykyään niin moni ohjelma
defaulttaa WTF-merkistöön, että pääsen vähemmällä säädöllä kun en
yritä palata isolatiniin

> > Sitten on vielä ongelmana miten saan kakkoskoneeksi jääneen laitteen
> > levyjaot näkymään nfs:llä uuteen koneeseen, mutta se taitaa olla oman
> > threadin asia..
>
> Enää tuo on varsinaisena ongelmana ja siis toisessa threadissa tarkemmin
> kuvailtu, siihen en ole vielä löytänyt ratkaisua.

Eka Mieleen tuleva arvaus vois olla, että se sekoilee sen kanssa, että
toisessa on NFS3 ja toisessa NFS4

Jukka Lahtinen

unread,
Jun 16, 2020, 3:55:13 AM6/16/20
to
Ari Saastamoinen <oh3mq...@hyper.fi> writes:
> Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

>> > Sitten on vielä ongelmana miten saan kakkoskoneeksi jääneen laitteen
>> > levyjaot näkymään nfs:llä uuteen koneeseen, mutta se taitaa olla oman
>> > threadin asia..

> Eka Mieleen tuleva arvaus vois olla, että se sekoilee sen kanssa, että
> toisessa on NFS3 ja toisessa NFS4

Täysin mahdollista.
Kummassakin koneessa on keväällä julkaistu Fedora 32 ja uudet versiot
asiaan liittyvistä softapalikoista, mutta kun nfs-säädöt on kymmenen
vuotta sitten konffattu niin että mountit toimi ristiin vielä vanhemman
koneen kanssa (silloinkin luntaten asioita vanhemmasta koneesta), ja
olen säätöjen kanssa lähinnä koettanut olla rikkomatta sellaista mikä on
toiminut ja ongelmia havaitessa säätänyt vain sen verran että asiat
näyttävät taas toimivan, niin sinne on hyvinkin voinut jäädä jotain mikä
olisi ollut parempi tehdä toisin jo 10 vuotta sitten. Hakukoneillakin
on tullut vastaan lähinnä tosi vanhoja ohjeita joista ei aina tiedä
miten niitä pitäisi nfs4:n ja systemd:n aikana soveltaa..

Kirjoittelin pidemmän sepustuksen 14.6. otsikolla "NFS harmaannuttaa
hiuksia", mutta otetaan tähän nyt vielä jotain pääkohtia:

(ipa on se 10-vuotias kone jonka home-partitiota olen tässä yrittänyt
mountata ja stout uusi kone, johon mounttaus epäonnistuu)

Tässä kohtaa mount-komento miettii pari minuuttia ennen kuin antaa
virheilmoituksen:
$ mount /opt/ipahome
mount.nfs: Connection refused

/var/log/messages:iin tulee tänä aikana tällaista:
Jun 14 12:27:20 stout kernel: NFS4: Couldn't follow remote path

/etc/fstab:issa on mountattava resurssi määritelty näin:
ipa:/dev/sda9 /opt/ipahome nfs noauto,user,hard,noatime 0 0

(Aikaisemmin mount-parametreissa oli myös intr, mutta silloin logiin
tuli myös sitä koskevia varoituksia, ja kun en muistanut sen merkitystä
ja lopulta löysin manuaalisivun jolla noita optioita selitettiin, niin
siellä mainittiin että intr ei nykyään tee mitään ja on mukana vain
yhteensopivuussyistä)

ipa-koneen ip on määritelty /etc/hosts:iin ja siihen saa yhteyden
ssh:lla ja se vastaa pingiin.

Mountpoint-hakemisto on luotu ja säädetty oikeudet auki:
$ ls -ld /opt/ipahome
drwxrwxrwx. 2 root root 4096 11. 6. 20:58 /opt/ipahome

Pari juttua joita hakukoneen perusteella tarkistin:
# rpcinfo -p ipa
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper

# rpcinfo -u ipa mountd
ipa: RPC: Program not registered
# showmount -e ipa
clnt_create: RPC: Program not registered

Kuitenkin ipa-koneesta katsoen näyttää tältä:
# systemctl status rpcbind
* rpcbind.service - RPC Bind
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2020-06-12 18:23:16 EEST; 1 day 20h ago

ipa-koneessa mountattava partitio näkyy /etc/mtab:ista katsoen näin:
/dev/sda9 /home2 ext4 rw,nodiratime,relatime,commit=37 0 0

Ja /etc/exports:issa lukee näin:
/home2/ -no_subtree_check 192.168.1.42(rw,sync,no_wdelay,mp) 192.168.1.59(ro)

Tuossa .42-loppuinen on mounttia yrittävän koneen ip, ja tarkistin että
ping ja ssh toimivat myös toiseen suuntaan. Rupesin miettimään, mahtaako
tuo hakemistonimen perässä oleva kauttaviiva vaikuttaa jotain. Toinen
kone kuitenkin on aikaisemmin saanut hakemiston mountattua.

--
Jukka Lahtinen

Ari Saastamoinen

unread,
Jun 16, 2020, 5:34:52 AM6/16/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

> /var/log/messages:iin tulee tänä aikana tällaista:
> Jun 14 12:27:20 stout kernel: NFS4: Couldn't follow remote path

Kannattaisi varmuuden vuoksi kokeilla tuota myös IP-osoitteella tuon
ipa-nimen sijaan.

Ari Saastamoinen

unread,
Jun 16, 2020, 11:43:41 AM6/16/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:

> Vaihdoin /etc/fstab:iin nimen tilalle ip:n, ei vaikutusta.
> (Ip on kyllä määriteltynä nimelle /etc/hosts:issa, joten en uskonutkaan
> sen vaikuttavan.)

Ei tuollaisista voi nykydistrojen kanssa olla enää varma, kun ne
tuntuvat siirtyvän systemd:n käyttöön, joka pyrkii assimiloimaan
itteensä kaikki ennen hyvin toimineet asiat tarjoten melkein-yhtähyvän
vaihtoehdon. Esim. hostnamejen resolvoinnin se haluaisi kaapata, enkä
olisi lankaan varma, että lukeeko se /etc/hosts:ia ihan oikein ihan
joka tapauksessa :)

> mount.nfs: portmap query retrying: RPC: Program not registered

Näin äkkiä tuo virheilmoitus kuulostaa siltä, että jostain syystä
siellä palvelimen päässä nfsd / mountd (whateverd) ei ole saanut
kerrottua portmapperille olemassaolostaan. Tuosta arvaisin, että joko
pallomuuriasetus tai sitten ne on esim. käynnistetty väärässä
järjestyksessä.

Jukka Lahtinen

unread,
Jun 18, 2020, 4:40:09 AM6/18/20
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:
> Ari Saastamoinen <oh3mq...@hyper.fi> writes:
>> Jukka Lahtinen <jtfj...@hotmail.com.invalid> writes:
>
>>> > Sitten on vielä ongelmana miten saan kakkoskoneeksi jääneen laitteen
>>> > levyjaot näkymään nfs:llä uuteen koneeseen, mutta se taitaa olla oman
>>> > threadin asia..

>> Eka Mieleen tuleva arvaus vois olla, että se sekoilee sen kanssa, että
>> toisessa on NFS3 ja toisessa NFS4

No niin, nyt on tapeltu hiukan lisää.

> Tässä kohtaa mount-komento miettii pari minuuttia ennen kuin antaa
> virheilmoituksen:
> $ mount /opt/ipahome
> mount.nfs: Connection refused

Kun lopulta löysin hakemiston
/etc/systemd/system/multi-user.target.wants jossa on linkit bootissa
käynnistettäviin palveluihin ja näin että symlinkit viittaavat hakemistoon
/lib/systemd/system, ja katsoin mitä /lib/systemd/system:issä näkyvistä
palveluista on ipa-koneessa käynnissä ja mikä ei, hoksasin että
nfs-server ei ollut päällä.
Piti siis tehdä systemctl start nfs-server ja vastaisen varalle
systemctl enable nfs-server , ja sen jälkeen tuo herja muuttui, tilalle
tuli

mount.nfs: mounting ipa:/dev/sda9 failed, reason given by server: No such file or directory

Tosiaan sikäli outoa että joskus olen kuitenkin onnistunut tuon koneen
hakemistoja mounttaamaan edelliseen koneeseen, eli ihan kuin palvelu
olisi joskus ollut päällä mutta syystä tai toisesta pudonnut pois.

> /etc/fstab:issa on mountattava resurssi määritelty näin:
> ipa:/dev/sda9 /opt/ipahome nfs noauto,user,hard,noatime 0 0

Tarkempi vertailu siihen mitä toisessa koneessa lukee fstab:issa nfs:llä
mountattavia resursseja varten.
Eihän nfs:llä mountata saman koneen laitteita vaan toisen koneen
hakemistoja eli tuohon tietty piti vielä korjata alkuun /dev/sda9:n
tilalle jakavan koneen HAKEMISTO joka mountataan!
Tällaista siinä syntyy kun fstabiin rivejä lisätessä katse harhailee
ympäriinsä eri riveille.
Eli tuon kuuluu olla
ipa:/home2 /opt/ipahome nfs noauto,user,hard,noatime 0 0

Tämän kun vielä korjasin niin sen jälkeen mounttaus onnistui, joten tämä
ongelma vaikuttaisi tältä erää loppuun käsitellyltä.

--
Jukka Lahtinen

Milky

unread,
Aug 27, 2020, 11:57:51 AM8/27/20
to
On 5.6.2020 11.00, Arto Järvinen wrote:

> En muusta tiedä, mutta Samsung 850 EVO SSD 250 Gt on reilut 5 vuotta nyt
> ollut käytössä ja vielä toimii :)
>
> Onhan se nopeampi ja hiljaisempi kuin "perinteinen", vanha satalevy on
> mulla pelkästään varmuuskopiointia varten...
>
>
> TRIMmiä joskus kattelin, mutta en siitä oikein tajunnut mitään.. Jostain
> netistä kattelin ohjeita ja sen mukaan koitin säätää...


Itellä kanssa Samsung 850 EVO tosin 500 Gt. Läppärissä ainoa levypaik-
ka joten ei ole perinteistä levyä toisena. Alkuperäinen kovo SATA-III
320 Gt levy. Ollut viime Helmikuussa 4 V:tta. Kirjoitettu yli 18 Tt:a.
EndevourOS pääkäyttiksenä. Olen laittanut sekä / että /home partition
SSD:lle. Tubutin 10 Pro myöskin löytyy pieneltä WIN partitiolta. Hal-
lusin pitää myöskin Windowsin vaikka pyrin tekemään kaiken Linux:lla
ja vältän Win 10:n käyttöä. Levyyn ollut erittäin tyytyväinen ja kes-
tää varmaan vielä pitkään tälläkin käytöllä...



--Milky--

Milky

unread,
Aug 27, 2020, 12:10:58 PM8/27/20
to
Piti vielä mainita että Linux partitiot ovat molemmat tiedostojär-
jestelmät XFS:llä...


Milky

unread,
Aug 27, 2020, 12:33:46 PM8/27/20
to
Korjattakoon vielä :( Kirjotetaan EndeavourOS ja on Cinnamon
työpöydällä. Ja toinen vielä siis yli 28 Tt eikä 18 Tt niinkuin
kirjoitin. Toivottavasti nyt tuli oiken ? :)


--Milky--

Reply all
Reply to author
Forward
0 new messages