Filesize verschil bij kopie

[Verwijderd]

ik kopieer bestanden van een computer (mount een ext3 schijf, via nfs geshared) naar een andere computer (mount nfs share, naar een mounted raid 5 set, met luks/crypt).

als ik met KDE's 4 Dolphin een "properties" op die mounted share doe dan zie ik bij het origineel.
176.8 GiB (189,861,161,343). Hetzelfde getal zie ik op de originele bron computer met kde3.

Als ik nu met Dolphin bij de kopie kijk dan zie ik:
176.8 GiB (189,861,169,535)

Het aantal bestanden is gelijk. Waardoor komt dit verschil? Lijkt me niet dat ie standaard de "ware ruimte" die het inmeemt aangeeft toch? Ik heb wat bestanden gecontroleerd die gekopieerd zijn, deze lijken te kloppen. Hetzelfde probleem had ik met een andere kopieeropdracht.

Een eerdere grote kopieeractie gaf bij het origineel en de kopie wel dezelfde grootte aan.

[CAPSLOCK2000]

Het verschil is exact 8192 bytes, oftwel 2 blocks. Ik vermoed dat Dolphin een filetje aanmaakt met instellingen.
Heb je ook gekeken naar verborgen bestanden?

[Olaf van der Spek]

md5sum uitvoeren op beide directories, diff op het resultaat en klaar, toch?

[Verwijderd]

Olaf van der Spek schreef op woensdag 19 augustus 2009 @ 11:57:
md5sum uitvoeren op beide directories, diff op het resultaat en klaar, toch?

Iets zegt mij dat een md5 genereren op 170 GB aan data dat dat niet even gedaan is.

Wat ik trouwens nog vergeten te melden had. Ik had wat directories vergeleken. Ik deed de properties opvragen van dezelfde folder van het origineel en de kopie. Daar waren ze verschillend. Daarna ging ik IN de folder. Alles selecteren, properties en dan vergelijken. En daar waren ze gelijk

[Barleone]

Ik denk dan dat je inderdaad een verborgen bestandje over het hoofd ziet.
In Windows maak je zulke dingen maar al te vaak mee met thumbs.db of desktop.ini bestandjes die net die paar bytes verschil uitmaken

[Verwijderd]

Barleone schreef op woensdag 19 augustus 2009 @ 13:38:
Ik denk dan dat je inderdaad een verborgen bestandje over het hoofd ziet.
In Windows maak je zulke dingen maar al te vaak mee met thumbs.db of desktop.ini bestandjes die net die paar bytes verschil uitmaken

Ik ga daar inderdaad vanavond nog eens goed naar kijken. Wat wel raar is in dat geval is dat dus bij "alles" selecteren in de folder dat het wel klopt maar als ik de parent folder vergelijk het niet klopt.
Daarbij heb ik het ook met "du" vergeleken. En neem aan dat deze sowieso wel de hidden files mee vergelijkt?

[Verwijderd]

alles" selecteren in de folder dat het wel klopt maar als ik de parent folder vergelijk het niet klopt.

Ik zet een kratje bier op een hidden folder / file

[daft_dutch]

Verwijderd schreef op woensdag 19 augustus 2009 @ 14:22:
[...]

Ik zet een kratje bier op een hidden folder / file

Bier Verstoppen wat ben jij voor hollander.

[Peter]

Misschien een verschil in de chunk sizes van de filesystems (16k vs 8k bijvoorbeeld)?

[Sprite_tm]

Ik gok 't erop dat de directories zelf andere groottes hebben. Ik heb d'r verder niet zoveel verstand van, maar ik zie dat een dir op mijn HD (ext3) vaak 4096 bytes groot is. Dat groeit als ik er meer bestanden inflikker, maar word niet meteen automatisch kleiner als ik die files er weer uithaal:

jeroen@laptop:/tmp/bla$ mkdir klont
jeroen@laptop:/tmp/bla$ ls -l
drwxr-xr-x 2 jeroen jeroen 4096 Aug 21 15:15 klont
jeroen@laptop:/tmp/bla$ for x in `seq 1 1000`; do touch klont/$x; done
jeroen@laptop:/tmp/bla$ ls -l
drwxr-xr-x 2 jeroen jeroen 20480 Aug 21 15:15 klont
jeroen@laptop:/tmp/bla$ rm klont/*
jeroen@laptop:/tmp/bla$ ls -l
drwxr-xr-x 2 jeroen jeroen 20480 Aug 21 15:15 klont

Als er in die originele dir 'ooit eens' meer bestanden heeft gestaan, kan dat het geweest zijn.

[Verwijderd]

Hmm, dat klinkt vrij aannemelijk inderdaad; heb het op een ubuntu laptop geprobeerd en kom tot hetzelfde resultaat.

[Verwijderd]

Je kunt de grote van een dir zien met bijvoorbeeld 'du -cxh' maar om echt alleen de bestanden te tellen

code:

find ./ -type f -print0 > ./check.list
du -ch --file0-from=./check.list

Ook weet ik niet of Dolphin hard-links dubbel telt en als je echt het aantal bytes wilt gebruik je -cb ipv -ch.

Mocht je ook zeker willen zijn dat de inhoud van je bestanden klopt dan kun je vrij simpel een md5sum van alle bestanden makken.

Om de md5 checksums te maken van alle bestanden onder de huidige directory.

code:

find ./ -type f -print0 | xargs -0 md5sum -b >> ./check.md5

./check.md5 bevat nu je md5 hashes. Om deze te checken

code:

md5sum -c ./check.md5 > ./check.result

Ik weet dat er vast een schonere manier is zonder de ./check.result file maar nu kun je met een simpele 'grep FAILED ./check.result' alle mislukte en dus verschillende files te voorschijn toveren. Gebruik het zelf ook voor mijn backups.

ene, 170Gibibyte hashen op een moderen hdd duurt ongeveer 3 kwartier. Liniare leessnelheiden halen wel 110MB/s voor een enkel schijf dus een LVM-snapshot van 170GiB hashen @110MB/s gaat heel snel. Probleem is dat dit natuurlijk niet werkt om de inhoud van een volume te checken. Een enkele mount en je hashes kloppen al niet meer. Toch 170GiB aan files hashen is vast niet meer dan 2 uurtjes werk en kan prima in de achtergrond met 'nice' bijvoorbeeld. Zeker met nfs zou ik toch wekelijks even een check doen ofzo.

[Olaf van der Spek]

Verwijderd schreef op woensdag 19 augustus 2009 @ 13:30:
Iets zegt mij dat een md5 genereren op 170 GB aan data dat dat niet even gedaan is.

ls -alR dan?

[Verwijderd]

ik heb het maar even aangekaart bij de developers:
https://bugs.kde.org/show_bug.cgi?id=205959

Met dank aan "Sprite_tm" code voorbeeld
De methode van "Docey" ga ik binnenkort toepassen om de data te controleren.
Meer nieuws volgt.

[gertvdijk]

Verwijderd schreef op woensdag 02 september 2009 @ 12:00:
ik heb het maar even aangekaart bij de developers:
https://bugs.kde.org/show_bug.cgi?id=205959

i call it a bug, but the shell makes the same "mistake".

Je geeft daarmee toch zelf al aan dat het geen KDE bug is?

[Olaf van der Spek]

gertvdijk schreef op woensdag 02 september 2009 @ 22:33:
Je geeft daarmee toch zelf al aan dat het geen KDE bug is?

Als twee mensen dezelfde fout maken is het toch nog steeds een fout?
Als gebruiker wil ik total data size zien, dat is dus exclusief meta-data.

[hostname]

Olaf van der Spek schreef op donderdag 03 september 2009 @ 14:08:
[..]
Als gebruiker wil ik total data size zien, dat is dus exclusief meta-data.

Lijkt me toch onhandig. Zie je dat je nog 10GB vrij hebt, blijkt dat allemaal ingenomen te zijn door metadata en dan is het probleem weer dat je niet meer kan kopieeren naar een schijf waar nog ruimte is.

[Olaf van der Spek]

hostname schreef op donderdag 03 september 2009 @ 15:36:
Lijkt me toch onhandig. Zie je dat je nog 10GB vrij hebt, blijkt dat allemaal ingenomen te zijn door metadata en dan is het probleem weer dat je niet meer kan kopieeren naar een schijf waar nog ruimte is.

Eh, dit gaat niet over free space.

[hostname]

Olaf van der Spek schreef op donderdag 03 september 2009 @ 17:13:
[...]

Eh, dit gaat niet over free space.

Dat snap ik ook nog wel. Maar als je mapsizes exclusief metadata gaat laten zien krijg je ook problemen. Stel: je wilt een backup maken van een map die 987GB (exclusief metadata) groot is naar je externe disk van 1000GB. Je denkt dat dit gaat lukken, maar omdat er ook nog 15GB (voorbeeldje) metadata bij moet gaat het niet passen. Dan krijgen we daar weer topics over.

Als je toch perse de hoeveelheid excl. metadata wilt weten (waarom eigenlijk?), dan zouden ze eigenlijk 2 values neer moeten zetten (zoals Windows het doet): size & size on disk.

[gertvdijk]

Olaf van der Spek schreef op donderdag 03 september 2009 @ 14:08:
Als twee mensen dezelfde fout maken is het toch nog steeds een fout?
Als gebruiker wil ik total data size zien, dat is dus exclusief meta-data.

Dat ligt niet erg voor de hand, dat twee projecten, notabene ls en KDE dezelfde fout maken. Ik zou dan namelijk denken aan een bug in het onderliggende niveau: de filesystem handler. En dat blijkt ook uit commentaar bij het bugreport.

[Verwijderd]

hostname schreef op donderdag 03 september 2009 @ 15:36:
[...]

Lijkt me toch onhandig. Zie je dat je nog 10GB vrij hebt, blijkt dat allemaal ingenomen te zijn door metadata en dan is het probleem weer dat je niet meer kan kopieeren naar een schijf waar nog ruimte is.

Om even op terug te komen. Ik ging er eigenlijk vanuit dat die weergave van ruimte "gewenst" gedrag was. (aangezien ext3 zo oud is verwacht je geen bugs en dat ze dat nog veranderen. Dat deze "fout" erin zit vindt ik dus ronduit eng),
Dus mijn vraag aan Dolphin had oa ook moeten zijn dat ze de data konden weergeven op 2 manieren. De grootte van de bestanden bij elkaar, en de ware grootte hoeveel het inneemt op de schijf (net zoals windows doet). Dit had ik eigenlijk erbij moeten zetten...

Maargoed, ik heb het nu op de manier van "Docey" gedaan en dit werkt perfect

[Olaf van der Spek]

hostname schreef op donderdag 03 september 2009 @ 17:24:
Dat snap ik ook nog wel. Maar als je mapsizes exclusief metadata gaat laten zien krijg je ook problemen. Stel: je wilt een backup maken van een map die 987GB (exclusief metadata) groot is naar je externe disk van 1000GB. Je denkt dat dit gaat lukken, maar omdat er ook nog 15GB (voorbeeldje) metadata bij moet gaat het niet passen. Dan krijgen we daar weer topics over.

De overhead staat niet vast, dus zo'n aanname kun je zoiezo niet doen...
Waarom geen metadata? Omdat de grootte ervan bijvoorbeeld niet vaststaat.

Verwijderd schreef op vrijdag 04 september 2009 @ 13:00:
en de ware grootte hoeveel het inneemt op de schijf (net zoals windows doet). Dit had ik eigenlijk erbij moeten zetten...

Windows toont metadata overhead ook niet, toch? Alleen slack space wordt meegenomen.

[ Voor 26% gewijzigd door Olaf van der Spek op 05-09-2009 11:16 ]

[Recursio]

Wat je zou kunnen doen is:
"krusader" installeren (als je dat nog neit gedaan hebt uiteraard) ->
krusader starten ->
linker panel ene dir kiezen ->
rechter panel andere dir kiezen ->
CTRL + Y (compare directories) ->
"Compare by content" aanvinken ->
start ->
heel veel geduld hebben tot 'ie klaar is

Dit zal je vertellen of de bestanden identiek zijn.

Zo ja, dan is je probleem "iets" met weergave / berekening.
Zo nee: zie de suggesties hierboven.

[ Voor 20% gewijzigd door Recursio op 05-09-2009 11:29 ]