Re: verifiering av filer

[Martin Leben]

Hej!

On 12/31/11 18:05, j...@lillahusetiskogen.se wrote:

Jamen, det är väl ganska exakt vad Anton skriver, om sync alltså.


Nej. Anton sa att man förlorar data om man inte kör sync innan.
Linux-kärnans dokumentation håller inte med. Den säger att man inte 
under några förutsättningar förlorar data.


mvh
/Martin


[...]

/Janne

On Sat, 31 Dec 2011 16:42:05 +0100
Martin Leben  wrote:


On 12/31/11 15:28, Anton Eliasson wrote:

För att utveckla: sync skriver innehållet i skrivbuffertarna till
disk omedelbart. Det påverkar inte läsbuffertarna. |echo 3>
/proc/sys/vm/drop_caches| tömmer läs- och skrivbuffertarna utan att
ta hänsyn till om innehållet i skrivbuffertarna har skrivits till
disk eller inte. Det är därför det kommandot måste köras direkt
efter sync, för att inte information ska gå förlorad.


Hej Anton!

Detta lät helt orimligt i mina öron.

Jag googlade lite och fann:


  "Writing to this will cause the kernel to drop clean
  caches, dentries and inodes from memory, causing that
  memory to become free."

... där står också några rader längre ned:

  "As this is a non-destructive operation and dirty
  objects are not freeable, the user should run `sync'
  first."

Anledningen till att man vill köra "echo 3

/proc/sys/vm/drop_caches" omedelbart efter sync är alltså att man
vill tömma så mycket av cache mm

som möjligt. Ingenting annat.

mvh
/Martin Leben



--
To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0061d3.20...@leben.nu

Re: verifiering av filer

[jan]

On Sun, 01 Jan 2012 14:38:27 +0100
Martin Leben  wrote:

> Hej!
> 
> On 12/31/11 18:05, j...@lillahusetiskogen.se wrote:
> > Jamen, det är väl ganska exakt vad Anton skriver, om sync alltså.
> 
> Nej. Anton sa att man förlorar data om man inte kör sync innan.
> Linux-kärnans dokumentation håller inte med. Den säger att man inte 
> under några förutsättningar förlorar data.

Rätt ska vara rätt!

/Janne

> 
> mvh
> /Martin
> 
> > [...]
> >
> > /Janne
> >
> > On Sat, 31 Dec 2011 16:42:05 +0100
> > Martin Leben  wrote:
> >
> >> On 12/31/11 15:28, Anton Eliasson wrote:
> >>> För att utveckla: sync skriver innehållet i skrivbuffertarna till
> >>> disk omedelbart. Det påverkar inte läsbuffertarna. |echo 3>
> >>> /proc/sys/vm/drop_caches| tömmer läs- och skrivbuffertarna utan
> >>> att ta hänsyn till om innehållet i skrivbuffertarna har skrivits
> >>> till disk eller inte. Det är därför det kommandot måste köras
> >>> direkt efter sync, för att inte information ska gå förlorad.
> >>
> >> Hej Anton!
> >>
> >> Detta lät helt orimligt i mina öron.
> >>
> >> Jag googlade lite och fann:
> >> 
> >>
> >>   "Writing to this will cause the kernel to drop clean
> >>   caches, dentries and inodes from memory, causing that
> >>   memory to become free."
> >>
> >> ... där står också några rader längre ned:
> >>
> >>   "As this is a non-destructive operation and dirty
> >>   objects are not freeable, the user should run `sync'
> >>   first."
> >>
> >> Anledningen till att man vill köra "echo 3
> >>> /proc/sys/vm/drop_caches" omedelbart efter sync är alltså att man
> >>> vill tömma så mycket av cache mm
> >> som möjligt. Ingenting annat.
> >>
> >> mvh
> >> /Martin Leben
> 
> 


--
To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120101160222.7b8c396c@nikolai

Re: verifiering av filer

[Anton Eliasson]

2012-01-01 16:02, j...@lillahusetiskogen.se skrev:

On Sun, 01 Jan 2012 14:38:27 +0100
Martin Leben  wrote:


Hej!

On 12/31/11 18:05, j...@lillahusetiskogen.se wrote:

Jamen, det är väl ganska exakt vad Anton skriver, om sync alltså.


Nej. Anton sa att man förlorar data om man inte kör sync innan.
Linux-kärnans dokumentation håller inte med. Den säger att man inte
under några förutsättningar förlorar data.


Rätt ska vara rätt!

/Janne


Ok, har man lärt sig något nytt!


mvh
/Martin


[...]

/Janne

On Sat, 31 Dec 2011 16:42:05 +0100
Martin Leben   wrote:


On 12/31/11 15:28, Anton Eliasson wrote:

För att utveckla: sync skriver innehållet i skrivbuffertarna till
disk omedelbart. Det påverkar inte läsbuffertarna. |echo 3>
/proc/sys/vm/drop_caches| tömmer läs- och skrivbuffertarna utan
att ta hänsyn till om innehållet i skrivbuffertarna har skrivits
till disk eller inte. Det är därför det kommandot måste köras
direkt efter sync, för att inte information ska gå förlorad.


Hej Anton!

Detta lät helt orimligt i mina öron.

Jag googlade lite och fann:


   "Writing to this will cause the kernel to drop clean
   caches, dentries and inodes from memory, causing that
   memory to become free."

... där står också några rader längre ned:

   "As this is a non-destructive operation and dirty
   objects are not freeable, the user should run `sync'
   first."

Anledningen till att man vill köra "echo 3

/proc/sys/vm/drop_caches" omedelbart efter sync är alltså att man
vill tömma så mycket av cache mm

som möjligt. Ingenting annat.

mvh
/Martin Leben









--
Med vänliga hälsningar / Regards
Anton Eliasson


--
To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0078ac.2010...@gmail.com

Re: verifiering av filer

[Anders Jackson]

God fortsättning allal

Den 31 december 2011 15:39 skrev  :
> On Sat, 31 Dec 2011 15:28:26 +0100 Anton Eliasson  
> wrote:

>> För att utveckla: sync skriver innehållet i skrivbuffertarna till
>> disk omedelbart. Det påverkar inte läsbuffertarna. |echo 3 >
>> /proc/sys/vm/drop_caches| tömmer läs- och skrivbuffertarna utan att
>> ta hänsyn till om innehållet i skrivbuffertarna har skrivits till
>> disk eller inte. Det är därför det kommandot måste köras direkt efter
>> sync, för att inte information ska gå förlorad. Nu tror jag dock att
>> vi jagar upp oss på problem som inte finns, för sannolikt har de
>> flesta metoder för filkopiering inbyggda kontroller för att
>> säkerställa att rätt information kopieras. Sen finns det ju idéer om
>> bitröta i magnetiska lagringsmedier och korruption i
>> icke-ECC-internminnen som man kanske vill vara förberedd på.
>
> Jag är tyvärr smärtsamt medveten om att stora filer går sönder. Både
> vid kopiering mellan datorer och lokalt.

Riskerna för "bitröta" blir större, ju större minnen vi använder.
Det var bland annat för att lösa detta problem med hårddiskar som ZFS
ser ut som det gör.  Läs om det, det finns många intressanta
blogg-inlägg skrivna om detta och om hur ZFS fungerar.

> Jag har sett det tidigare också men med Ubuntu 11.04 blev det riktigt
> tydligt. Tyvärr verkar problemet även, om än inte så allvarligt, finnas
> också i Mint Debian.

Tror inte att det har det minsta att göra med distributionernan, utan
möjligen version av kernel.  Men allra mest med vilket filsystem man
använder och hur dessa är uppbyggda.

> Och varför kör jag då inte vanlig Debian, som kanske fungerar felfritt.
> Jo, min hårdvara Asus E35M1-I stöds inte fullt ut av Debian. Så vitt
> jag vet.

Ok, det är väl ett bra argument.  Får man fråga vad det är?  Om det är
firmware som inte existerar, så finns det massa icke-fria firmware
packeterade.  Dessa kan dessutom användas när man installerar, bara
paketet finns på mediat (eller ett annat, som en USB-sticka).

> Gott nytt etc!
> /Janne

Önske dig som skriver det samma.

Så.

Jag tror inte alls att du behöver oroa dig för att md5 skall missa
något för att innehållet i RAM-bufferten är olikt innehållet på filens
sektor i disken.  Speciellt om filerna är mycket större än
RAM-storleken och allt som kopieras inte kan finnas i minnet
samtidigt.  OM du kopierar något som är mindre än buffertminnet, så
borde sync(1) räcka.
Men med stora datamängder så kommer ju md5sum att läsa genom filerna
för att kunna beräkna checksumman.  Då måste innehållet i alla filerna
läsas in till RAM-minnet.  Dvs läsa från disken, eftersom all data
inte får plats i RAM-buffertar.  Då skulle inte ens behöva använda
sync(1) för att tvinga OS:et att tömma buffertarna till disken.

Vad som kan eventuellt möjligen bli fel är att OS:et skriver data till
disken men inte kontrollerar när det skriver att det är samma data som
kommer tillbaka. För detta behöver filsystemet implementera
checksummor på allt, samt att OS:et behöver kolla dem, från att
program skriver data i RAM:buffertar tills att de skrivs på disk,  på
vägen tillbaka från disken och i RAM:buffertarna.  Varje del måste
verifieras om du flyttar MYCKET data.  Dvs du behöver stöd hela vägen.
 OpenSolaris hade detta stöd med ZFS, Linux börjar få det iom btrfs,
men har en bit kvar.

Att använda MD5sum på alla filerna är ett bra sätt att minska risken
för en förändring av en fil som du inte märker av.  Men att hantera de
fel som du vill undvika, är varken nödvändigt eller möjligt att
hantara med de vanligaste stora OS:en för konsumentdatorer. Vad jag
sett är väl Solaris det os som gjort mest för att hantera problem med
bitröta i stora diskar.

(Hmm, jag som tänkte skriva något kort...  :D )

/Jackson


--
To UNSUBSCRIBE, email to debian-user-swedish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacxj-bg+kskg7xxdzztauqqrxajd_oaaz_ehyjxseuo4bcy...@mail.gmail.com

Re: Angående qemu/kvm

[Anders Jackson]

God fortsättning.

Den 31 december 2011 16:04 skrev Peter Carlsson :
> On Sat, Dec 31, 2011 at 05:13:49AM +0100, Anders Jackson wrote:
>> Den 30 december 2011 23:49 skrev Peter Carlsson :
>
> Hej och tack Anders för den utförliga förklaringen. En del av det
> kände jag till och en del var nytt. Tyvärr blev jag inte så mycket
> klokare över hur jag rent konkret löser mitt problem även efter
> jag läst lite på länkarna du tipsade om.
>
>> > Hej!
>>
>> Hej
>>
>> > Just nu har jag en server (Debian stable) och en arbetsdator (Debian 
>> > testing).
>> >
>> > Servern är igång 24/7 och såpass kraftfull att den skulle kunna tjänstgöra 
>> > som både server och arbetsdator.
>> >
>> > Däremot vill jag fortfarande ha dem som två separata system av olika 
>> > anledningar.
>> >
>> > Jag provade att köra arbetsdatorn virtuellt på servern med hjälp av 
>> > qemu/kvm och det fungerade utmärkt om jag gjorde det via ssh med X 
>> > forwarding.
>>
>> Dvs du använder X-11-servern på den maskin du ansluter dig ifrån.
>
> Ja, det kände jag till. Det var mer för att tala om att min virtuella
> maskin fungerade.

Njae. Gör du?

>> > Kör jag däremot igång det direkt på servern så får jag felmeddelandet 
>> > inklistrat i slutet av mailet.
>> >
>> > Problemet är då att servern inte kör nåt grafiskt och har inte X server 
>> > installerat.
>
> Precis, och det är egentligen här jag undrar om jag verkligen måste
> installera hela X servern på min server (Debian stable) för att qemu
> ska ha en grafisk miljö för den korta stund det tar innan den virtuella
> maskinen bootat upp och använder sin egna X server.

För att köra grafiska program på din virtuella maskin, så behöver du
bara en VNC-xserver startad. Inte en vanlig X11-server.

Varför skall du ha X11-server körandes på din qemu-server-maskin?
Måste du ha en grafisk skärm kopplad till den?
Om inte, så kanske det räcker med att ha X11-klient-program
installerad på den maskinen.

Du får väl se till att inte ha något grafiskt program starta
automatiskt på din maskin.  För att köra grafisk miljö i KVM-klienter,
så använd VCN.

Har du provat att köra X11-serverna xnest eller xephyr (se paketen
xnest och xserver-xephyr) som använder en annan X11-server för att
skriva ut sin grafik och få tangentbord och råtta.

> Jag hade hoppats det skulle finnas något enklare/mindre.

>> Du kan köra X11-servrar som inte matar ut på en FB. Samt sedan skicka
>> det datat vidare till en annan X-server som kör på din maskin.
>>
>> Notera att X11 är ett nätverksprotokoll.  Dvs den kan jobba över
>> nätverk.  Tyvärr är det inte krypterat, vilket gör att den kan
>> avlyssnas om det inte gör via localhost (127.0.0.1) eller via en
>> socket i filsystemet (vilket är det vanligaste sättet).  Till och med
>> OpenGL kan gå över nätverket.
>>
>> X11-servern hanteras normalt av ett program som använder sig av
>> XDM-protokollet (X Display Manager - vilket implementeras exempelvis
>> av programmen gdm eller xdm) så att den kan hantera flera
>> X11-servrar.  X11-servrar kör normalt på arbetsstationer och XDM samt
>> X11-klienter (program som Firefox och Xterm etc) kör normalt på en
>> server.  X11-servern och X11-klienter kör vanligtvis på samma maskin
>> numera, som på din arbetsstation.  Så klient-server är normalt
>> "omvänt" mot filservrar (tänk på vilken som ber om att få något gjort
>> och vem som utför.  I X11 är det hanteringen av arbetsplatsen som är
>> tjänsten).
>>
>> När du kör ssh -X så tunnlas X11 via SSH till din lokala X11-server.
>> Därför behöver du inte något grafikkort på servern, fast du kör det
>> grafiska programmet där.
>>
>> Det finns några olika sätt att hantera X11-servrar och inloggningar
>> till X11-klienter (körandes på en server).
>>
>> 1) Ställ in din lokala XDM-server (som är konfigurerard att starta din
>> X11-server) att fråga över nätet vilka maskiner som hanterar
>> XDM-protokollet för din maskin.  Då kan du från en lista att välja
>> från vilken maskin du vill logga in på.  Då kommer allt, inklusive
>> fönsterhanteraren och skrivbordshanteraren att köra på vald server.
>> Din lokala maskin hanterar bara skärm, tangentbord och pekdon via
>> X11-servern.
>>
>> 2) Ställ in din lokala XDM-server så att den alltid ansluter mot en
>> viss server via XDM-protokollet (det är så det fungerar för din
>> arbetsstation.  Den startar själv en X11-server och ansluter direkt
>> XDM till den).
>>
>> 3) Du talar om för din X11-server på din klient (arbetsstation) att
>> när den startar så skall den låta en annan maskin hantera inloggningen
>> via XDM-protokollet. Då behöver du inte en XDM-server på klienten.
>>
>> Det är flexibelt, du kan köra dina virtuella maskiner på din maskin.
>> Nackdelen är att vem som helst kan avlyssna vad du gör på skärmen som
>> sitter på samma nätverk.
>
> Jag vet inte om det framgick eller om det ens har någon betydelse
> för din förklaring eftersom nätverket kan vara inom samma maskin.

Nätverksmässigt så bryr sig OS inte om data kommer från en intern
virtuell bridg