---

Min computer fryste da jeg skulle have den ud af dockingstationen, så
jeg måtte slukke den ved at holde power-knappen inde. Der må have været
nogle filer i min .mozilla-mappe, der er blevet korrupte, for da jeg
startede igen, var nogle af mine Firefox-indstillinger glemt.

Nu kan jeg godt leve med at genskabe mine indstillinger i Firefox, men
jeg har to spørgmål:

1) Kan jeg være sikker på, at andre eventuelt korrupte filer begrænser
sig til de jeg havde åbne da computeren frøs? Eller kan der være
korrupte filer blandt dem jeg ikke havde åbne?

2) Det er måske lidt naivt, men kan jeg på nogen måde finde ud af, om
der er andre korrupte filer eller må jeg bare krydse fingrer for at
der ikke er?

Filsystemet er ext4 på Arch Linux.

---

Lars Stokholm skrev:


<KLIP>

> Filsystemet er ext4 på Arch Linux.

Modigt.

--
Steen Suder

---

Steen Suder <sfs_news_spam@suder.dk> wrote:

>> Filsystemet er ext4 på Arch Linux.
> Modigt.

ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
mine maskiner.

Har du nogle konkrete oplevelser du vil dele?

--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"Squirming with anchovies!" - Wakko "Not!" - Dot

---

Allan Willems Joergensen skrev:
> Steen Suder <sfs_news_spam@suder.dk> wrote:
>
>>> Filsystemet er ext4 på Arch Linux.
>> Modigt.
>
> ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
> mine maskiner.
>
> Har du nogle konkrete oplevelser du vil dele?

Det burde jeg måske have kvalificeret mit "indlæg" med i første omgang.
To crashede maskiner i hostingkontekst (dog kun test . Det blev
opgivet til fordel for XFS (som deruover er standardvalget).

--
Steen Suder

---

On 2009-04-26, Allan Willems Joergensen <allan@nowhere.dk> wrote:
>
>>> Filsystemet er ext4 på Arch Linux.
>> Modigt.
>
> ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
> mine maskiner.
>
> Har du nogle konkrete oplevelser du vil dele?

Der har ihvertfald været nogle konkrete data-korrumperende bugs.

--
Andreas

---

Den 26 Apr 2009 14:37:01 GMT skrev Lars Stokholm:
> Min computer fryste da jeg skulle have den ud af dockingstationen, så
> jeg måtte slukke den ved at holde power-knappen inde. Der må have været
> nogle filer i min .mozilla-mappe, der er blevet korrupte, for da jeg
> startede igen, var nogle af mine Firefox-indstillinger glemt.
>
> Nu kan jeg godt leve med at genskabe mine indstillinger i Firefox, men
> jeg har to spørgmål:
>
> 1) Kan jeg være sikker på, at andre eventuelt korrupte filer begrænser
> sig til de jeg havde åbne da computeren frøs? Eller kan der være
> korrupte filer blandt dem jeg ikke havde åbne?

Det bør kun være de filer der var åbne for skrivning (jeg skriver
bevidst ikke "du", for de fleste vil nok være åbnet af diverse
daemons).

> 2) Det er måske lidt naivt, men kan jeg på nogen måde finde ud af, om
> der er andre korrupte filer eller må jeg bare krydse fingrer for at
> der ikke er?

Det ved kun programmet der skal læse filerne. Filsystemet ved ikke hvad
der er gyldige data, det kender kun bytes.

(Jeg går ud fra vi snakker om indholdet af filerne der er corrupt,
og ikke at filen er flyttet til lost+found).

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis wrote:
> Den 26 Apr 2009 14:37:01 GMT skrev Lars Stokholm:
>> 1) Kan jeg være sikker på, at andre eventuelt korrupte filer begrænser
>> sig til de jeg havde åbne da computeren frøs? Eller kan der være
>> korrupte filer blandt dem jeg ikke havde åbne?
>
> Det bør kun være de filer der var åbne for skrivning (jeg skriver
> bevidst ikke "du", for de fleste vil nok være åbnet af diverse
> daemons).

Okay, så burde mine vigtigste dokumenter være i fin behold.

>> 2) Det er måske lidt naivt, men kan jeg på nogen måde finde ud af, om
>> der er andre korrupte filer eller må jeg bare krydse fingrer for at
>> der ikke er?
>
> Det ved kun programmet der skal læse filerne. Filsystemet ved ikke hvad
> der er gyldige data, det kender kun bytes.

Det var også bare et spinkelt håb, men jeg ville være *helt* sikker. :)

> (Jeg går ud fra vi snakker om indholdet af filerne der er corrupt,
> og ikke at filen er flyttet til lost+found).

Ja, det er som du siger. I lost+found er der ikke noget.

Tak for dit svar.

---

Allan Willems Joergensen wrote:
> ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
> mine maskiner.

Hvad er da og hvorfor? Jeg har ikke valgt ext4 fremfor noget andet, jeg
har bare valgt det for at vælge noget.

---

Lars Stokholm <lars.stokholm@gmail.com> wrote:

>> ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
>> mine maskiner.
> Hvad er da og hvorfor? Jeg har ikke valgt ext4 fremfor noget andet, jeg
> har bare valgt det for at vælge noget.

I enterprise-sammenhænge kører jeg ext3 fordi det nu er hvad RedHat
bruger (og jeg har ikke oplevet problemer med det).

På mine egne maskiner kører jeg XFS fordi det er godt til størstedelen
af mine formål (mange større filer).

Jeg har testet ext4 på min laptop, men jeg synes ikke det gav mig nogle
fordele - Og jeg har oplevet det samme som i det oprindelige indlæg,
nemlig at Firefox opfører sig underligt efter crash; det mener jeg nu
godt nok også er sket med ext3, men jeg er ikke sikker.

mvh
--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"Admit it... you all will be destroyed." - Alien

---

Den 26 Apr 2009 19:46:50 GMT skrev Allan Willems Joergensen:
> Lars Stokholm <lars.stokholm@gmail.com> wrote:
>
>>> ext4 fungerer fint, omend det er ikke er mit førstevalg (eller anden) på
>>> mine maskiner.
>> Hvad er da og hvorfor? Jeg har ikke valgt ext4 fremfor noget andet, jeg
>> har bare valgt det for at vælge noget.
>
> I enterprise-sammenhænge kører jeg ext3 fordi det nu er hvad RedHat
> bruger (og jeg har ikke oplevet problemer med det).
>
> På mine egne maskiner kører jeg XFS fordi det er godt til størstedelen
> af mine formål (mange større filer).
>
> Jeg har testet ext4 på min laptop, men jeg synes ikke det gav mig nogle
> fordele - Og jeg har oplevet det samme som i det oprindelige indlæg,
> nemlig at Firefox opfører sig underligt efter crash; det mener jeg nu
> godt nok også er sket med ext3, men jeg er ikke sikker.

Filsystemet (uanset hvilket du vælger) garantere ikke mod at indholdet
af en fil bliver corrupt, hvis systemet crasher når der skrives til
filen. Det er op til programmet at implementere transaktioner hvis
det er påkrævet.

Jeg kunne godt tænke mig at OS'et fik systemkald til fil-transaktioner,
som filsystemets journal så kunne tage hånd om. Men det findes mig
bekendt ikke, og vil heller ikke være nemt at implementere, for mange
programmer vil kræve at det virker på tværs af filer, for at være
brugbart (fx en form for database i en fil, med index i en anden.
Transaktionen omfatter begge filer, og kommer de ud af sync, er der
problemer, også selvom de set alene er korrekte).

Sålænge det ikke findes, kan filsystemet ikke hjælpe mod corrupte filer.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Allan Willems Joergensen wrote:
> Jeg har testet ext4 på min laptop, men jeg synes ikke det gav mig nogle
> fordele - Og jeg har oplevet det samme som i det oprindelige indlæg,
> nemlig at Firefox opfører sig underligt efter crash; det mener jeg nu
> godt nok også er sket med ext3, men jeg er ikke sikker.

Hmm, er Firefox mon specielt udsat? Eller er fejl dér bare specielt
nemme at få øje på? Eller er det bare tilfældigt?

---

On 26 Apr 2009 20:08:11 GMT, Lars wrote:

> Hmm, er Firefox mon specielt udsat? Eller er fejl dér bare specielt
> nemme at få øje på? Eller er det bare tilfældigt?

Jeg tror Firefox er specielt udsat, jvnf. Ted Tso på lkml:

"Right now Firefox 3.0 writes 2.5 megabytes each time you click on a
URL, not counting the Firefox cache; I have my Firefox cache directory
symlinked to /tmp to save on unnecessary SSD writes, and I was still
recording 2600k written to the filesystem each time I clicked on a
HTML link. This means that for every 400 pages that I visit, Firefox
is currently generating a full gigabyte of (in my view, unnecessary)
writes to my SSD, all in the name of maintaining Firefox's "Awesome
Bar". This rather nasty behaviour should hopefully be significantly
improved with Firefox 3.1, or so the Sqlite maintainer tells me."

- http://article.gmane.org/gmane.linux.kernel/813517


Mvh.

--
"Angels can fly because they take themselves lightly." Adam Sjøgren
asjo@koldfront.dk

---

Adam Sjøgren wrote:
> "Right now Firefox 3.0 writes 2.5 megabytes each time you click on a
> URL, ....

Spændende! Jeg spekulerer på, om det her berører de fine
Ubuntu-installationer man kan installere på og køre fra en USB-nøgle.

Tricket med at symlinke Firefox-cachen til tmpfs er smart.

--
Stephan

---

Lars Stokholm <lars.stokholm@gmail.com> wrote:

> Hmm, er Firefox mon specielt udsat? Eller er fejl dér bare specielt
> nemme at få øje på? Eller er det bare tilfældigt?

Det er jo i hvert fald til at få øje på når Firefox-profilen er tilbage
til default :)

--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"So, are you saying we should pay more attention to the MOVIES?"

---

2009-04-26 Lars Stokholm wrote
> Min computer fryste...
> ... da jeg
> startede igen, var nogle af mine Firefox-indstillinger glemt.
> ...
> Filsystemet er ext4 på Arch Linux.

Mener helt bestemt at have læst at ext4 skulle have væsentligt længere
imellem sine sync's end andre mere old-school filsystemer. Men jeg kan
naturligvis ikke lige finde artiklen jeg mener at kunne huske måske
engang at have læst, måske.....

Men hvis det holder vand, så er det jo nok derfor du oplever problemer
i forbindelse med et crash. Andre ville sikkert have set det samme med
ext3, men dog bare langt mindre sansynligt.


/Morten

---

Den 27 Apr 2009 18:57:29 GMT skrev Morten Guldager:
> 2009-04-26 Lars Stokholm wrote
>> Min computer fryste...
>> ... da jeg
>> startede igen, var nogle af mine Firefox-indstillinger glemt.
>> ...
>> Filsystemet er ext4 på Arch Linux.
>
> Mener helt bestemt at have læst at ext4 skulle have væsentligt længere
> imellem sine sync's end andre mere old-school filsystemer. Men jeg kan
> naturligvis ikke lige finde artiklen jeg mener at kunne huske måske
> engang at have læst, måske.....

Det ændrer ikke noget, for en sync gør ikke andet end at skrive det
der ligger cachet i RAM ned på disk. En sync bekymrer sig ikke om
hvorvidt de data der ligger cachet i RAM er konsistente. Det kan den
ikke, fordi transaktioner er noget der foregår på applikations-niveau,
ikke på OS-nivau.

Hvis sidste sync har skrevet en halv transaktion til disk, vil
filens indhold være korrupt. Uanset hvornår sidste sync var. Og med
alle de data Firefox skriver, vil der sandsynligvis altid være en
halv transaktion, sålænge Firefox bliver brugt.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Morten Guldager skrev:

> Mener helt bestemt at have læst at ext4 skulle have væsentligt
> længere imellem sine sync's end andre mere old-school filsystemer.
> Men jeg kan naturligvis ikke lige finde artiklen […]

Se fx http://bit.ly/4TRzk (Wikipedia → Ext4 → Delayed allocation and
potential data loss).

Der er osse en lang, og måske irrelevant, tråd på

· https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Stephan Henningsen wrote:
> Tricket med at symlinke Firefox-cachen til tmpfs er smart.

Men du deler så også din cache med alle andre brugere på systemet.

---

On Tue, 28 Apr 2009 14:06:50 +0200, Stephan wrote:

> Adam Sjøgren wrote:

>> "Right now Firefox 3.0 writes 2.5 megabytes each time you click on a
>> URL, ....

> Spændende! Jeg spekulerer på, om det her berører de fine
> Ubuntu-installationer man kan installere på og køre fra en USB-nøgle.

Det kunne være interessant at vide hvordan han målte de 2.5MB, i øvrigt.


Mvh.

--
"Angels can fly because they take themselves lightly." Adam Sjøgren
asjo@koldfront.dk

---

On 28 Apr 2009 19:04:30 GMT, Lars wrote:

> Stephan Henningsen wrote:

>> Tricket med at symlinke Firefox-cachen til tmpfs er smart.

> Men du deler så også din cache med alle andre brugere på systemet.

Hvorfor det? Virker permissions ikke i /tmp på tmpfs?


Mvh.

--
"Angels can fly because they take themselves lightly." Adam Sjøgren
asjo@koldfront.dk

---

Adam Sjøgren wrote:
> On 28 Apr 2009 19:04:30 GMT, Lars wrote:
>> Stephan Henningsen wrote:
>>> Tricket med at symlinke Firefox-cachen til tmpfs er smart.
>
>> Men du deler så også din cache med alle andre brugere på systemet.
>
> Hvorfor det? Virker permissions ikke i /tmp på tmpfs?

Joh, jeg ved ikke lige hvorfor jeg troede de ikke gjorde.

---

On Tue, 28 Apr 2009 14:06:50 +0200
Stephan Henningsen <blah@blah.blah> wrote:

> Tricket med at symlinke Firefox-cachen til tmpfs er smart.

jeg kan bedre lide den her :
<oneliner>
sed -i .firefox/default.pwk/prefs.js -e
'/browser.cache.disk.parent_directory/d' ; echo
"user_pref(\"browser.cache.disk.parent_directory\",
\"$(echo /tmp/${USER}ff3)\");" > .firefox/default.pwk/prefs.js
</oneliner>

så oprettes /tmp/${USER}ff3 , af browseren, hvis det ikke findes,
browser-processen ejes af mig, og derfor kommer /tmp/jagff3 til at ejes
af mig, hvorfor

jag@jag-tpr50$ ls -lartd /tmp/jagff3/
drwx------ 3 jag jag 60 2009-04-27 02:35 /tmp/jagff3/
jag@jag-tpr50$

root kan kigge og pille i min browser-cache, men det kan han alligevel
(enetn ejer han filsystemet, eller også kan han blive mig)


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

Jacob Gaarde wrote:
><oneliner>
> sed -i .firefox/default.pwk/prefs.js -e
> '/browser.cache.disk.parent_directory/d' ; echo
> "user_pref(\"browser.cache.disk.parent_directory\",
> \"$(echo /tmp/${USER}ff3)\");" > .firefox/default.pwk/prefs.js
></oneliner>
>
> så oprettes /tmp/${USER}ff3 , af browseren, hvis det ikke findes,
> browser-processen ejes af mig, og derfor kommer /tmp/jagff3 til at ejes
> af mig, hvorfor

Jeg har gjort det samme (bare med en editor :)) og så har jeg i stedet
for din "dynamiske" $() bare skrevet noget statisk.

Jeg har så også symlinket /tmp til /dev/shm. Er det noget makværk eller
er det i orden at bruge /dev/shm på den måde? Jeg har 4GB ram og
/dev/shm kan bruge halvdelen af dem.

---

Den 29 Apr 2009 19:14:47 GMT skrev Lars Stokholm:
> Jacob Gaarde wrote:
>><oneliner>
>> sed -i .firefox/default.pwk/prefs.js -e
>> '/browser.cache.disk.parent_directory/d' ; echo
>> "user_pref(\"browser.cache.disk.parent_directory\",
>> \"$(echo /tmp/${USER}ff3)\");" > .firefox/default.pwk/prefs.js
>></oneliner>
>>
>> så oprettes /tmp/${USER}ff3 , af browseren, hvis det ikke findes,
>> browser-processen ejes af mig, og derfor kommer /tmp/jagff3 til at ejes
>> af mig, hvorfor
>
> Jeg har gjort det samme (bare med en editor :)) og så har jeg i stedet
> for din "dynamiske" $() bare skrevet noget statisk.
>
> Jeg har så også symlinket /tmp til /dev/shm. Er det noget makværk eller
> er det i orden at bruge /dev/shm på den måde? Jeg har 4GB ram og
> /dev/shm kan bruge halvdelen af dem.

Det er ikke anbefalet. Du risikerer i princippet et navne-konflikt
mellem dine temp-filer og shared memory filer.

Du kan mount'e en tmpfs mere på /tmp.

Mvh
Kent
--
"The Brothers are History"

---

On Wed, 29 Apr 2009 20:41:41 +0200, Jacob wrote:

> jeg kan bedre lide den her :
> <oneliner>
> sed -i .firefox/default.pwk/prefs.js -e
> '/browser.cache.disk.parent_directory/d' ; echo
> "user_pref(\"browser.cache.disk.parent_directory\",
> \"$(echo /tmp/${USER}ff3)\");" > .firefox/default.pwk/prefs.js
> </oneliner>

Min variant går på at ændre ~/.mozilla/firefox/whatever/Cache til et
symlink til /tmp/.asjo_mozilla/Cache, og så sørger jeg for at mappen
oprettes i min personlige crontab:

@reboot mkdir -p /tmp/.asjo_mozilla/Cache; chmod go-rwx /tmp/.asjo_mozilla

Der er mange måder at opnå ca. det samme på


Mvh.

--
"Soon we'll have spent a whole month at sea, Adam Sjøgren
splitting atoms for no apparent reason" asjo@koldfront.dk

---

On Wed, 29 Apr 2009 22:40:45 +0200
asjo@koldfront.dk (Adam Sjøgren) wrote:

> Der er mange måder at opnå ca. det samme på

TMTOWTDI
(http://www.perlfoundation.org/perl5/index.cgi?tmtowtdi)


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 29 Apr 2009 23:07:40 +0200, Jacob wrote:

> On Wed, 29 Apr 2009 22:40:45 +0200
> asjo@koldfront.dk (Adam Sjøgren) wrote:

>> Der er mange måder at opnå ca. det samme på

> TMTOWTDI
> (http://www.perlfoundation.org/perl5/index.cgi?tmtowtdi)

Dog, ingen af os brugte Perl


Mvh.

--
"Halleluja og hurlumhej" Adam Sjøgren
asjo@koldfront.dk

---

On 29 Apr 2009 19:14:47 GMT
Lars Stokholm <lars.stokholm@gmail.com> wrote:

> Jeg har så også symlinket /tmp til /dev/shm. Er det noget makværk
> eller er det i orden at bruge /dev/shm på den måde? Jeg har 4GB ram og
> /dev/shm kan bruge halvdelen af dem.

nej det er vel fint, men du kunne også bind-mounte /dev/shm på /tmp som
noget af det første under boot,

- eller, hvis du bruger debian eller et
derivat (e.g. [kx]ubuntu)
rette i /etc/default/tmpfs , /etc/default/rcS, og
kopiere /etc/init.d/mountkernfs.sh til e.g. /etc/init.d/mountkernfs1.sh
og lave en masse sjov med at
montere /tmp, /var/cache/apt, /var/tmp, /var/mail, og evt. /var/log som
selvstændige tmpfs.
hvis man gør det med /var/log og /var/cache/apt og /var/mail, skal man
lige lave nogle julenumre med at bind-mounte de oprindelige dirs på
et andet sted inden man mounter tmpfs, og så kopiere de nødvendige
filer over i de nye tmpfs inden resten af boot-sekvensen kører. m.a.o,
man skal vide hvad man gør, vis man mounter tmpfs
på /var/cache/apt, /var/log og /var/mail.

jeg vil ikke lige poste min /etc/init.d/mountkernfs1.sh her, da

jag-tpr50# wc -l /etc/init.d/mountkernfs1.sh
113 /etc/init.d/mountkernfs1.sh
jag-tpr50#







--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Wed, 29 Apr 2009 23:18:46 +0200
asjo@koldfront.dk (Adam Sjøgren) wrote:

> > TMTOWTDI
> > (http://www.perlfoundation.org/perl5/index.cgi?tmtowtdi)
>
> Dog, ingen af os brugte Perl

men forkortelsen holder, sproget oavset^H^H^H^H^H^H^H uanset


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

Jacob Gaarde wrote:
> On 29 Apr 2009 19:14:47 GMT
> Lars Stokholm <lars.stokholm@gmail.com> wrote:
>> eller er det i orden at bruge /dev/shm på den måde? Jeg har 4GB ram og
>> /dev/shm kan bruge halvdelen af dem.
>
> nej det er vel fint, men du kunne også bind-mounte /dev/shm på /tmp som
> noget af det første under boot,

Jeg synes noget af det smarte ved mit symlink er, at det er nemt, at det
kun skal gøres én gang, at /dev/shm er der i forvejen og at der er
rigeligt tilgængelig plads. Så så længe der ikke er noget galt med det,
så er det en fin løsning for mig.

Men jeg er i tvivl om hvad du mener med at bind-mounte /dev/shm på /tmp
og nu blev jeg nysgerrig. Jeg bruger Arch Linux og jeg har ikke noget
specielt filsystem til /tmp - den ligger bare under / (root).

---

On 29 Apr 2009 21:35:14 GMT
Lars Stokholm <lars.stokholm@gmail.com> wrote:

> Men jeg er i tvivl om hvad du mener med at bind-mounte /dev/shm
> på /tmp og nu blev jeg nysgerrig. Jeg bruger Arch Linux og jeg har
> ikke noget specielt filsystem til /tmp - den ligger bare under /
> (root).

man mount

mount -obind /dev/shm /tmp


i min fstab :

jag@jag-tpr50$ grep bind /etc/fstab
/data/virtual/vmware   /vmware      bind
defaults_netdev,auto,bind,rw 0
0 /vmware         /mnt/VMWare   bind
defaults_netdev,auto,bind,rw 0
0 /vmware         /VMWare      bind
defaults_netdev,auto,bind,rw 0 0
#/data         /data      bind
defaults_netdev,auto,bind,rw 0 0 jag@jag-tpr50$


--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

Kent Friis wrote:
> Den 29 Apr 2009 19:14:47 GMT skrev Lars Stokholm:
>> Jeg har så også symlinket /tmp til /dev/shm. Er det noget makværk eller
>> er det i orden at bruge /dev/shm på den måde? Jeg har 4GB ram og
>> /dev/shm kan bruge halvdelen af dem.
>
> Det er ikke anbefalet. Du risikerer i princippet et navne-konflikt
> mellem dine temp-filer og shared memory filer.

Jeg tænkte nok der var et eller andet og jeg tænkte nok det var dig der
skulle fortælle mig hvad det var. :)

> Du kan mount'e en tmpfs mere på /tmp.

Done. Så har de fået 25% hver (af 4GB).

Tak.