[EXT3] Files nemen dubbele ruimte in na partitioneren? *

[mithras]

Wat is er aan de hand
Ik wilde van mijn hdd (300GB Seagate schijfje) van situatie#1 naar situatie#2:

code:

Situatie #1
sdb2 (100GB, 80% vol) | Free space (70GB) | sdb3 (10GB) | sdb4 (70GB, 99% vol)
-----------------------------------------------
Situatie #2
sdb2 (100GB, 80% vol) | sdb3 (10GB) | sdb4 (140GB (bedoeling) 50% vol)

Dit deed ik onder Windows XP met PM8. Echter liep tijdens de laatste operatie (de data van sdb4 van het eind van de partitie naar het begin kopieren) PM8 vast
Toen ik terugging naar Ubuntu 6.06 (waar ik standaard mee werk) moest sdb4 gecontroleerd worden. Dit was lastig, er bleken "duplicated blocks" te bestaan. Ik heb handmatig een fsck op /dev/sdb4 uitgevoerd en alles laten repareren. Toen ik mijn schijfruimte later ging bekijken, was sdb4 99% vol!
Wat nu
Alle data is dus correct overgenomen, alleen staat alles er dubbel op. In het gebruik merk je hier niets van, alleen kan er eigenlijk niets meer bij de schijf! Ik wil dus alle duplicated data weghebben. Echter heb ik niet zomaar de ruimte meer om dit op te slaan, en wil ik wel alles wat erop staat behouden
Probleem
Ja Maar ik wil wel graag wat meer schijfruimte overhebben. sdb4 is een ext3 partitie, en ik wil liefst dit zonder Windows oplossen. Maar hoe? Heeft iemand de oplossing?

Dus ff in het kort
Ik draai Ubuntu 6.06 alles up-to-date. Verder is dit niet mn / of /home partitie, evenmin mijn C:\ of Documents&Settings partitie van Windows, die staan alle vier op een andere schijf. Op dit moment vind fsck ook dat de partitie clean is.
Wie helpt?

[The Evil Brain]

Al gekeken met PM8 wat die zegt? Die heeft het immers verneukt, dus misschien dat die het ook weer kan repareren?

[mithras]

Ha Bas
Maar PM vindt dus ook niets Ik heb PM8 een 'check partition for errors' laten doen, maar de partitie was dus helemaal goed (niet dus ).
Verder bedacht ik me, dat misschien de blocks wel leeg zijn, maar niet zijn vrij gegeven. Ik weet niet of dit kan, maar dat is misschien ook een mogelijkheid.

[mithras]

Hoewel het nog geen 24 uur geleden is: ik heb wel nieuwe dingen gevonden:

• Allereerst zal dus het verwijderen van data niet 2x zo snel gaan. Ik heb wat data gebackup'ed, vervolgens op sdb4 4GB verwijderd. Dit resulteerde dus ook in 4GB meer ruimte, en niet 8GB meer ofzo (helaas)
• In de terminal worden de meeste mappen van sdb4 weergegeven in de terminal met een color-code 42. Dit betekent een groene achtergrond. Je kan met google wel wat vinden over de color-codes, en hoe je ze kan aanpassen. Echter wordt nergens uitgelegd waar code 42 vandaan komt. Ook in mijn configfiles (zowel in /etc/ als in mn home) komt de colde 42 helemaal niet voor!

Ik ben nu een beetje op met mn fantasie hoe ik dit kan oplossen. Jammer genoeg kan ik niet alle data backup'en om zo de partitie te formatteren. Is er echt geen andere oplossing?

[stefan001]

Kan je niet een harde schijf lenen van iemand om je data tijdelijk op te zetten?

IMHO sowieso niet erg slim om dergelijke dingen met een schijf te doen als je data erg belangrijk is. nofi hoor

[ Voor 5% gewijzigd door stefan001 op 19-06-2006 12:39 ]

[mithras]

Tja, ik weet dat het stom is om met partities te klooien. Het was echter niet mn C:\, Documents&Settings, / of /home, dus ik dacht, ik probeer het gewoon

Ik ga dus steeds meer denken dat (en ik weet niet of het mogelijk is, ik ben niet zo'n HDD-nerd ) lege blocks niet zijn vrijgeven. Echter heb ik gezocht, maar geen enkel programma'tje gevonden wat zoiets kan. Omdat het een ext3 partitie is, kan je het niet defragmenteren vanuit Windows (en al kan het wel, dat ga ik niet proberen ). Dus zoek ik een 3rd party tooltje wat mn hdd verder bekijkt dan alleen op fouten.

[stefan001]

Dan zal je een linux tooltje nodig hebben, maar dan ben je bij mij aan het verkeerde adres helaas . Wat jij kennelijk nodig hebt is scandisk for linux

[Spider.007]

Zou je iets verder uit kunnen leggen wat er nu precies op je schijf staat? Je ziet alle data 1 keer maar deze neemt de dubbele ruimte in beslag oid? [q]• In de terminal worden de meeste mappen van sdb4 weergegeven in de terminal met een color-code 42. Dit betekent een groene achtergrond. Je kan met google wel wat vinden over de color-codes, en hoe je ze kan aanpassen. Echter wordt nergens uitgelegd waar code 42 vandaan komt. Ook in mijn configfiles (zowel in /etc/ als in mn home) komt de colde 42 helemaal niet voor! Post de output van `dircolors` eens?

[mithras]

Spider.007 schreef op maandag 19 juni 2006 @ 19:46:
Zou je iets verder uit kunnen leggen wat er nu precies op je schijf staat? Je ziet alle data 1 keer maar deze neemt de dubbele ruimte in beslag oid?

Volgens mij wel idd. Ik kan gewoon de hele directorystructuur bekijken, muziek afspelen in Rhythbox (NB. Listen pakt kennelijk de muziek niet meer. Voor het veranderen van de partities was het nog wel het geval) en afbeeldingen (foto's ed) zijn ook intact.

Post de output van `dircolors` eens?

Dat is dit:

code:

jurian@jvs:~$ dircolors
LS_COLORS='no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35:';
export LS_COLORS
jurian@jvs:~$

Hier staat 42 wel in met 42:ow=34. Echter geeft Google ook niet zo veel hulp daarbij (1 hit, uit Taiwan ofzo)

\edit: ter verduidelijking plaatjes van de situatie:
Mijn schijf:

Mijn data:

Hier staat wel echter aangegeven

sommige inhoud niet leesbaar

[ Voor 17% gewijzigd door mithras op 19-06-2006 21:56 ]

[Spider.007]

ow staat volgens mij voor het schrijfbaar zijn van je files door anderen; en geeft dus behalve de permissies geen speciale status aan de bestanden. Ik ga je topic ook even verplaatsen aangezien er in NOS wellicht meer mensen zijn die hier dieper in kunnen duiken Ik pas ook je topictitel even aan

CSA > NOS
Na partitionering schijf overvol > [EXT3] Files nemen dubbele ruimte in na partitioneren? *

[daft_dutch]

de fout zit niet in ext3 ext3 is ext2 met jouraling.
proven en save. Ik denk dat partition magic het niet helemaal 100% goed gedaan heeft.

fsck heeft heeft het gerepareerd. kijk eens in /lost-found/ mischien zit daar iets wat 50% je hd opvreet.

bij konqueror is een bestand weergave wat de file tree weer geeft in grote die ze op de hd in nemen.
Kan je makkelijk zien Waar de grote bestanden zijn en hoe ze zijn ingedeeld.

voorbeeld als je een hd hebt van 4GB en een file is 2GB is dit een blok met de helft van het totale beeld.

je kan het best qparted gebruiken voor het aanrommelen met partities.

[Spider.007]

daft_dutch schreef op dinsdag 20 juni 2006 @ 17:03:
de fout zit niet in ext3 ext3 is ext2 met jouraling.
proven en save. Ik denk dat partition magic het niet helemaal 100% goed gedaan heeft.

[...]

Volgens mij is dat niet automatisch de reden dat ext3 niet de oorzaak is Wellicht zijn er bijvoorbeeld meerdere links naar bepaalde data gemaakt; of worden niet-gelinkte inodes wel in gebruik gehouden oid. Nu ben ik geen filesystem expert; maar jouw conclusie vindt ik ook iets te voorbarig

[mithras]

daft_dutch schreef op dinsdag 20 juni 2006 @ 17:03:
bij konqueror is een bestand weergave wat de file tree weer geeft in grote die ze op de hd in nemen.
Kan je makkelijk zien Waar de grote bestanden zijn en hoe ze zijn ingedeeld.

Als je bedoelt dat ik de gehele tree moet uitklappen. Dat heb ik gedaan (alle 925 folders ) en dit is het resultaat:

Dus ook hier wordt maar 73GB aangegeven
Maar wel bedankt natuurlijk

Spider.007 schreef op dinsdag 20 juni 2006 @ 17:12:
[...]

Volgens mij is dat niet automatisch de reden dat ext3 niet de oorzaak is Wellicht zijn er bijvoorbeeld meerdere links naar bepaalde data gemaakt; of worden niet-gelinkte inodes wel in gebruik gehouden oid. Nu ben ik geen filesystem expert; maar jouw conclusie vindt ik ook iets te voorbarig

Dat niet-gelinkte inodes wel in gebruik gehouden denk ik ook aan. Heb al gezocht op google, maar daar is heel weinig over te vinden.

Verder: hoe langer ik hiermee bezig ben, hoe meer ik zin krijg om heel Windows eraf te gooien. En geen flame jegens MS, maar daar heb ik 80GB+ aan ruimte, en ik kom er steeds minder op. Alleen ben ik wel iemand die wil weten wat er aan de hand is en hoe je dit om een directe (simpele?) manier kan oplossen

[ Voor 43% gewijzigd door mithras op 20-06-2006 19:01 ]

[Spider.007]

Geef anders eens de output van `du -hs *` in de root (/home ?) van je schijf. Is de data echt dubbel zo groot; of kan het zijn dat er toch nog ergens iets groots rondzwerft? Kloppen de groottes van de files bij elkaar opgeteld bijvoorbeeld wel; of kun je wellicht traceren dat de schijf niet echt zo vol is; maar alleen zo vol lijkt te zijn? (kun je er nog wel naar schrijven bijvoorbeeld?)

[mithras]

Spider.007 schreef op dinsdag 20 juni 2006 @ 19:18:
Geef anders eens de output van `du -hs *` in de root (/home ?) van je schijf. Is de data echt dubbel zo groot; of kan het zijn dat er toch nog ergens iets groots rondzwerft? Kloppen de groottes van de files bij elkaar opgeteld bijvoorbeeld wel; of kun je wellicht traceren dat de schijf niet echt zo vol is; maar alleen zo vol lijkt te zijn? (kun je er nog wel naar schrijven bijvoorbeeld?)

Ik weet dus echt niet waar het aan ligt, de terminal output is

code:

jurian@jvs:/data$ sudo du -hs *
1,7G    afbeeldingen
4,0K    lost+found
28G     muziek
439M    profiles
2,8G    software
5,0M    torrents
40G     video
jurian@jvs:/data$

Als je echter info over de partities opvraagt, krijg je

code:

jurian@jvs:~$ df | grep data
/dev/sdb4             85703524  74843708   6435116  93% /data
jurian@jvs:~$

Wat dus heel tegenstrijdig is!

smokalot schreef op dinsdag 20 juni 2006 @ 20:43:
weet je zeker dat je filesystem wel goed is geresized? wat geeft df -h /partitie bijvoorbeeld?

Geeft

code:

jurian@jvs:~$ df -h /data
Bestandssysteem            Grtte Gebr Besch Geb% Aankoppeling
/dev/sdb4                  82G   72G  6,2G  93% /data
jurian@jvs:~$

[ Voor 17% gewijzigd door mithras op 20-06-2006 20:55 ]

[smokalot]

weet je zeker dat je filesystem wel goed is geresized? wat geeft df -h /partitie bijvoorbeeld?

[Wilke]

Het gebruik van wazige DOS/Windows-tooltjes om Linux-filesystems te resizen is natuurlijk sowieso _vragen_ om problemen.

Niet dat je daar nu veel aan hebt, maar dan weet je het voor de volgende keer.

Anyway, als je de bestanden nog wel gewoon kunt benaderen, zou je ze naar een andere schijf kunnen kopieren, dan fatsoenlijk herpartitioneren (gewoon in Linux) en dan de files terugzetten?

[Zwerver]

Wilke schreef op dinsdag 20 juni 2006 @ 23:07:
Het gebruik van wazige DOS/Windows-tooltjes om Linux-filesystems te resizen is natuurlijk sowieso _vragen_ om problemen.

Niet dat je daar nu veel aan hebt, maar dan weet je het voor de volgende keer.

Anyway, als je de bestanden nog wel gewoon kunt benaderen, zou je ze naar een andere schijf kunnen kopieren, dan fatsoenlijk herpartitioneren (gewoon in Linux) en dan de files terugzetten?

Hij zegt net dat ie daar de ruimte niet voor heeft


TS, als je met qparted de partitie probeert te schrinken, hoever kan je dan gaan? Kan je echt maar 6gib kleiner of heb je dan wel ineens spontaan genoeg ruimte? Mount die disk eens ext2 zodat je geen journaling meer hebt, wat is dan de diskgrootte?

[T-h-i-j-s]

Post eens de output van dumpe2fs -h /dev/sdb4
Ik ben benieuwd naar het aantal 'reserved blocks'. Misschien is dat om e.o.a reden belachelijk hoog.

edit:
Hmmm... bedenk me net dat dat geen invloed zou moeten hebben op de 'Used' blocks...
Wel op het percentage dat beschikbaar is.

[ Voor 35% gewijzigd door T-h-i-j-s op 21-06-2006 00:30 ]

[mithras]

Thijs_w schreef op woensdag 21 juni 2006 @ 00:26:
Post eens de output van dumpe2fs -h /dev/sdb4
Ik ben benieuwd naar het aantal 'reserved blocks'. Misschien is dat om e.o.a reden belachelijk hoog.

edit:
Hmmm... bedenk me net dat dat geen invloed zou moeten hebben op de 'Used' blocks...
Wel op het percentage dat beschikbaar is.

Dat is als volgt:

code:

jurian@jvs:~$ sudo dumpe2fs -h /dev/sdb4
Password:
dumpe2fs 1.38 (30-Jun-2005)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          51401cde-c2aa-40f5-b786-81877e111b72
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal needs_recovery
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              22129536
Block count:              22123513
Reserved block count:     1106175
Free blocks:              2715444
Free inodes:              22116294
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32736
Inode blocks per group:   1023
Last mount time:          Tue Jun 20 23:00:54 2006
Last write time:          Tue Jun 20 23:00:54 2006
Mount count:              13
Maximum mount count:      20
Last checked:             Sat Jun 17 14:26:46 2006
Check interval:           15552000 (6 months)
Next check after:         Thu Dec 14 13:26:46 2006
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       19510678
Journal backup:           inode blocks

jurian@jvs:~$

Wilke schreef op dinsdag 20 juni 2006 @ 23:07:
Anyway, als je de bestanden nog wel gewoon kunt benaderen, zou je ze naar een andere schijf kunnen kopieren, dan fatsoenlijk herpartitioneren (gewoon in Linux) en dan de files terugzetten?

Ja, ik had al eerder wat gemompeld:

Verder: hoe langer ik hiermee bezig ben, hoe meer ik zin krijg om heel Windows eraf te gooien. En geen flame jegens MS, maar daar heb ik 80GB+ aan ruimte, en ik kom er steeds minder op. Alleen ben ik wel iemand die wil weten wat er aan de hand is en hoe je dit om een directe (simpele?) manier kan oplossen

Dus misschien is dat een laatste optie?

[laurencevde]

je filesystem is nu 82GB groot, in plaats van de 140GB die je wilt hebben, maar je partitie is wel de volledige grootte. je filesysteem neemt dus niet de volledige ruimte in beslag
oplossing: resize2fs

[mithras]

laurencevde schreef op woensdag 21 juni 2006 @ 02:04:
je filesystem is nu 82GB groot, in plaats van de 140GB die je wilt hebben, maar je partitie is wel de volledige grootte. je filesysteem neemt dus niet de volledige ruimte in beslag
oplossing: resize2fs

laurencevde
Ik had namelijk nooit kunnen denken dat een filesystem niet direct gekoppeld zit aan een partitie. Dat daar dus ruimte "verloren" kan gaat. Het is nu weer helemaal in orde:

code:

jurian@jvs:~$ df | grep data
/dev/sdb4            162469272  74783960  80974000  49% /data
jurian@jvs:~$

[smokalot]

Mithras86 schreef op woensdag 21 juni 2006 @ 11:49:
[...]

laurencevde
Ik had namelijk nooit kunnen denken dat een filesystem niet direct gekoppeld zit aan een partitie. Dat daar dus ruimte "verloren" kan gaat. Het is nu weer helemaal in orde:

code:

jurian@jvs:~$ df | grep data
/dev/sdb4            162469272  74783960  80974000  49% /data
jurian@jvs:~$

he! ik was eerder met die opmerking!

[mithras]

smokalot schreef op woensdag 21 juni 2006 @ 12:23:
[...]

he! ik was eerder met die opmerking!

Want namelijk met die opmerking:

smokalot schreef op dinsdag 20 juni 2006 @ 20:43:
weet je zeker dat je filesystem wel goed is geresized? wat geeft df -h /partitie bijvoorbeeld?

had ik het nooit kunnen begrijpen, want alsnog snap ik vrij weinig van filesystems enzo:

Mithras86 schreef op woensdag 21 juni 2006 @ 11:49:
[...]
Ik had namelijk nooit kunnen denken dat een filesystem niet direct gekoppeld zit aan een partitie. Dat daar dus ruimte "verloren" kan gaat.

Maar natuurlijk bedank ik iedereen die mee heeft geholpen

[smokalot]

als je df -h /data gedaan zou hebben zou je toch een fikse hint gekregen kunnen hebben

* smokalot gaat nu maar weer weg, je gelijk proberen te krijgen heeft nooit zin, zelfs als je het overduidelijk hebt