Wo ist das Verhalten beschrieben?
Afaik in
File System Forensic Analysis
http://safari.oreilly.com/0321268172
Anmeldungsdatum: Beiträge: 37971 |
Afaik in File System Forensic Analysis |
Anmeldungsdatum: Beiträge: 2870 |
mythos hat geschrieben:
Die Seektime wandert mit steigernder Fragmentierung von Average zu Random - letztere ist nämlich auch ein Durchschnittswert. Das kann man durch bestimmte Annahmen reduzieren und absolute Zufälligkeit wird nie erreicht werden. Aber das Problem besteht trotzdem. mythos hat geschrieben:
Natürlich kannst und sollst Du Dich im Wiki einbringen. Ersten finden grundlegenden Überarbeitungen in der Baustelle statt. Insofern wirst Du kaum darum herum kommen, auf bestimmte Punkte näher einzugehen - und besonders strittige Punkte mit entsprechend fundierten Quellen zu belegen. |
Anmeldungsdatum: Beiträge: 2870 |
Chrissss hat geschrieben:
Hm, momentan habe ich das jetzt nicht finden können bei den Beschreibungen wie Dateien angelegt werden. |
Anmeldungsdatum: Beiträge: 1080 |
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 |
Anmeldungsdatum: Beiträge: 2870 |
mythos hat geschrieben:
Das ist eigentlich in den üblichen Implementierungen das Dateisystem der Wahl, wenn man richtig toll viel Fragmentierung möchte... |
Ehemaliger
(Themenstarter)
Anmeldungsdatum: Beiträge: 28953 Wohnort: WW |
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. 😇 |
Anmeldungsdatum: Beiträge: 2870 |
noisefloor hat geschrieben:
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. 😇 |
Anmeldungsdatum: Beiträge: 28 |
Rotbart van Dainig hat geschrieben:
wann kann man denn mit einsatz für ubuntu rechnen ? |
Anmeldungsdatum: Beiträge: 2870 |
ext4? Mit etwas Glück 8.10. |
Anmeldungsdatum: Beiträge: 28 |
/dev/sdb1: 34437/48840704 files (52.4% non-contiguous), 82563283/97679208 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. |
Anmeldungsdatum: Beiträge: 2870 |
Kopieren, bisher. Und ext4-Unterstützung wird es nur für zukünftige Versionen geben. |
Anmeldungsdatum: Beiträge: 28 |
auf gut deutsch gesagt : scheisse scheisse * nach neuer platte such ... |
Anmeldungsdatum: Beiträge: 7 |
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 |
Anmeldungsdatum: Beiträge: 7 |
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 |
Anmeldungsdatum: Beiträge: 966 |
@ 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. Achtung!Vor einem Einsatz bei Solid State Disks und bei mit NTFS (Windows) formatierten Datenträgern sei gewarnt. Eine vorhandene Datensicherung minimiert das Risiko eines möglichen Datenverlustes. 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 😉
|