sonnenblen.de - Das unabhängige Sun User Forum Der Treffpunkt für Sun-Fans seit 2001
  Übersicht   Forum   Hilfe Suche Einloggen Registrieren   *
Suche
Google
Erweiterte Suche
Willkommen Gast. Bitte einloggen oder registrieren.
24. Mai 2012, 18:26:47

Einloggen mit Benutzername, Passwort und Sitzungslänge
Letzte 5 Shouts:
09. April 2012, 22:24:40
Genau! dir auch noch knappe 35 Minuten Rest-Ostern Wink und denen dies noch vor 0 Uhr lesen ebenso ein frohes Rest-Ostern Wink
08. April 2012, 12:25:29
Falls heute noch jemand hier vorbei schaut: Frohe Ostern!  :-)
14. März 2012, 02:18:10
Wet,Wetter,abgesoffen? Wink *scnr*
21. September 2011, 17:02:09
USENET? - Tolles Ding!
11. September 2011, 15:09:12
Super Wetter!
Spenden
Anzeige
Berechtigungen

Anzeige
Seiten: 1 [2]   Nach unten
  Drucken  
Autor Thema: Kompression funktioniert nicht (richtig)  (Gelesen 2051 mal)
batschul
Sobl Newbie
*
Offline Offline

Beiträge: 21

Ich mag keine Signaturen!


WWW
« Antworten #15 am: 03. Februar 2009, 21:26:43 »

Da ich zwar überhaupt keine Ahnung von ZFS habe, aber neugierig bin, möchte ich mal was fragen:

Heisst das, dass die Kompression gar nicht stattfindet, weil das File gar nicht geschrieben, sondern lediglich der Platz allokiert wird?

Claus

nicht ganz, es ist sozusagen die "ueber" kompression, es werden in diesem fall in der tat keine user daten blocks
allokiert und geschrieben um komprimierte 0en zu schreiben, wozu auch. jeder block wurde komprimiert mit dem
ergebniss das er keinen platz braucht, ergo wird nur die ondisk dnode fuer die datei allokiert und geschrieben
und die vermeintliche groesse der datei in der ondisk dnode gespeichert, jedoch ohne weitere user daten
bloecke zu belegen. es ist eine datei voller 0en, ein sparse file, lesen davon liefert wiederum nur nullen.

ich wuerde also sagen das topic dieses threads: 'Kompression funktioniert nicht (richtig)'
ist nicht ganz korrekt..in der tat funktioniert sie excellent.

---
frankB

Gespeichert
sonnenblen.de - Das unabhängige Sun User Forum
« Antworten #15 am: 03. Februar 2009, 21:26:43 »

 Gespeichert
batschul
Sobl Newbie
*
Offline Offline

Beiträge: 21

Ich mag keine Signaturen!


WWW
« Antworten #16 am: 04. Februar 2009, 10:51:38 »

Da ich zwar überhaupt keine Ahnung von ZFS habe, aber neugierig bin, möchte ich mal was fragen:

Heisst das, dass die Kompression gar nicht stattfindet, weil das File gar nicht geschrieben, sondern lediglich der Platz allokiert wird?

Claus

nicht ganz, es ist sozusagen die "ueber" kompression, es werden in diesem fall in der tat keine user daten blocks
allokiert und geschrieben um komprimierte 0en zu schreiben, wozu auch. jeder block wurde komprimiert mit dem
ergebniss das er keinen platz braucht, ergo wird nur die ondisk dnode fuer die datei allokiert und geschrieben
und die vermeintliche groesse der datei in der ondisk dnode gespeichert, jedoch ohne weitere user daten
bloecke zu belegen. es ist eine datei voller 0en, ein sparse file, lesen davon liefert wiederum nur nullen.

ich wuerde also sagen das topic dieses threads: 'Kompression funktioniert nicht (richtig)'
ist nicht ganz korrekt..in der tat funktioniert sie excellent.


ich hab das mal mit einem zdb output anschaulich gemacht, 'zdb -dddddd' auf den pool der
die besispiel datei enthaelt _mit_ kompression an:

-- snip --
    Object  lvl   iblk   dblk  lsize  asize  type
         4    3    16K   128K   128K      0  ZFS plain file (K=inherit) (Z=inherit)
                                 264  bonus  ZFS znode
        path    /testfile
        atime   Wed Feb  4 10:31:32 2009
        mtime   Wed Feb  4 10:31:44 2009
        ctime   Wed Feb  4 10:31:44 2009
        crtime  Wed Feb  4 10:31:32 2009
        gen     30850
        mode    100644
        size    1073741824
        parent  3
        links   1
        xattr   0
        rdev    0x0000000000000000
Indirect blocks:
-- snip --

keine indirekten bloecke allokiert, und 'asize' ist 0

im gegensatz dazu das gleiche beispiel auf mit ausgeschalteter kompression (1MB datei),
'asize' (physisch fuer daten & metadaten belegte bloecke) == 1MB

    Object  lvl   iblk   dblk  lsize  asize  type
         5    2    16K   128K     1M  1.00M  ZFS plain file (K=inherit) (Z=inherit)
                                 264  bonus  ZFS znode
        path    /testfile1
        atime   Wed Feb  4 10:36:25 2009
        mtime   Wed Feb  4 10:36:25 2009
        ctime   Wed Feb  4 10:36:25 2009
        crtime  Wed Feb  4 10:36:25 2009
        gen     31155
        mode    100644
        size    1048576
        parent  3
        links   1
        xattr   0
        rdev    0x0000000000000000
Indirect blocks:
               0 L1  1:e0400:400 0:100400:400 4000L/400P F=8 B=31155
               0  L0 0:2cc0000:20000 20000L/20000P F=1 B=31155
           20000  L0 0:c0000:20000 20000L/20000P F=1 B=31155
           40000  L0 0:a0000:20000 20000L/20000P F=1 B=31155
           60000  L0 0:80000:20000 20000L/20000P F=1 B=31155
           80000  L0 1:80000:20000 20000L/20000P F=1 B=31155
           a0000  L0 0:e0000:20000 20000L/20000P F=1 B=31155
           c0000  L0 1:a0000:20000 20000L/20000P F=1 B=31155
           e0000  L0 1:c0000:20000 20000L/20000P F=1 B=31155
-- snip --

frankB
Gespeichert
Seiten: 1 [2]   Nach oben
  Drucken  
 
Gehe zu:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006, Simple Machines LLC
TinyPortal v0.9.8 © Bloc
Prüfe XHTML 1.0 Prüfe CSS
sonnenblen.de, mood-indigo.org, unixforum.net und realcomputers.org sind Projekte der steinbruch.info GbR

Google war zuletzt hier 12. Mai 2012, 19:08:43