Acties:
  • 0 Henk 'm!

  • Tim
  • Registratie: Mei 2000
  • Laatst online: 18-03 14:00

Tim

Bij mij verschijnt discard ook niet in de mount-opties, maar het werkt wel gewoon. Nu heb ik de discard als default opgegeven met tune2fs ipv via fstab (dat is te controleren met tune2fs -l /dev/xxx).
Heb je verder nog mount opties? Zo kwam ik er ook achter dat data=writeback niet werkt met trim.

Hier is een manier om zeker te zijn of trim werkt: http://andyduffell.com/techblog/?p=852

edit: Overigens is discard op niet-ssd schijven waarschijnlijk geen goed idee.

[ Voor 9% gewijzigd door Tim op 02-02-2012 11:46 ]


Acties:
  • 0 Henk 'm!

  • BlueMotion
  • Registratie: Januari 2010
  • Laatst online: 18-05 23:22
Oke, die test werkt bij mij :)

$ mount -l
geeft nog steeds niets weer. Ik ben even aan het zoeken geweest in de output van
$ dmesg
Daarin staat de discard option wel:

mounted filesystem(...) Opts: discard

Ik heb overigens default,noatime als verdere mount opties bij de ssd. En de default voor data=ordered.

Waarom zou discard voor niet SSD's niet zo'n goed idee zijn? Ik meende ergens gelezen te hebben dat dat ook prima kon, maar dat kan ik zo even niet weervinden..

Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
BlueMotion schreef op donderdag 02 februari 2012 @ 14:36:
Waarom zou discard voor niet SSD's niet zo'n goed idee zijn? Ik meende ergens gelezen te hebben dat dat ook prima kon, maar dat kan ik zo even niet weervinden..
Op harde schijven lijkt het me iig niet zinvol (geen performancewinst), tenzij je datarecovery wilt frustreren.

Komt bij dat omdat niemand het gebruikt er misschien bugs in de firmware van je harde schijf zitten waardoor data corrupt raakt. :)

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Waarom TRIM't ie nu niet?

Ik heb net een SSD in mijn Lenovo Thinkpad Edge gebouwd.
code:
1
2
# hdparm -i /dev/sda | grep -i model
 Model=M4-CT256M4SSD2, FwRev=0009


Ik draai Ubuntu 11.10, kernel 3.0.0:
code:
1
2
$ uname -a
Linux Redsandro 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


En zonder iets te veranderen staat het sterretje van enabled op enabled:
code:
1
2
3
4
# hdparm -I /dev/sda | grep -i trim
    (Enabled    Supported:)
       *    Data Set Management TRIM supported (limit 8 blocks)
       *    Deterministic read data after TRIM


Maar als ik ga testen:

code:
1
2
3
4
5
6
7
8
9
10
11
12
$ dd if=/dev/urandom of=temp bs=1M count=3
$ hdparm --fibmap temp
temp:
 filesystem blocksize 4096, begins at LBA nnnnnn; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           m  xxxxxx  yyyyyy        zzz
$ rm temp && sync && sleep 400 && hdparm --read-sector xxxxxx /dev/sda


/dev/sda:
reading sector xxxxxx: succeeded
[allemaal random data]
krijg ik allemaal random data, niet getrimt dus.

Vervolgens voeg ik de optie discard aan fstab toe, ookal is dat volgens mij niet nodig, maar na een reboot staat er nog steeds [allemaal random data], niet getrimt dus.

code:
1
2
3
$ cat /etc/fstab | grep discard
UUID=[removed] /           ext4    discard,noatime,errors=remount-ro     0       1
UUID=[removed] /home       ext4    defaults,discard,noatime              0       2

code:
1
2
3
4
5
$ hdparm --read-sector xxxxxx /dev/sda

/dev/sda:
reading sector xxxxxx: succeeded
[allemaal random data]


Uiteindelijk wiper.sh van hdparm voor TRIMloze huilie-SSD's gebruikt:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ wiper.sh --commit /dev/sda5

wiper.sh: Linux SATA SSD TRIM utility, version 3.3, by Mark Lord.
Preparing for online TRIM of free space on /dev/sda5 (ext4 mounted read-write at /).

This operation could silently destroy your data.  Are you sure (y/N)? y
Creating temporary file (22072791 KB).. 
Syncing disks.. 
Beginning TRIM operations..

[blah blah]

succeeded
Removing temporary file..
Syncing disks.. 
Done.


En dan is de boel wel getrimt:

code:
1
2
3
4
5
$ hdparm --read-sector xxxxxx /dev/sda

/dev/sda:
reading sector xxxxxx: succeeded
0000 0000 0000 0000 0000 0000 0000 0000

🇪🇺 Buy from EU (GoT)


Acties:
  • 0 Henk 'm!

  • Jormungandr
  • Registratie: Oktober 2006
  • Laatst online: 16-05 14:16
Zijn er nog mensen waar een hardnekkige SSD en koppige fdisk voor verhoogde bloeddruk zorgt?

Ik ben bezig met het installeren van Arch op mijn Intel 320 120GB SSD en de alignment wil maar niet op -H 32 -S 32 blijven staan.

Ik doe netjes de fdisk -S 32 -H 32 /dev/sda en maak mijn partities aan. Als ik na het aanmaken een 'p' doe, zie ik nog steeds 32h/32s staan. Doe ik een write en daarna een fdisk -l /dev/sda en fdisk -lu /dev/sda, dan staat het weer standaard op 255h, 63s.

Zowel met de Arch installer als de fedora liveCD krijg ik hetzelfde fenomeen.

Acties:
  • 0 Henk 'm!

  • Borromini
  • Registratie: Januari 2003
  • Niet online

Borromini

Mislukt misantroop

De arch installer heeft gdisk, dat werkt een stuk makkelijker met SSD's.

https://wiki.archlinux.org/index.php/Solid_State_Drives

Got Leenucks? | Debian Bookworm x86_64 / ARM | OpenWrt: Empower your router | Blogje


Acties:
  • 0 Henk 'm!

  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 12:36
Ik zou niet weten waarom je met fdisk en C/H/S instellingen zou kloten als je gewoon met parted een partitie op 1MB kunt starten en vervolgens partitiegroottes in megabytes aangeeft. Als je alignment niet klopt begint parted er zelf ook wel over tegenwoordig.

Acties:
  • 0 Henk 'm!

  • Rprp
  • Registratie: December 2007
  • Laatst online: 12:31
Interessant: ik heb nooit problemen gehad met TRIM, maar heb nu een Plextor m3p in een server geinstalleerd en deze doet toch "raar".

Op de Intel X25-M worden de sectors vrijwel instant getrimmed (binnen 2-3 seconden). Ik heb dit al met 5+ servers gedaan, nooit problemen gehad.

Vandaag de Plextor M3P uitgeprobeerd en deze "trimmed" pas na 60-90 seconden. Is dit een "feature" v.d. controller (uitstellen?) of wordt dit niet gedaan door het OS maar door garbage collection en moet ik m'n settings nakijken?

  • Sallin
  • Registratie: Mei 2004
  • Niet online
Ik heb recent linux op een SSD geinstalleerd met een ext4 filesystem en dit ging vrij automatisch. Het enige wat ik heb ingesteld is de discard en noatime optie in /etc/fstab. Op basis van de huidige TS maakte ik me wat zorgen of het niet ingewikkeld zou zijn, maar dat was voor mij niet zo. Verder was de performance volgens mij ook goed voor een 128GB:

hdparm -tT --direct /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   926 MB in  2.00 seconds = 462.67 MB/sec
 Timing O_DIRECT disk reads: 1462 MB in  3.00 seconds = 487.10 MB/sec


hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   28688 MB in  2.00 seconds = 14362.14 MB/sec
 Timing buffered disk reads: 1492 MB in  3.00 seconds = 497.17 MB/sec

This too shall pass
Debian | VirtualBox (W7), Flickr


Acties:
  • 0 Henk 'm!

  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Volgens Linux Ext4 ontwikkelaar Theodore Ts'o is het tegenwoordig beter om geen "discard" mee te geven aan ext4, maar gewoon bijvoorbeeld één keer per week fstrim uit te voeren (bijvoorbeeld als cronjob):
Again, using direct TRIM support from the file system is generally going to be a performance problem for all current SSD's, since the TRIM command is a non-queuable command, so it requires a NCQ queue flush --- and many SSD's have a highly inefficient and slow TRIM command. As a consequence, you don't want to issue a trim on every single journal commit. A much better thing to do is to use fstrim once a day or once a week (which for many SSD's and workloads is plenty).
Bron: https://plus.google.com/1...9033135/posts/BW2PX7eXmqx

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Is dat niet gewoon in het systeem geregeld?
Ik heb helemaal niets ingesteld, en bij mij wordt verwijderde data ook gewoon weggeTRIMd.

Het zou ook van de zotte zijn als je anno 2012 je SSD handmatig moet TRIMmen.

Altans, bij een modern FS als EXT4. Als je geen EXT4 hebt ingesteld dan moet je inderdaad handmatig moeilijk doen.

🇪🇺 Buy from EU (GoT)


Acties:
  • 0 Henk 'm!

Anoniem: 185331

Elijan9 schreef op maandag 24 september 2012 @ 11:49:
Volgens Linux Ext4 ontwikkelaar Theodore Ts'o is het tegenwoordig beter om geen "discard" mee te geven aan ext4, maar gewoon bijvoorbeeld één keer per week fstrim uit te voeren (bijvoorbeeld als cronjob):
[...]
Bron: https://plus.google.com/1...9033135/posts/BW2PX7eXmqx
Moet ik dan hém geloven of moet ik de tutorials geloven die over heel het internet is verspreid...

Acties:
  • 0 Henk 'm!

  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Sando schreef op maandag 24 september 2012 @ 15:35:
Is dat niet gewoon in het systeem geregeld?
Ik heb helemaal niets ingesteld, en bij mij wordt verwijderde data ook gewoon weggeTRIMd.
Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".

Handmatig TRIM-en is sowieso eigenlijk alleen mogelijk bij moderne filesystemen, een filesysteem moet namelijk met de fysieke laag (de SSD) communiceren welke sectors niet actief gebruikt worden om TRIM (en `fstrim`) te laten werken.
Anoniem: 185331 schreef op maandag 24 september 2012 @ 17:14:
Moet ik dan hém geloven of moet ik de tutorials geloven die over heel het internet is verspreid...
Theodore Ts'o lijkt mij dan toch echt de meest betrouwbaardere bron. Iedereen kan een tutorial schrijven, maar niet iedereen is dè Linux hoofdontwikkelaar van de ext2, ext3 en ext4 filesystemen en heeft zoveel te maken gehad met TRIM support in Linux...

[ Voor 23% gewijzigd door Elijan9 op 24-09-2012 17:48 . Reden: reactie bitking ]

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

Anoniem: 185331

Elijan9 schreef op maandag 24 september 2012 @ 17:15:
[...]

Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".

Handmatig TRIM-en is sowieso eigenlijk alleen mogelijk bij moderne filesystemen, een filesysteem moet namelijk met de fysieke laag (de SSD) communiceren welke sectors niet actief gebruikt worden om TRIM (en `fstrim`) te laten werken.
Zo onhandig, handmatig is niet meer van deze tijd 8)7 Mijn discard blijft staan hoor! NÉM! :)

Acties:
  • 0 Henk 'm!

  • Sallin
  • Registratie: Mei 2004
  • Niet online
Ik snap niet helemaal of zijn commentaar nu altijd toepasbaar is of voor de specifieke context van de thread, namelijk dingen compileren.

This too shall pass
Debian | VirtualBox (W7), Flickr


Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
Anoniem: 185331 schreef op maandag 24 september 2012 @ 17:26:
[...]

Zo onhandig, handmatig is niet meer van deze tijd 8)7 Mijn discard blijft staan hoor! NÉM! :)
Je zou ook kunnen trimmen bij het afsluiten (of opstarten) van de computer in een script, dan hoef je ook niks handmatig te doen.

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Elijan9 schreef op maandag 24 september 2012 @ 17:15:
[...]

Als je mount met de optie "discard" dan wordt het "in het systeem geregeld". Echter, dat gaat dus ten koste van performance volgens de hoofdontwikkelaar van ext4 en volgens hem is het dus eigenlijk beter dit eens in de zoveel tijd handmatig te doen met fstrim... Het is dus geen kwestie van "handmatig moeten doen" maar van "handmatig willen doen".
Je uitleg is helder maar het klopt volgens mij niet. Ik heb geen extra mountopties. Geen discard. (Geen noatime, hoewel dat misschien wel een idee is om mijn SSD 1% i/o te ontzien.) En toch wordt het netjes geTRIMt.

Ik zal even voor je opzoeken hoe je dat ookalweer kunt testen..

(to be editted)
edit:
  • dd if=/dev/urandom of=random.tmp bs=1M count=4 && sync
  • sudo hdparm --fibmap random.tmp
    • blabla ff herhalen totdat je ziet begin_LBA = xxxxxxxx
  • sudo hdparm --read-sector xxxxxxxx [url]/dev/sda[/url]
    • 310f 036d 8d5c 504f <- willekeurige data hier
  • rm random.tmp && sync
  • Paar minuten wachten en opnieuw:
  • sleep 150 && sudo hdparm --read-sector xxxxxxxx [url]/dev/sda[/url]
    • 0000 0000 0000 0000 <- als alles 0 is, dan werkt trim goed.
WUT? Op mijn laptop werkt het wel, maar op mijn HTPC werkt het niet? What kind of sourcery is this??
edit:

Oh wacht, mijn HTPC is nogal getweaked, maar ik kan mijn eigen tweaks niet terugvinden. :(

[ Voor 43% gewijzigd door Sando op 24-09-2012 22:25 ]

🇪🇺 Buy from EU (GoT)


Acties:
  • 0 Henk 'm!

  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Sallin schreef op maandag 24 september 2012 @ 18:32:
Ik snap niet helemaal of zijn commentaar nu altijd toepasbaar is of voor de specifieke context van de thread, namelijk dingen compileren.
Het beïnvloedt met name de schrijf-performance en enigszins de lees-performance op het moment dat er tegelijkertijd wordt geschreven. Bij compileren speelt zoiets, maar ook bij rippen, videobewerking, P2P, (applicaties) opstarten. Extra performance op die (paar?) momenten dat je het nodig hebt.
Sando schreef op maandag 24 september 2012 @ 20:53:
Je uitleg is helder maar het klopt volgens mij niet. Ik heb geen extra mountopties. Geen discard. (Geen noatime, hoewel dat misschien wel een idee is om mijn SSD 1% i/o te ontzien.) En toch wordt het netjes geTRIMt.
Geen discard expliciet meegeven via fstab wil niet meteen zeggen dat de optie niet aan staat, een subset van de mogelijke mountopties kun je in het filesysteem zelf instellen, met `tune2fs -o discard ...` of ook via `tune2fs -E mount_opts=discard ...` Volgens de mount manpage staat discard in elk geval standaard uit, maar het kan zijn dat Linux distributies deze default veranderd hebben in hun kernels:
This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient testing has been done.

[ Voor 23% gewijzigd door Elijan9 op 25-09-2012 10:39 ]

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Of misschien heb ik het dan toch ooit eens zelf geactiveerd op de laptop. Bedankt voor het attenderen in ieder geval. :P

Heb maar even snel mijn EXT4's van discard optie voorzien
$ sudo tune2fs -o discard /dev/sda1
$ sudo tune2fs -o discard /dev/sda3

Want blijkbaar stond alles constant vol. Gelukkig leeft de SSD nog. (Ik heb ook geen idee hoe zo'n vaart dat loopt zonder TRIM)

Ik weet dat je juist probeert uit te leggen dat we beter niet discard kunnen gebruiken, maar dit is mijn HTPC, performance boeit niet zoveel. Ik kan altijd nog even CRON erbij halen, maar op mijn laptop heb ik me nooit echt ge-ergerd aan TRIMs wanneer het niet uitkomt ofzo.

Ik vind het wel van de ratten dat het niet standaard werkt bij een SSD, zoals op alle andere systemen in de rest van het heelal.

[ Voor 56% gewijzigd door Sando op 25-09-2012 15:34 ]

🇪🇺 Buy from EU (GoT)


  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Sando schreef op dinsdag 25 september 2012 @ 15:26:
...

Want blijkbaar stond alles constant vol. Gelukkig leeft de SSD nog. (Ik heb ook geen idee hoe zo'n vaart dat loopt zonder TRIM)
Een SSD gaat er niet meteen dood van, alleen kan de SSD veel efficiënter nieuwe data wegschrijven als het weet welke blokken ongebruikt zijn.
Mounten met "discard" lost het volgens mij alleen op voor nieuwe schrijfbewerkingen, ik vermoedt dat je alsnog even fstrim moet draaien. Als je fstrim met "-v" draait zie je meteen hoeveel data er getrimmed is...
Ik vind het wel van de ratten dat het niet standaard werkt bij een SSD, zoals op alle andere systemen in de rest van het heelal.
Onder Windows werkt het ook pas vanaf versie 7, en voor Mac OSX vanaf 10.6.8. "Alle andere systemen in de rest van het heelal" valt dus ernstig mee, in elk geval op en rond de aardbol draait zeker de helft een systeem zonder TRIM support. Windows 7 schakelt TRIM trouwens pas (handmatig) in als je de "Prestatie Index" bijwerkt, op een manier die vergelijkbaar is met `tune2fs -odiscard ...`
Eerlijk gezegd vind ik het ook niet helemaal terecht dat discard nog steeds niet standaard aan staat, maar ik heb al meerdere malen meegemaakt dat het opstarten van Linux 2 seconden bijna stil staat op het moment dat een swapfile met "discard" werd gemount (op een inmiddels overleden OCZ Vertex 2), dus het kan behoorlijk vertragen...

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Elijan9 schreef op woensdag 26 september 2012 @ 10:42:
Als je fstrim met "-v" draait zie je meteen hoeveel data er getrimmed is...
_/-\o_
Onder Windows werkt het ook pas vanaf versie 7, en voor Mac OSX vanaf 10.6.8. "Alle andere systemen in de rest van het heelal" valt dus ernstig mee
Ja dat weet ik ook wel, maar Linux is altijd zo snel met nieuwe dingen, dagelijks 10tallen patches enzo.
Windows 7 komt overigens uit 2009, en de reden dat OSX pas TRIM ondersteunt vanaf 2011 is omdat ze daarvoor (2008?) al Apple-SSD's verkochten welke dit op een andere manier deden, iirc, hardwarematig zonder dat het OS daar over ging, wat performancetechnisch onder deed voor TRIMcommando's vanuit het systeem.

Linux loopt wel degelijk 3 jaar achter door bepaalde systeemfunctionaliteit-verantwoordelijkheden bij de gebruiker te laten liggen in plaats van ze door het systeem - daar is het immers voor - te laten regelen.

Dat sommige mensen nog XP draaien, ja daar heb ik dan wat minder een boodschap aan. Oude software en nieuwe technologie gaat logischerwijs niet altijd samen.
al meerdere malen meegemaakt dat het opstarten van Linux 2 seconden bijna stil staat op het moment dat een swapfile met "discard" werd gemount (op een inmiddels overleden OCZ Vertex 2), dus het kan behoorlijk vertragen...
Je moet je swap toch ook gewoon als swap mounten? En alle rommel gewoon (encrypted) laten staan. Swap ondersteunt geen TRIM, alleen EXT4 doet dat.

🇪🇺 Buy from EU (GoT)


  • Ultraman
  • Registratie: Februari 2002
  • Laatst online: 15-05 17:01

Ultraman

Moderator Harde Waren

Boefje

Ik denk dat "swapfile" het essentiële uit zijn verhaal is. Namelijk geen losse swap partitie, maar een file dus, en die kan best op een ext4 filesystem staan.

[ Voor 17% gewijzigd door Ultraman op 26-09-2012 20:20 ]

Als je stil blijft staan, komt de hoek wel naar jou toe.


  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Sando schreef op woensdag 26 september 2012 @ 18:54:
...
Swap ondersteunt geen TRIM, alleen EXT4 doet dat.
code:
1
swapon --discard /dev/....
;)
En nee, volgens mij is het beter data die je niet nodig hebt z.s.m. terug te geven aan de SSD controller via TRIM, ook oude swap data... (TRIM is juist bedoeld om geen rommel te laten staan.)

Volgens de Linux 3.5 sources zit er ook discard ondersteuning in vfat en gfs2(?), naast xfs, nilfs, btrfs, ext2 en ext3. vfat heb ik meteen getest en dat werkt inderdaad... :*)

[ Voor 31% gewijzigd door Elijan9 op 26-09-2012 23:56 ]

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

  • Trax_Digitizer
  • Registratie: Januari 2002
  • Laatst online: 08-03-2024

Trax_Digitizer

are we there yet?

Ik ben van plan om een nieuwe Linux server aan te schaffen (tbv hosting doeleinden en router@home). Mijn huidige server (een oude P4 met SATA1) is dusdanig oud dat het tijd wordt om over te stappen op een nieuw platform. Een upgrade is niet meer aan de orde. In mijn nieuwe server wil ik gebruik gaan maken van SSD('s).

In dit topic heb ik al een aantal goede tips gevonden die ik zeker ga toepassen. Zo ga ik mijn squid cache en /tmp in het RAM zetten en ga ik geen swap partitie meer gebruiken. Met 8 GB RAM moet dit makkelijk lukken. Draai geen X en doe alles in de shell. Het punt waar ik over twijfel is het toepassen van SW RAID 1 met twee SSD's (Crucial m4 128 GB).

In mijn huidige server gebruik ik SW RAID 1 (t.b.v. continuiteit) al jaren icm reguliere harddisks en dat bevalt prima. Via Google kom ik echter uit bij personen die het gebruik van SW RAID 1 i.c.m. SSD's afraden. Dit omdat Linux SW RAID nog niet goed omgaat met het TRIM commando. Dit zou nadelig uitpakken voor de performance en levensduur van de SSD. Ik lees daarentegen ook weer stukken van mensen die het wél met succes hebben toegepast. Op dit moment weet ik dus even niet meer wat "waar" is. Doordat ik de feiten niet goed ken, vind ik het lastig om keuzes te maken.

De reden dat ik überhaupt SSD's wil gebruiken (t.o.v. reguliere harddisks) is in de eerste plaats het geluidsniveau. Ik weet mijn server redelijk stil te krijgen, maar de harddisks maken op dit moment het meeste lawaai. Dat komt ook doordat mijn huidige consumenten harddisks al 6 jaar 24x7 draaien in RAID 1; de lagers slijten waardoor het lawaai toeneemt. Dat is wel een situatie waar ik in de toekomst vanaf wil. Daarnaast is de snelheidswinst van een SSD t.o.v. een HD natuurlijk mooi mee genomen. Met name bij het inladen van grote mailboxen via de webmail verwacht ik hier snelheidswinst. Bij 5000 mails kost dat wel wat laadtijd op dit moment.

De totale hoeveelheid data op mijn huidige server is ongeveer 30 GB. Dat is dus inclusief OS, software en gebruikersdata.

Kortom, wat is verstandig? Ga ik voor 1x SSD of ga ik voor 2x SSD in RAID 1? Iemand ervaring met een soortgelijk vraagstuk?

Acties:
  • 0 Henk 'm!

  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Trax_Digitizer schreef op maandag 17 december 2012 @ 09:27:
[...]
In mijn huidige server gebruik ik SW RAID 1 (t.b.v. continuiteit) al jaren icm reguliere harddisks en dat bevalt prima. Via Google kom ik echter uit bij personen die het gebruik van SW RAID 1 i.c.m. SSD's afraden. Dit omdat Linux SW RAID nog niet goed omgaat met het TRIM commando.
Linux kernel 3.7 is recentelijk uitgebracht en deze ondersteunt nu wel TRIM in combinatie met SW RAID, zie:
http://kernelnewbies.org/...6e69ed24f88e0eb83217fa8df Eerdere kernels ondersteunden TRIM voor zover ik weet helemaal niet i.c.m. software RAID.

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

  • AlterEgo
  • Registratie: Juli 2001
  • Niet online
Is een periodiek fstrim-commando geen redelijk alternatief?

Acties:
  • 0 Henk 'm!

  • Sando
  • Registratie: Januari 2007
  • Niet online

Sando

Sandoichi

Elijan9 schreef op woensdag 26 september 2012 @ 21:33:
[...]

code:
1
swapon --discard /dev/....
;)
Huw? Wist ik niet :P Enig idee hoe dat werkt met cryptoswap in fstab wat Ubuntu en consorten volgens mij standaard gebruiken?

🇪🇺 Buy from EU (GoT)


Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
Trax_Digitizer schreef op maandag 17 december 2012 @ 09:27:
In dit topic heb ik al een aantal goede tips gevonden die ik zeker ga toepassen. Zo ga ik mijn squid cache en /tmp in het RAM zetten en ga ik geen swap partitie meer gebruiken. Met 8 GB RAM moet dit makkelijk lukken. Draai geen X en doe alles in de shell. Het punt waar ik over twijfel is het toepassen van SW RAID 1 met twee SSD's (Crucial m4 128 GB).
Niet doen. Als je een goede SSD hebt (zoals een Crucial M4 of Samsung 830, koop nooit Sandforcetroep) dan is een defect sowieso al behoorlijk onwaarschijnlijk. Mocht er toch iets mis gaan, dan is de kans vrij groot dat beide SSD's tegelijk kapot gaan:

• Slijtage, bijvoorbeeld door een intensieve database te draaien, zal beide SSD's op ongeveer hetzelfde moment laten falen.
Crucial 5000 uur bug, geeft geen dataverlies maar de computer loopt wel steeds vast na een uur. Logischerwijs zullen beide SSD's in RAID1 hier op vrijwel precies hetzelfde moment tegenaan lopen als je firmware niet up-to-date is. ;)

SSD's zijn anders dan harde schijven die door hun mechanische aard op een meer willekeurig moment de fout in konden gaan. RAID1 bij SSD's is imho niet zinvol.

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Elijan9
  • Registratie: Februari 2004
  • Laatst online: 09-05 10:12
Sando schreef op maandag 17 december 2012 @ 15:54:
[...]

Huw? Wist ik niet :P Enig idee hoe dat werkt met cryptoswap in fstab wat Ubuntu en consorten volgens mij standaard gebruiken?
Bij Ubuntu weet men het ook nog niet, Ubuntu gebruikt de eigen tool "mountall" om alles in fstab af te handelen en deze ondersteunt (nog) geen discard optie bij swap (wordt genegeerd), dat zal voor cryptoswap niet anders zijn. Ik heb daar al een patch voor klaar liggen, maar moet nog even de tijd vinden om dit te melden.

Met cryptoswap heb ik geen ervaring, maar ik denk dat bij cryptoswap de swapfile ook opnieuw geïnitialiseerd moet worden en dan zou discard meteen een schone lei opleveren, dus het zou zeker nuttig en logisch zijn om discard ook hier te gebruiken/ondersteunen...

War is when the young and stupid are tricked by the old and bitter into killing each other. - Niko Bellic


Acties:
  • 0 Henk 'm!

  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 12:36
W3ird_N3rd schreef op maandag 17 december 2012 @ 23:23:
[...]

Niet doen. Als je een goede SSD hebt (zoals een Crucial M4 of Samsung 830, koop nooit Sandforcetroep) dan is een defect sowieso al behoorlijk onwaarschijnlijk. Mocht er toch iets mis gaan, dan is de kans vrij groot dat beide SSD's tegelijk kapot gaan:

• Slijtage, bijvoorbeeld door een intensieve database te draaien, zal beide SSD's op ongeveer hetzelfde moment laten falen.
Crucial 5000 uur bug, geeft geen dataverlies maar de computer loopt wel steeds vast na een uur. Logischerwijs zullen beide SSD's in RAID1 hier op vrijwel precies hetzelfde moment tegenaan lopen als je firmware niet up-to-date is. ;)

SSD's zijn anders dan harde schijven die door hun mechanische aard op een meer willekeurig moment de fout in konden gaan. RAID1 bij SSD's is imho niet zinvol.
Bij RAID1 heb je idd het probleem dat 2 identieke SSDs op hetzelfde moment door hun writes heen zijn. Ik heb een 6-tal Crucial M4s in RAID6 hangen in een databaseserver, daarvan zijn er een aantal op 4% levensduur, een aantal op 9% en een aantal zitten al op 13%. Dat is een server met 300GB aan databases die de hele dag staat te schrijven (wel met 512MB WB cache en BBU). Al met al zijn die SSDs over een jaar of 7-8 gewoon op, maar voor die tijd gok ik dat er vraag is naar een grotere server met meer cores, meer geheugen en ook weer nieuwe opslag.

Heb bij die server vooral in het begin last gehad van uitvallende SSDs door firmware bugs. Uiteindelijk de interface geforceerd naar 3Gbit/s, maar sinds 000F kan die gewoon weer naar 6Gbit/s. Latere firmwares heb ik nog niet geflasht, zie de noodzaak niet echt.

Edit:
Naast de willekeur van RAID6 met 256KB stripesize komt het verschil in levensduur ook door het feit dat het array een aantal keren in degraded mode heeft gedraaid omdat een SSD zich door firmwarebugs ineens ging afmelden bij de controller en pas bij de volgende powercycle weer gevonden werd.

[ Voor 7% gewijzigd door _JGC_ op 19-12-2012 12:14 ]


Acties:
  • 0 Henk 'm!

  • Trax_Digitizer
  • Registratie: Januari 2002
  • Laatst online: 08-03-2024

Trax_Digitizer

are we there yet?

Bedankt voor de reacties. De nieuwe server met 2x crucial m4 128GB draait inmiddels, maar nog zonder raid 1. Sterker nog, 1 SSD is momenteel helemaal niet aangesloten. Ik installeer het systeem eerst volledig op 1 SSD en besluit dan later nog of ik de 2e SSD voor raid 1 wil gebruiken. Ik kan hem ook 'bewaren' voor als mijn huidige SSD versleten is. Weet nog niet wat verstandig is. Als de kans groot is dat ze beiden tegelijk falen, dan heeft raid 1 niet zoveel nut. Maar als ik de andere SSD bijvoorbeeld na een jaar pas aansluit, dan is de kans dat ze tegelijk falen alweer een stuk kleiner.

Ik vraag me overigens af of mijn SSD nu goed 'gealigned' is. Zie hieronder de output van 'fdisk -lu'
code:
1
2
3
4
5
6
7
8
9
Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007eb5f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   250068991   125033472   83  Linux


Hier las ik dat je dan de startsector * 512 / 4096 moet doen. En als daar dan een rond getal uitkomt, dan zou de SSD goed gealigned zijn. In mijn geval is dat een geheel getal, maar ik begrijp niet goed waarom dit dan klopt. Is dit niet afhankelijk van de "clustergrootte"? En moet dit voor mijn SSD niet 4096 bytes zijn ipv de 'oude' 512 bytes?

Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
Trax_Digitizer schreef op zaterdag 22 december 2012 @ 16:33:
Bedankt voor de reacties. De nieuwe server met 2x crucial m4 128GB draait inmiddels, maar nog zonder raid 1. Sterker nog, 1 SSD is momenteel helemaal niet aangesloten. Ik installeer het systeem eerst volledig op 1 SSD en besluit dan later nog of ik de 2e SSD voor raid 1 wil gebruiken.
Ik zei het al, maar RAID1 is niet bijster zinnig in deze setup. Als je iets wil doen, zorg dan gewoon voor dagelijkse backups, of zelfs backups ieder uur afhankelijk van wat erop staat.

RAID1 is geen backup.
Ik kan hem ook 'bewaren' voor als mijn huidige SSD versleten is. Weet nog niet wat verstandig is.
Dat is niet verstandig, want afhankelijk van wat je ermee doet kan het zomaar 10 jaar duren eer hij versleten is. Tegen die tijd koop je een veel betere SSD voor dat geld. ;)

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Trax_Digitizer
  • Registratie: Januari 2002
  • Laatst online: 08-03-2024

Trax_Digitizer

are we there yet?

RAID 1 gebruik ik alleen tegen het falen van een schijf waardoor ik niet meteen een systemrestore hoef te doen. Backups maak ik elke week met rsync naar mijn NAS. Wellicht dat ik de SSD dan toch voor mijn 13" laptopje kan gebruiken. Daar zit nu zo'n trage 4200 toerenschijf in en die heb ik al eens willen vervangen. ;)

Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
Lijkt me idd een beter idee. :)

Een flexibeler idee om aan te denken zou zijn om het gehele systeem bijvoorbeeld wekelijks te backuppen. In het onwaarschijnlijke geval dat de SSD zou falen steek je die 4200rpm schijf uit je laptop erin ;) en zet je daar de laatste backup van het systeem op terug.

Persoonlijk zou ik gewoon de boel de boel laten: de moeite om een systeem backup te maken (of de kosten van een RAID1) wegen niet op tegen de kans op een minor inconvenience van het opnieuw instellen van je systeem in het geval de SSD zou falen.

[ Voor 29% gewijzigd door Mentalist op 22-12-2012 18:55 ]

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Trax_Digitizer
  • Registratie: Januari 2002
  • Laatst online: 08-03-2024

Trax_Digitizer

are we there yet?

Omdat ik /var/log/ ook in het RAM (tmpfs) heb gezet, zoek ik een manier om de inhoud te behouden bij een reboot. De basale gedachte is dat ik de inhoud van /var/log/ mbv tar naar mijn SSD wegschrijf bij een shutdown, de inhoud weer terugzet bij het booten.

Ik heb me zitten verdiepen in bootscripts en ben met een bestaand script in /etc/init.d/ en de informatie op een aantal websites (1, 2) aan de slag gegaan. Zie hieronder het resultaat van mijn "log_maintainer" bootscript.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#!/bin/sh

### BEGIN INIT INFO
# Provides:          log_maintainer
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 1 6
# Short-Description: restore logfiles in tmpfs
### END INIT INFO

# on shutdown, before unmout tmpfs: /bin/tar zpcvf /root/var_log.tar.gz /var/log/* > /dev/null
# on boot, after mount tmpfs: /bin/tar zpxvf /root/var_log.tar.gz -C / > /dev/null

PATH=/sbin:/usr/sbin:/bin:/usr/bin

do_start() {
        echo -n "Restoring logfiles (/var/log/) from disk to RAM (tmpfs)..."
        /bin/tar zpxvf /root/var_log.tar.gz -C / > /dev/null
        echo "done."
}

do_stop() {
        echo -n "Writing logfiles (/var/log/) from RAM (tmpfs) to disk..."
        /bin/tar zpcvf /root/var_log.tar.gz /var/log/* > /dev/nul
        echo "done."
}

case "$1" in
    start)
        do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        do_stop
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac


Vervolgens heb ik via sysv-rc-conf de juiste symlink in /etc/rcS.d/ aangemaakt. Ik heb hier heel bewust voor runlevel "S" gekozen, omdat ik dit /var/log/ gevuld wil hebben voordat de applicaties worden gestart die hier gebruik van maken (rsyslog, apache2, squid3, postfix, courier, etc...), maar pas nadat alles in /etc/fstab (zie hieronder) is gemount.

code:
1
tmpfs   /var/log        tmpfs   defaults,noatime,mode=0755      0       0


Ik heb het getest met een reboot, maar er gebeurt helemaal niks. En ja het script is executable (-rwxr-xr-x root root).

Toen heb ik het nog geprobeerd in runlevel 2. Los van het feit dat mijn script dan te laat zou worden uitgevoerd (dat zie ik aan de volgorde in /etc/rc2.d/) gebeurt er ook helemaal niks.

Ik maak ongetwijfeld ergens een denkfout, of mijn script klopt niet, maar ik loop vast op dit punt. Iemand nog tips/ideeën?

Acties:
  • 0 Henk 'm!

  • mace
  • Registratie: Juni 2003
  • Laatst online: 18-05 22:25

mace

Sapere Aude

_JGC_ schreef op woensdag 19 december 2012 @ 12:10:

Heb bij die server vooral in het begin last gehad van uitvallende SSDs door firmware bugs. Uiteindelijk de interface geforceerd naar 3Gbit/s, maar sinds 000F kan die gewoon weer naar 6Gbit/s. Latere firmwares heb ik nog niet geflasht, zie de noodzaak niet echt.
000F is nog steeds de beste firmware want in 010G is weer een andere bug geïntroduceerd die er bij 040H nog niet uitgehaald is.

Acties:
  • 0 Henk 'm!

  • Mentalist
  • Registratie: Oktober 2001
  • Laatst online: 11:34
Wat voor bug?

Verstuurd vanaf mijn Computer®


Acties:
  • 0 Henk 'm!

  • Trax_Digitizer
  • Registratie: Januari 2002
  • Laatst online: 08-03-2024

Trax_Digitizer

are we there yet?

Het script om de inhoud van /var/log/ op tmpfs te behouden bij een reboot heb ik inmiddels werkend. Ik heb insserv gebruikt om het script aan bepaalde runlevels toe te voegen. Dat werkte meteen. Dit in tegenstelling tot sysv-rc-conf.

Daarnaast ik twee aparte scripts gemaakt, vanwege verschillende boot/shutdown dependencies die ik niet verenigd kreeg in een enkel script. Kijk hier voor mijn recente blogpost met daarin de definitieve scripts.

Daarnaast loop ik nog steeds met de onderstaande vragen rond.
Trax_Digitizer schreef op zaterdag 22 december 2012 @ 16:33:
...
Ik vraag me overigens af of mijn SSD nu goed 'gealigned' is. Zie hieronder de output van 'fdisk -lu'
code:
1
2
3
4
5
6
7
8
9
Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007eb5f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   250068991   125033472   83  Linux


Hier las ik dat je dan de startsector * 512 / 4096 moet doen. En als daar dan een rond getal uitkomt, dan zou de SSD goed gealigned zijn. In mijn geval is dat een geheel getal, maar ik begrijp niet goed waarom dit dan klopt. Is dit niet afhankelijk van de "clustergrootte"? En moet dit voor mijn SSD niet 4096 bytes zijn ipv de 'oude' 512 bytes?
Met name de 512B of 4K "clustergrootte". Anyone?

Acties:
  • 0 Henk 'm!

  • mace
  • Registratie: Juni 2003
  • Laatst online: 18-05 22:25

mace

Sapere Aude

In die firmwares zit een bug waardoor de drive in sommige gevallen niet door de bios wordt herkend.

http://forum.crucial.com/...OS-after-BSOD/td-p/110660

Acties:
  • 0 Henk 'm!

Anoniem: 474628

Ik heb net een nieuwe PC in elkaar gezet en Ubuntu 12.04.2 erop geinstalleerd. Op zich ging dat allemaal vlekkeloos, totdat ik de veel vertelde tip om de "noatime" parameter toe te voegen aan de root partitie in fstab ging uitvoeren. Zodra ik dit gedaan had, boot mijn systeem niet meer grafisch op en kan ik alleen inloggen op de consoles tty[0-6]. (Her)Kent iemand dit probleem?

Als ik dan in de console de noatime parameter weer weghaal en reboot is er weer niets aan de hand. Ik heb al aardig wat gegoogled, maar kan echt niets vinden.

De fstab regel die wel boot:
UUID=9d02a572-f593-4e0d-9980-7ded33ed2f1b / ext4 errors=remount-ro 0 1
en dit maakt mijn systeem stuk:
UUID=9d02a572-f593-4e0d-9980-7ded33ed2f1b / ext4 errors=remount-ro,noatime 0 1
Bedankt!

Acties:
  • 0 Henk 'm!

  • Room42
  • Registratie: September 2001
  • Niet online
Ik geloof dat je de noatime voor de errors=remount-ro moet zetten.

[ Voor 63% gewijzigd door Room42 op 05-03-2013 00:32 ]

"Technological advancements don't feel fun anymore because of the motivations behind so many of them." Bron


Acties:
  • 0 Henk 'm!

Anoniem: 474628

Bedankt voor je reactie, maar ik was het vergeten er bij te zetten: dat heb ik ook wel geprobeerd. Is niet echt een verschil, alleen blijft hij dan ook af-en-toe hangen op een zwart scherm met een blinkende underscore.

Acties:
  • 0 Henk 'm!

  • Ozzie
  • Registratie: Februari 2004
  • Laatst online: 09:27
Ik zou het proberen met defaults,noatime,errors=remount-ro als opties, maar weet niet of het gaat werken en kan het momenteel ook niet uitproberen.

"Write code as if the next maintainer is a vicious psychopath who knows where you live."


Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 18-05 22:16

Hero of Time

Moderator LNX

There is only one Legend

Vreemd dat Ubuntu niet standaard de juiste opties toepast in fstab voor op SSDs. Mijn Debian Sid heeft dat wel gedaan. Alleen op m'n macbook niet omdat 't in BIOS mode draait waardoor TRIM e.d. niet werkt. Even hoger of pagina terug heb ik mijn opties al eens gepost en andere hebben dat ook gedaan. Door alleen noatime te gebruiken zal je niet veel extra krijgen uit je SSD, discard bijvoorbeeld zou TRIM moeten inschakelen.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

  • Ertepeller
  • Registratie: November 2010
  • Laatst online: 12:56
noatime expliciet opgeven heeft geen zin meer...

Tegenwoordig is relatime de default: access time wordt alleen bijgewerkt als de vorige access time ouder is dan de laatste modification time. Sommige applicaties kunnen er niet tegen als atime ouder is dan mtime (bv. mutt).

Dus als je een bestand wijzigt, wordt alleen de 1e keer dat hij daarna wordt gelezen de access time geupdate. Alle reads daarna niet.

In de praktijk zul je geen verschil in performance kunnen merken tussen mounten met en zonder noatime.

Acties:
  • 0 Henk 'm!

Anoniem: 474628

Nou ja, wellicht gooi ik het er dan maar uit ja. Ik zag hier en daar al staan dat voor ext4 noatime het ook niet echt nodig meer is. Maar toch raden vele mensen het nog steeds aan.
@Ozzie: ik heb nog allerlei verschillende volgordes geprobeerd, maar no joy. Het rare is wel dat ik dus gewoon in de tty1 console kan inloggen en dan is vervolgens de SSD wel gewoon gemount met noatime optie volgens "> mount". Ik krijg alleen met geen mogelijkheid een grafische omgeving gestart.

Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 18-05 22:16

Hero of Time

Moderator LNX

There is only one Legend

Dan moet je kijken naar je Xorg.0.log. Die geeft aan wat er dan mis is. Ik heb met een oudere kernel gehad dat de nVidia driver niet meer werkte omdat ik IOMMU aan had, was een bug in de kernel die ondertussen is opgelost.
Het is dus mogelijk dat noatime iets doet wat je video driver niet fijn vind. Ik zie nu dat ik bij elke ext4 mount noatime heb staan. Voor / staat er dit:
code:
1
noatime,discard,errors=remount-ro

Andere partities op m'n SSD hebben 'defaults' ipv 'errors=remount-ro'. Standaard zo gedaan door de Debian installer.

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

Anoniem: 474628

Ok, thanks voor de tip. Ik zal er morgen even op gaan letten. De keren dat het fout ging kon ik in dmesg in ieder geval nooit iets vinden. Het rare (maar ook wel enge) is dat hij vanochtend tijdens het testen is gaan booten met noatime... En nu al een aantal keer herstart en nog steeds doet hij het...

Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 18-05 22:16

Hero of Time

Moderator LNX

There is only one Legend

Niet toevallig updates gehad gisteren?

Commandline FTW | Tweakt met mate


Acties:
  • 0 Henk 'm!

Anoniem: 474628

Nee, geen updates gehad, niet dat ik weet. En vanochtend deed hij het weer een keertje. Nu meteen de Xorg.0.log gekopieerd en na een reboot (zonder iets te veranderen) ging het weer goed.

Een relevantie sectie uit de log:
[     1.596] (EE) intel(0): [drm] failed to set drm interface version.
[     1.597] (EE) intel(0): Failed to become DRM master.
[     1.597] (II) intel(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
[     1.597] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[     1.597] (==) intel(0): RGB weight 888
[     1.597] (==) intel(0): Default visual is TrueColor
[     1.597] (II) intel(0): Integrated Graphics Chipset: Intel(R) Ivybridge Desktop (GT2)
[     1.597] (--) intel(0): Chipset: "Ivybridge Desktop (GT2)"
[     1.597] (II) UnloadModule: "intel"
[     1.597] (II) Unloading intel
[     1.597] (EE) Screen(s) found, but none have a usable configuration.
[     1.597] 
Fatal server error:
[     1.597] no screens found


En hier lijkt het voor het eerst fout te gaan vergeleken met een "goede" Xorg.0.log:
[     1.316] drmOpenDevice: node name is /dev/dri/card0
[     1.471] drmOpenDevice: open result is 9, (OK)
[     1.471] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[     1.471] drmOpenDevice: node name is /dev/dri/card0
[     1.471] drmOpenDevice: open result is 9, (OK)
[     1.471] drmOpenByBusid: drmOpenMinor returns 9
[     1.471] drmOpenByBusid: Interface 1.4 failed, trying 1.1  <-- deze regel is nieuw in de foute log
[     1.471] drmOpenByBusid: drmGetBusid reports <--- de goede log report hier weer "pci:0000:00:02.0" en gaat dan gewoon door met het scherm herkennen etc


Maar goed, nu weet ik niet meer zeker of noatime de boosdoener is. Het leek tijdens het testen wel echt super consistent: met noatime geen boot, zonder noatime wel booten. Iemand een tip hoe ik vanuit deze logs kan verder zoeken/testen?

Het lijkt op https://bugs.launchpad.ne...g-video-intel/+bug/927684 of https://bugs.launchpad.ne...g-video-intel/+bug/899725, dus ik heb plymouth gedisabled, maar ja, het probleem deed zich niet altijd meer voor dus of het echt werkt weet ik pas over een week ofzo, haha.

Acties:
  • 0 Henk 'm!

  • Hero of Time
  • Registratie: Oktober 2004
  • Laatst online: 18-05 22:16

Hero of Time

Moderator LNX

There is only one Legend

Doe even nieuw topic openen hiervoor. Dit gaat niet meer over SSDs tenslotte ;).

Commandline FTW | Tweakt met mate

Pagina: 1 2 3 Laatste