[7020S] PLI flubber, hoe var naar usb

[Gast]

ik zie dit nergens staan? wel vind ik 'use swap file' terug, maar ook dit blijkt niet te werken.

moet ik eerst een format doen?

ik vind terug dat dit via 'pli setup' kan, maar wie kan de weg wijzen?

groeten,

[paardengek]

Wimpie,

 

Steek de usb stick erin en reboot vervolgens de dreambox. Hierna is de optie move var to usb wel zichtbaar.

 

Met vriendelijke groet, paardengek

[Gast]

move var is (gelukkig) niet nodig voor de 7020, die heeft geen aparte 'var' partitie. En er zijn voldoende manieren om dingen te installeren buiten de interne flash, door bijv. symlinks, of door ipkg install paden aan te passen.

 

Daarom vind je de 'move var' opties ook niet terug in je 7020 image.

[Ome Merde]

had de 7020 niet 32Mb bruikbaar geheugen (verdubbeling t.o.v de 7000) ?

 

 

merDe

[Gast]

Citaat:

had de 7020 niet 32Mb bruikbaar geheugen (verdubbeling t.o.v de 7000) ?

Ja, maar daar is 'maar' 28MB van beschikbaar in het rootfs.
En omdat dit een openembedded distro rootfs is, is die een stukje logger (of completer) dan het rootfs van een oudere box.
Volgens mij heb je bij een schone image ca 8MB vrije ruimte in je root partitie, en dat is dan echte, ongecomprimeerde ruimte, met jffs2 krijg je er dus veel meer dan 8MB aan data in, voordat hij vol is.

Maar als je hem echt vol krijgt, zijn er volop mogelijkheden om dit te voorkomen. Moven van var is echt niet meer nodig.

[Gast]

De reden van de vraag is eigenlijk omdat ik in var/keys om de 15 minuten een een file editeer. (automatisch uiteraard;) )

als het interne flashgeheugen constant beschreven wordt, dan lijkt me dat niet echt gezond. De usb-stick is vervangbaar, het interne flashgeheugen iets moeilijker.

of zie ik dit fout?

[Gast]

Citaat:

De reden van de vraag is eigenlijk omdat ik in var/keys om de 15 minuten een een file editeer. (automatisch uiteraard;) )
als het interne flashgeheugen constant beschreven wordt, dan lijkt me dat niet echt gezond. De usb-stick is vervangbaar, het interne flashgeheugen iets moeilijker.
of zie ik dit fout?

Dat zie je fout. jffs2 is een journaling filesystem, wat sequentieel door de flash heen schrijft (wear-leveling).
Je schrijft dus niet telkens op dezelfde plek.
Pas als je 28MB aan data geschreven hebt (grootte van je filesystem), heb je 1 volledige schrijf cyclus van de flash gebruikt.

[Gast]

Verder wordt, als je iets naar de flash schrijft, dit niet onmiddellijk ook weggeschreven, maar eerst in RAM gecached.

Dat heeft tot gevolg dat je na een vastloper vaak een gedeelte van je laatste settings kwijt bent (nog niet weggeschreven naar de flash/stick), maar dus ook dat de flash/stick niet zo 'wild' beschreven wordt als je denkt.

Ik zou er dus niet zo bang voor zijn, en de flash is volgens mij wel een stuk sneller dan USB.

 

Greetz, Lion.

[Gast]

Citaat:

Verder wordt, als je iets naar de flash schrijft, dit niet onmiddellijk ook weggeschreven, maar eerst in RAM gecached.

Dat is niet juist. jffs2 is een synchroon filesystem, als je write returnt, staat de data in flash. Gelukkig wel, dat maakt jffs2 juist tot een veilig flash filesystem.

Citaat:

Dat heeft tot gevolg dat je na een vastloper vaak een gedeelte van je laatste settings kwijt bent

Dat is een enigma 'feature'.

[offtopic]
De preciese reden voor deze rare keuze is mij niet helemaal duidelijk, ofwel de oorspronkelijke tuxbox ontwikkelaars waren (onterecht) bang voor flash wear, of ze hebben dit zo gedaan om het blocken van writes op veel te kleine volle NOR flash partities te voorkomen.
(juist vanwege het synchrone karakter van jffs2 kan, als voor een write actie een garbage collectie nodig is, de write een aantal seconden duren)

Of dit op de oudere boxen een probleem zal zijn kan ik moeilijk voorspellen, maar ik heb de neiging om alle configchanges in enigma synchroon te maken.
Op de 7020 zal dit geen enkel probleem zijn (NAND flash, snelle garbagecollectie), op de oudere boxen (NOR flash, trage garbagecollectie) is het een kwestie van uitproberen.

De huidige situatie betekent vaak dat een gewijzigde setting soms na een paar week weer ongedaan gemaakt wordt, als opeens de stroom uitvalt.
Dat je enigma moet restarten na het maken van een setting, is niet echt meer van deze tijd.
[/offtopic]

[Gast]

@pieterg: Dank voor de correctie, weer wat geleerd.

Ik heb altijd gedacht dat het moeten herstarten na config-wijzigingen kwam door filesystem-buffering, maar het zit dus een laagje hoger, in Enigma zelf?

Maar dan helpt een sync commando via telnet voor je herstart dus ook niet als je Enigma is vastgelopen?

En is er dan ook een verschil in 'veiligheid' tussen /var in flash of op USB?

Dit vanwege dat op de USB stick doorgaans geen jffs2 gebruikt wordt maar bijv. ext3.

 

Dit roept trouwens meteen een andere vraag op:

Zou het kunnen zijn dat het 'hikken' van opnames op de 500 ermee samenhangt dat op de 500 de /var op jffs2 staat, en dus synchroon geschreven wordt?

Stel dat een of ander proces tijdens het opnemen wat in de /var wegschrijft, ik denk aan EPG-data, of de cam oid.

Als dit door het synchroon zijn van jffs eens wat langer kan duren, zou dat het opnemen kunnen storen.

Of heb ik nu hele rare gedachten?

 

Greetz, Lion.

[Gast]

Citaat:

Ik heb altijd gedacht dat het moeten herstarten na config-wijzigingen kwam door filesystem-buffering, maar het zit dus een laagje hoger, in Enigma zelf?
Maar dan helpt een sync commando via telnet voor je herstart dus ook niet als je Enigma is vastgelopen?

Inderdaad, dat helpt dan niet meer, enigma zelf synct toch niet meer als hij vastgelopen is.

Citaat:

En is er dan ook een verschil in 'veiligheid' tussen /var in flash of op USB?
Dit vanwege dat op de USB stick doorgaans geen jffs2 gebruikt wordt maar bijv. ext3.

Een CF of een USB stick zijn behoorlijk powerfail 'unsafe'. Een CF emuleert namelijk een IDE device, en een USB stick een scsi device.
Wat beide intern doen met de data is niet gespecificeerd, en het kan best even duren voordat de data veilig is.
Verder kan gedurende een write in file A ergens anders in file B wat beschadigen, als op dat moment de spanning wegvalt.
En dat zijn dingen die een filesystem als ext3 nooit kan oplossen.
Maar omdat ext3 op zichzelf best stabiel is, vallen de gevolgen in de praktijk best mee. (en zo vaak valt de spanning nu ook weer niet uit).

jffs2 werkt alleen op een mtd device, maw rechtstreeks op de sectoren van de flash. En daar kan een filesystem boven op een blockdevice emulatielaag nooit aan tippen.

Citaat:

Zou het kunnen zijn dat het 'hikken' van opnames op de 500 ermee samenhangt dat op de 500 de /var op jffs2 staat, en dus synchroon geschreven wordt?
Stel dat een of ander proces tijdens het opnemen wat in de /var wegschrijft, ik denk aan EPG-data, of de cam oid.
Als dit door het synchroon zijn van jffs eens wat langer kan duren, zou dat het opnemen kunnen storen.
Of heb ik nu hele rare gedachten?

Als je leest wat voor rare vage stabiliteits problemen bezitters van 500's, en in iets mindere mate ook 7000 bezitters vaak hebben, waarbij een flash erase en/of factory reset dan de boel weer verbetert, en je zet dat tegenover de 100% stabiliteit van de 7020, onder alle omstandigheden, dan moet het verschil haast wel in de flash zitten.

jffs2 performt beduidend slechter naarmate er minder vrije ruimte in het fs zit. Een aantal (voor zover ik weet in de huidige versie nog steeds 5) sectoren wordt permanent vrij gehouden voor garbage collection, dat is dus al 64KB * 5 die je niet kunt gebruiken.
En zodra je nog maar een stuk of 7 sectoren vrij hebt, is de kernel vrijwel continu aan het garbage collecten, en dat is een vrij CPU intensieve zaak (laatste keer dat ik in de mtd driver internals keek, gingen de irq's nog uit gedurende bepaalde tijdrovende flash operaties...)

En inderdaad, hoewel de enigma config bijna nooit gesynct wordt, zijn er binnen enigma een aantal andere file operaties, die wel synchroon uitgevoerd worden.
Andere processen kunnen natuurlijk ook naar files schrijven, ik meen zelfs wel eens gezien te hebben dat sommige softcams tijdens het decoderen naar een file zitten te schrijven.

Ik heb zelf geen ervaring met andere boxen dan de 7020, maar als je zegt dat 'var op USB' op een 500 de boel veel stabieler maakt, dan sluit dat precies aan bij dit verhaal.

edit: typo