staging.inyokaproject.org

Wo ist das Verhalten beschrieben?

Afaik in

File System Forensic Analysis
http://safari.oreilly.com/0321268172

mythos hat geschrieben:

Wer redet denn hier von zufällig? Die Seektime nähert sich einem Durchnschnittswert an, der weit entfernt von der Random Seektime ist.

Die Seektime wandert mit steigernder Fragmentierung von Average zu Random - letztere ist nämlich auch ein Durchschnittswert.
Einfach weil Fragmentierung prinzipbedingt weitestgehend zufällig ist - es gibt keine generelle Möglichkeit zu wissen, welche unterschiedlichen Teile in welcher Situation hintereinander stehen sollten.

Das kann man durch bestimmte Annahmen reduzieren und absolute Zufälligkeit wird nie erreicht werden. Aber das Problem besteht trotzdem.

mythos hat geschrieben:

Zum Rest schreibe ich gar nichts mehr, da mir die Zeit zu schade ist, alles zu beantworten (die Zeit fehlt mir sogar für diesen Post). Bei Gelegenheit schreibe ich den Artikel um.

Natürlich kannst und sollst Du Dich im Wiki einbringen.
Allerdings sind dabei zwei Dinge zu beachten:

Ersten finden grundlegenden Überarbeitungen in der Baustelle statt.
Und zweitens ist ein Thread zum Artikel dazu da, diese Überarbeitung zu diskutieren.

Insofern wirst Du kaum darum herum kommen, auf bestimmte Punkte näher einzugehen - und besonders strittige Punkte mit entsprechend fundierten Quellen zu belegen.

Chrissss hat geschrieben:

File System Forensic Analysis

Hm, momentan habe ich das jetzt nicht finden können bei den Beschreibungen wie Dateien angelegt werden.
Allerdings bin ich über die Beschreibung gestolpert, dass ext2 beim Löschen die Pointer im inode nullt und ext3 angeblich nicht... was sich nicht so ganz mit der FAQ deckt.

Du brauchst mich nicht zu belehren. Ich habe schlicht heute keine Zeit um alles raus zu suchen.

btw wenn du ein Dateisystem suchst, welches die Daten in einem Stück verwaltet, empfehle ich dir FAT.

mfg
mythos

mythos hat geschrieben:

btw wenn du ein Dateisystem suchst, welches die Daten in einem Stück verwaltet, empfehle ich dir FAT.

Das ist eigentlich in den üblichen Implementierungen das Dateisystem der Wahl, wenn man richtig toll viel Fragmentierung möchte...

Hallo,

BTW, wenn etwas offensichtlich falsch ist im Artikel - wie gesagt, ich bin nicht allwissend - kann das jeder gerne ändern. Es ist ein Wiki.

Aber natürlich bitte keinen Edit-War starten und subjektive Meinung als die "reine Lehre" darstellen. ☺

Gruß, noisefloor

P.S.: Dafür, das Defragmentierung unter Linux "kein Thema" ist, habe alle ganz schön viel zu sagen. 😇

noisefloor hat geschrieben:

Dafür, das Defragmentierung unter Linux "kein Thema" ist, habe alle ganz schön viel zu sagen.

Und erst recht interessant ist die Tatsache, dass obwohl es "wenn doch dann nur für Server ein Thema" ist, sich Kernel-Entwickler Skripte bauen um Build-Ordner zu defragmentieren. 😇

Rotbart van Dainig hat geschrieben:

Die Features von ext4 und Reiser4 sind noch völlig nebensächlich für den Artikel, da beide Systeme nicht für den Produktiveinsatz in Ubuntu taugen.

Es ging nur darum dass ext3 schlicht und ergreifend inzwischen effektiv veraltet ist... und der Nachfolger die üblichen Schutzbehauptungen eben widerlegt.

wann kann man denn mit einsatz für ubuntu rechnen ?

ext4? Mit etwas Glück 8.10.
Reiser4? Mit dem Release von Duke Nukem Forever für GNU HURD...

/dev/sdb1: 34437/48840704 files (52.4% non-contiguous), 82563283/97679208 blocks
/dev/sda6: 26/244320 files (3.8% non-contiguous), 16610/487966 blocks
/dev/sda5: 30354/3427200 files (4.7% non-contiguous), 2975011/6875812 blocks
/dev/sda7: 1553/8912896 files (74.7% non-contiguous), 12416157/17812060 blocks

also das schokkt mich doch grad sehr extrem !!! gut die 52% fragmentierung ist ein raid array und übers lan hab ich die vollen 11mb/s aber beim packen und entpacken macht sich doch ein performance verlust bemerkbar :/ die 74% HD is ne ftp server partition.

welches tools wurde denn schon getestet und für tauglich befunden ? shaker scheint ja nicht so der renner zu sein :/ und mal eben 600GB hin und herkopieren geht nicht weil ich kein plat habe. die sda7 und sdb1 partitionen sind grad mal ein halbes jahr alt !!

der geschokkte speefak.

rotbart wie defragmentierst du dein ext3 fs ?

wird es für 7.10 auch eine ext4 unterstüzung gegen ? wenn ja würde ich dann gerne auf ext4 umsteigen denn 3/4 fragmentierung sind mir doch ein bischen zu heftig.

Kopieren, bisher.

Und ext4-Unterstützung wird es nur für zukünftige Versionen geben.

auf gut deutsch gesagt :

scheisse

scheisse

* nach neuer platte such ...

moin,

bei mir sind komischerweise fast alle dateien in /bin, /lib, /usr/bin, ... fragmentiert (alle ext3). habe den verdacht, dass das im laufe der zeit durch updates passiert ist weil wenn die dateien bei der installation erstmalig geschrieben werden, sollten sie ja nicht fragmentiert sein. beispielsweise hat meine bash 57 extents und die scheinen auch nicht wirklich zusammenhängend zu sein:

filefrag -v  /bin/bash
Filesystem type is: ef53
Filesystem cylinder groups is approximately 38
File size of /bin/bash is 818232 (200 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0   471534               2 merged
   1       2   472086   471535      2 merged
   2       4   532501   472087      2 merged
   3       6   532525   532502      1 merged
   4       7   533561   532525      1 merged
   5       8   534759   533561      4 merged
   6      12   534764   534762     13 merged
   7      25   534781   534776      3 merged
   8      28   535072   534783      6 merged
   9      34   536581   535077      1 merged
  10      35   537499   536581      3 merged
  11      38   537506   537501      8 merged
  12      46   537845   537513      1 merged
  13      47   537848   537845      3 merged
  14      50   537949   537850      2 merged
  15      52   538914   537950      2 merged
  16      54   539040   538915     11 merged
  17      65   539052   539050      1 merged
  18      66   539058   539052      1 merged
  19      67   539066   539058      2 merged
  20      69   539072   539067      1 merged
  21      70   539075   539072      1 merged
  22      71   539084   539075      1 merged
  23      72   539086   539084      1 merged
  24      73   539094   539086      4 merged
  25      77   539100   539097      8 merged
  26      85   539116   539107      1 merged
  27      86   539119   539116      1 merged
  28      87   539200   539119      1 merged
  29      88   539204   539200      3 merged
  30      91   539250   539206      6 merged
  31      97   539261   539255      2 merged
  32      99   539284   539262      5 merged
  33     104   540686   539288      4 merged
  34     108   540691   540689      3 merged
  35     111   541051   540693      4 merged
  36     115   541071   541054      4 merged
  37     119   541080   541074      5 merged
  38     124   542737   541084      8 merged
  39     132   542827   542744     10 merged
  40     142   543990   542836      2 merged
  41     144   546958   543991      6 merged
  42     150   549029   546963      1 merged
  43     151   549037   549029      1 merged
  44     152   549146   549037     12 merged
  45     164   549163   549157      1 merged
  46     165   549174   549163      2 merged
  47     167   549286   549175      3 merged
  48     170   549290   549288      5 merged
  49     175   549296   549294      1 merged
  50     176   549298   549296      1 merged
  51     177   549406   549298      2 merged
  52     179   549410   549407      6 merged
  53     185   549418   549415      3 merged
  54     188   549422   549420      9 merged
  55     197   549432   549430      2 merged
  56     199   550916   549433      1 merged,eof
/bin/bash: 57 extents found, perfection would be 1 extent

sieht so aus, wie wenn die platte den lesekopf 3-4mal bewegen muss, nur um die bash zu lesen? oder interpretiere ich die daten falsch?

das im artikel erwähnte "defrag" oder rumkopieren und überschreiben hilft komischerweise nicht, nur auf den partitionen, die ich auf ext4 umgestellt habe (hab ich mit / noch nicht gemacht).

was sagt denn bei Euch filefrag /bin/* ?

tschö pimbi

hallo,

hier behaupten ein paar leute steif und fest, fragmentierte dateien würden sich schneller einlesen lassen, als unfragmnetierte. dafür hätte ich gerne mal ne quelle, ansonsten sieht das eher aus wie "wenn ich keinen defragmentierer kriege, will ich auch keinen" 😉

tschö pimbi

@ pimbi:

Bitte sei auch selber "kreativ" bei der Suche nach der Antwort. Im 1.Satz des Artikels ist ein Wikipedia-Link referenziert. Dort wird es relativ erschöpfend beschrieben. Ansonsten auch mal in's englische Wikipedia schauen, oft gibt es dort mehr Info und andere weiterführende Links. Auch im Artikel sind unter Links am unteren Seitenende welche.

@ all:

Bereits seit Ubuntu Precise Pangolin existiert ein Programm 'e4defrag' zur Online-Deframentierung von ext4. Es ist Bestandteil von e2fsprogs.

Nachweis:

apt-cache policy e2fsprogs
e2fsprogs:
  Installiert: 1.42-1ubuntu2
  Kandidat:    1.42-1ubuntu2
  Versionstabelle:
 *** 1.42-1ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status
$ dpkg -L e2fsprogs | grep e4defrag
/usr/sbin/e4defrag
/usr/share/man/man8/e4defrag.8.gz

Etwas Info findet sich bereits in der online Manpage : e4defrag

Ich hatte den Verdacht, dass .vdi beim Nutzen von "Snapshots" (Virtualbox Container) auf meiner USB-HDD und andere Dateien im Benutzer-Ordner (z.B. bei Mehrfach-Segment Download) doch etwas "zerkluttern". Diesen Verdacht hat sich nun bei mir bestätigt. Überrascht hat mich dies besonders beim /Home/BENUTZER/.mozilla/*.* Ordner. Die Überprüfungsfunktion bestätigt ansonsten die geringe Defragmentierung innerhalb des ext4-Dateisystems.

Falls jemand mehr Ahnung von der Materie hat, würde ich mich über eine Ergänzung im Artikel freuen und habe diesen Hinweis dafür hier hinterlegt.

edit: done, Merci! @ Vlad Cohen 😉