[Darwin] Verschillende file sizes met `du`

[justincase]

code:

10.6.1 Finder: 25.4 MB on disk (25,364,520 bytes)

~local > du -sh dev.zip
 24M    dev.zip

~remote:~$ du -sh dev.zip
17M dev.zip

Local is 10.6.1. De Remote is ubuntu 8.04 LTS. `du` geeft twee erg verschillende sizes aan voor het zelfde bestand. Het verschil tussen de finder en local-du is waarschijnlijk omdat de finder base-10 gebruikt in Snow Leopard. Want op een 10.5.8 machine geeft de finder 24.2MB aan. Ook als ik specifiek dezelfde blocksize gebruikt blijft het verschillend.

code:

~local > export BLOCKSIZE=1048576 # 1 megabyte
~local > du -sm dev.zip
25  dev.zip

~remote:~$ du -s --block-size=1048576
17  dev.zip

Enig idee waar de verschillen vandaan komen? Als ik op de remote machine de output in bytes laat zien dan komt het wél overeen met de finder-bytes.

code:

~remote:~$ du -sb dev.zip
25364520    dev.zip

Is er een manier om op beide machine de zelfde output te krijgen?

[ Voor 1% gewijzigd door justincase op 27-10-2009 12:02 . Reden: filenames ]

[Daedalus]

Dit hoort in Apple Software & Diensten en niet in Apple Computers, dus een move die kant op

ACS > ASD

[justincase]

Oops! Al een tijdje niet langs geweest, was me niet opgevallen dat APL opgesplits was. Excuse!

[0fbe]

Het verschil komt omdat OS X 10.6 (SL) een megabit als 10^6 bytes ziet en OS X 10.5 en Ubuntu als 2^20 bytes. Alhoewel dat alleen een verschil van +/- 5 procent op MegaByte niveau zou verklaren en niet de +10% die jij ziet...

[ Voor 34% gewijzigd door 0fbe op 27-10-2009 12:11 ]

[justincase]

Zowel 10.6.1 als 10.5.8 geven 24M aan, dat zou het dan niet kunnen zijn. De base-10 verandering heeft (volgens mij) alleen betrekking op de GUI.

[Soultaker]

Wat is "remote" precies? Een andere host waarop je het eerste filesystem gemount hebt? Of heb je gewoon een kopie van 't bestand gemaakt?

In principe kan de bestandsgrootte van du afwijken van het aantal bytes in het bestand, omdat du probeert de daadwerkelijk gebruikte ruimte te schatten. Daarbij wordt (naar boven) afgerond op filesystem blocks, ongealloceerde delen van sparse files worden niet meegeteld, en zo nog wat dingen.

Meestal is de grootte die du rapporteert daardoor iets hoger dan de werkelijke grootte van het bestand (zoals b.v. door ls -l of wc -c of du -b gerapporteerd worden). Het lijkt me niet dat een zip file sparse is (of er is iets misgegaan bij het kopiëren). Als je een remote filesystem gebruikt (NFS ofzo) gaat er misschien iets mis bij het interpreteren van de blocksize, maar ook dat is niet heel plausibel aangezien dat meestal machten van twee zijn, dus zou ik verwachten dat de een twee keer zo groot of twee keer zo klein aantal bytes gerapporteert zou worden, en niet iets wat er een beetje tussenin lijkt te zitten...

Als ik moet gokken, ben ik toch geneigd te denken dat het bestand niet goed gekopieerd is. Kun je dat eens controleren?

[ Voor 5% gewijzigd door Soultaker op 27-10-2009 12:46 ]

[dawuss]

Vermeld inderdaad eens welke filesystems local en remote zijn. Als één van de twee bijvoorbeeld een FAT formatted USB stick is en de ander ext2, kan dat nogal uit maken.

[Digistorm]

Kan het er ook niet mee te maken hebben dat het andere OS de resource-fork negeert en alleen naar de data-fork kijkt?

[justincase]

Soultaker schreef op dinsdag 27 oktober 2009 @ 12:41:
Wat is "remote" precies? Een andere host waarop je het eerste filesystem gemount hebt? Of heb je gewoon een kopie van 't bestand gemaakt?

SSH naar een VPS. FS is ext3.

In principe kan de bestandsgrootte van du afwijken van het aantal bytes in het bestand, omdat du probeert de daadwerkelijk gebruikte ruimte te schatten. Daarbij wordt (naar boven) afgerond op filesystem blocks, ongealloceerde delen van sparse files worden niet meegeteld, en zo nog wat dingen.

Dat had ik me inderdaad bedacht. (du -- display disk usage statistics)

Meestal is de grootte die du rapporteert daardoor iets hoger dan de werkelijke grootte van het bestand (zoals b.v. door ls -l of wc -c of du -b gerapporteerd worden). Het lijkt me niet dat een zip file sparse is (of er is iets misgegaan bij het kopiëren). Als je een remote filesystem gebruikt (NFS ofzo) gaat er misschien iets mis bij het interpreteren van de blocksize, maar ook dat is niet heel plausibel aangezien dat meestal machten van twee zijn, dus zou ik verwachten dat de een twee keer zo groot of twee keer zo klein aantal bytes gerapporteert zou worden, en niet iets wat er een beetje tussenin lijkt te zitten...

Als ik moet gokken, ben ik toch geneigd te denken dat het bestand niet goed gekopieerd is. Kun je dat eens controleren?

De zip was inderdaad corrupt. Na scp:

code:

~local > du -sh dev.zip
 24M    dev.zip

~local > du -sm dev.zip #MB blocks
 25M    dev.zip

~remote:~$ du -sh dev.zip
25M dev.zip

Dit bestand was alleen om het even te testen though (fail). Reden waarom ik me dit afvroeg is het volgende. Ik doe een rsync:

code:

#!/bin/sh

date=`date "+%Y-%m-%d-%H%M%S-T"`
HOME=/Users/justin/dev

rsync -azh \
  --stats \
  --delete \
  --delete-excluded \
  --exclude-from=$HOME/.rsync/exclude \
  --link-dest=/Users/justin/Backups/current \
  $HOME /Users/justin/Backups/incomplete_backup-$date 

mv /Users/justin/Backups/incomplete_backup-$date /Users/justin/Backups/backup-$date
rm -f /Users/justin/Backups/current
ln -s /Users/justin/Backups/backup-$date /Users/justin/Backups/current

Als ik dit script bijv. 4 keer draai (zonder iets te veranderen in dev/) eindig ik met de volgende backup:

code:

~local > du -sh *
183M backup-2009-10-27-101123
24k  backup-2009-10-27-101123
24k  backup-2009-10-27-101123
24k  backup-2009-10-27-101123

Dat klopt allemaal. De increments zijn hardlinks naar de 183M dir. Doe ik het zelfde naar de VPS krijg ik:

code:

~remote > du -sh *
198M backup-2009-10-27-101123
15M  backup-2009-10-27-101123
15M  backup-2009-10-27-101123
15M  backup-2009-10-27-101123

Rsync geeft aan 0 files getransferred te hebben na de eerste run. Ik zag dat één van de dir's in de backup local 56KB is en remote 72KB. Met 10000 files kan daar het verschil in zitten. Maar dat verklaart niet waarom de increment dir's 15MB zijn, dat zouden gewoon hardlinks naar de eerste dir moeten zijn?

[Soultaker]

Volgens mij klopt je verhaal nog niet helemaal.

1. Ik neem aan dat je eigenlijk vier verschillende bestandsnamen hebt en niet vier keer dezelfde?
2. Je kunt directories niet hard-linken, alleen symlinken. (Bestanden kunnen wel gehardlinkt worden, daar is die --link-dest optie van rsync voor.) Je directorystructuur moet dus altijd opnieuw gemaakt worden.
3. Je hebt het over transfers met rsync, maar je hebt alleen de scriptcode laten zien voor het maken van je lokale backup; daar komt geen file transfer bij kijken. Laat ook eens zien wat voor rsync-commando je gebruikt om je files tussen lokaal en remote te synchroniseren?

Om te verklaren waarom de incremental directories zoveel groter zijn zou je er eens in moeten kijken. Als ik het goed begrijp wordt je hele bestands- en directorystructuur gerepliceert. Elke directory kost sowieso al een filesystem block (meestal 4KB of 8KB) dus als ongeveer een derde van de 10,000 files directories zijn kom je er al op.

edit:
Trouwens, het schijnt dat Mac OS X wel directories kan hardlinken. Als rsync dat ook doet, zou dat kunnen verklaren waarom die directories zoveel kleiner zijn op de Mac.

[ Voor 14% gewijzigd door Soultaker op 27-10-2009 14:57 ]

[justincase]

@Soultaker

1) True. Copy/Paste fail.

edit:
Trouwens, het schijnt dat Mac OS X wel directories kan hardlinken. Als rsync dat ook doet, zou dat kunnen verklaren waarom die directories zoveel kleiner zijn op de Mac.

2) Ah. Daar heb je een punt. Op de VPS gebeurd het in ieder geval niet. ls -li geeft verschillende inodes voor de zelfde directories. Zal eens kijk wat het local aangeeft. Het zijn in iedergeval ongeveer 3000 dir's

3) Script naar VPS toe is hetzelfde alleen dan met andere destination

code:

#!/bin/sh

date=`date "+%Y-%m-%d-%H%M%S"`
HOME=/Users/justin/dev

rsync -azh \
  --progress \
  --stats \
  --delete \
  --delete-excluded \
  --exclude-from=$HOME/.rsync/exclude \
  --link-dest=../current \
  $HOME remote:Backups/incomplete_backup-$date \
  && ssh remote \
  "mv Backups/incomplete_backup-$date Backups/backup-$date \
  && rm -f Backups/current \
  && ln -s backup-$date Backups/current"

[Soultaker]

Oh, --link-dest werkt ook remote? Interessant, dat wist ik niet. Ik had verwacht dat je je backups lokaal maakte en daarna syncte met remote (zodat je ook een offsite backup hebt). Dit is wel handig om te onthouden.

justincase schreef op dinsdag 27 oktober 2009 @ 17:45:
Op de VPS gebeurd het in ieder geval niet. ls -li geeft verschillende inodes voor de zelfde directories. Zal eens kijk wat het local aangeeft. Het zijn in iedergeval ongeveer 3000 dir's

Dat verklaart het ongeveer: 3000 directories keer 4096 byte blocks is al bijna 12 MB. Hard links zijn bijna gratis, behalve als je veel bestanden in één directory hebt; dan heb je per ~100 bestanden ofzo een extra block nodig. Dat zou de overige 3MB kunnnen verklaren. (Elke hard link kost immers nog wel een directory entry.)

Hoe het op de Mac zit moet je dan nog even zelf bekijken, maar waarschijnlijk worden dan directories wel gehardlinkt of du meet gewoon anders op de Mac. De incrementele back-ups kunnen onder Linux in ieder geval niet veel kleiner (of je moet ze tarren en gzippen/xzippen remote, dat scheelt natuurlijk wel een stuk).