Snelse manier van bestanden copieren?

[houghi]

Ik ben net klaar met de herindeling van mijn partities. Zowel wat
samenvoegen van partities als verplaatsen en ook hernoemen. Ik ben er
net klaar mee en bedacht ineens dat het nogal een tijd duurde voor ik
veel bestanden (Iets over de TB) van de ene partitie/HD naar de andere
verplaatst had. En natuurlijk weer terug.

Oude bestanden kunnen blijven staan, aangezien de partitie toch
geherformateerd wordt. Bij het terugzetten teld de tijd van het
terugzetten, dus niet van het verwijderen van de bestanden. Een rm kan
achteraf gedaan worden.

Wat zou de snelste manier geweest zijn?
1) Gewoon een mv
2) Een cp
3) tar en dan mv
4) ...

En enig idee hoeveel verschil dat zou uitmaken? Niet zozeer in tijd,
maar in %.

houghi

[John Bokma]

Post by houghi
Ik ben net klaar met de herindeling van mijn partities. Zowel wat
samenvoegen van partities als verplaatsen en ook hernoemen. Ik ben er
net klaar mee en bedacht ineens dat het nogal een tijd duurde voor ik
veel bestanden (Iets over de TB) van de ene partitie/HD naar de andere
verplaatst had. En natuurlijk weer terug.
Oude bestanden kunnen blijven staan, aangezien de partitie toch
geherformateerd wordt. Bij het terugzetten teld de tijd van het
terugzetten, dus niet van het verwijderen van de bestanden. Een rm kan
achteraf gedaan worden.
Wat zou de snelste manier geweest zijn?
1) Gewoon een mv
2) Een cp
3) tar en dan mv
4) ...

ikzelf zou rsync -avh gebruiken. Het zal vast niet sneller zijn, maar
neemt ook de meest belangrijke eigenschappen over (gid, uid, tijden,
enz.). Evt. --delete om bestanden die er niet (meer) horen ook te wissen.

Ik maak zo een kopie van mijn /home naar een externe USB disk. De 1e
keer duurde het even, maar nu er niet veel bijkomt (of weggaat), is een
kopie zo gemaakt.

[Paul van der Vlis]

Post by John Bokma

Post by houghi
Ik ben net klaar met de herindeling van mijn partities. Zowel wat
samenvoegen van partities als verplaatsen en ook hernoemen. Ik ben er
net klaar mee en bedacht ineens dat het nogal een tijd duurde voor ik
veel bestanden (Iets over de TB) van de ene partitie/HD naar de andere
verplaatst had. En natuurlijk weer terug.
Oude bestanden kunnen blijven staan, aangezien de partitie toch
geherformateerd wordt. Bij het terugzetten teld de tijd van het
terugzetten, dus niet van het verwijderen van de bestanden. Een rm kan
achteraf gedaan worden.
Wat zou de snelste manier geweest zijn?
1) Gewoon een mv
2) Een cp
3) tar en dan mv
4) ...

ikzelf zou rsync -avh gebruiken. Het zal vast niet sneller zijn, maar
neemt ook de meest belangrijke eigenschappen over (gid, uid, tijden,
enz.). Evt. --delete om bestanden die er niet (meer) horen ook te wissen.

Ik zou ook rsync gebruiken en heb nog een argument: rsync kun je stoppen
en weer starten en dat is handig.

Tijdens het kopieren zie ik b.v. soms grote bestanden of directories
voorbij komen waarvan ik denk: die wil ik excluden want die oude zooi
hoeft niet. Dan kan je stoppen en excluden met rsync. Denk dan evt. aan
"--delete-excluded" in het commando om resten op te ruimen.

Overigens rsync ik vaak eerst lokaal en dan via internet naar een andere
locatie. Raar maar waar: dat laatste is vaak sneller. Lokaal is rsync
niet erg snel. Maar toch gebruik ik het.

Met vriendelijke groet,
Paul van der Vlis.

[houghi]

Post by Paul van der Vlis
Ik zou ook rsync gebruiken en heb nog een argument: rsync kun je stoppen
en weer starten en dat is handig.

Niet van toepassing in mijn situatie. Het was een eenmalig kopieren van
bestanden naar een tijdelijke opslagplaats en dan nog een keer.

Post by Paul van der Vlis
Tijdens het kopieren zie ik b.v. soms grote bestanden of directories
voorbij komen waarvan ik denk: die wil ik excluden want die oude zooi
hoeft niet. Dan kan je stoppen en excluden met rsync. Denk dan evt. aan
"--delete-excluded" in het commando om resten op te ruimen.

Zeker niet van toepassing, aangezien ik alles weer terug wilde hebben
zoals het was, Inclusief all Cache bestanden en wat al niet.

Post by Paul van der Vlis
Overigens rsync ik vaak eerst lokaal en dan via internet naar een andere
locatie. Raar maar waar: dat laatste is vaak sneller. Lokaal is rsync
niet erg snel. Maar toch gebruik ik het.

Als het niet snel is, dan zou het hoe dan ook afvallen.

Zou er een verschil zijn tussen een mv en een cp?

houghi

[Paul van der Vlis]

Post by houghi

Post by Paul van der Vlis
Ik zou ook rsync gebruiken en heb nog een argument: rsync kun je stoppen
en weer starten en dat is handig.

Niet van toepassing in mijn situatie. Het was een eenmalig kopieren van
bestanden naar een tijdelijke opslagplaats en dan nog een keer.

Post by Paul van der Vlis
Tijdens het kopieren zie ik b.v. soms grote bestanden of directories
voorbij komen waarvan ik denk: die wil ik excluden want die oude zooi
hoeft niet. Dan kan je stoppen en excluden met rsync. Denk dan evt. aan
"--delete-excluded" in het commando om resten op te ruimen.

Zeker niet van toepassing, aangezien ik alles weer terug wilde hebben
zoals het was, Inclusief all Cache bestanden en wat al niet.

Bij mij komt het toch vaak voor dat ik het vervloek als ik weer eens cp
heb gebruikt bij grote kopien...

Post by houghi

Post by Paul van der Vlis
Overigens rsync ik vaak eerst lokaal en dan via internet naar een andere
locatie. Raar maar waar: dat laatste is vaak sneller. Lokaal is rsync
niet erg snel. Maar toch gebruik ik het.

Als het niet snel is, dan zou het hoe dan ook afvallen.
Zou er een verschil zijn tussen een mv en een cp?

Uiteraard wel op dezelfde partitie, daar is mv bloedsnel ;-)

Naar een andere partitie veranderd een mv in een cp en daarna rm.
Misschien dat die rm extra tijd kost en dat mv dus trager is.

Met vriendelijke groet,
Paul van der Vlis.

[houghi]

Post by Paul van der Vlis

Post by houghi
Zou er een verschil zijn tussen een mv en een cp?

Uiteraard wel op dezelfde partitie, daar is mv bloedsnel ;-)

Dat weet ik, vandaar dat ik het er bij vermelde. :-D

Post by Paul van der Vlis
Naar een andere partitie veranderd een mv in een cp en daarna rm.
Misschien dat die rm extra tijd kost en dat mv dus trager is.

OK, da's interessant om te weten. In mijn geval was het beste dus een
copy te doen, formateren en herinrichten van de partities en weer een
copy terug.

houghi

[unknown]

Post by Paul van der Vlis
Uiteraard wel op dezelfde partitie, daar is mv bloedsnel ;-)

Precieser: zelfde filesystem. En eerlijk gezegd weet ik niet of dat voor
alle filesystems geldt.

Bart

[Burg]

Post by unknown
Precieser: zelfde filesystem. En eerlijk gezegd weet ik niet of dat voor
alle filesystems geldt.

Zelfde partitie. FS is (relatief) irrelevant. Copy op een zelfde partitie is
inderdaad snel. Je verwisselt enkel inodes op dezelfde partitie. Millisecondes.

Ik gebruik ReiserFS trouwens ;-) Is die Duitser trouwens nu inmiddels voor
altijd en voor het hiernamaals opgesloten? Mocht hij het gedaan hebben
natuurlijk.

[Paul van der Vlis]

Post by Burg

Post by unknown
Precieser: zelfde filesystem. En eerlijk gezegd weet ik niet of dat voor
alle filesystems geldt.

Zelfde partitie. FS is (relatief) irrelevant. Copy op een zelfde partitie is
inderdaad snel. Je verwisselt enkel inodes op dezelfde partitie. Millisecondes.
Ik gebruik ReiserFS trouwens ;-) Is die Duitser trouwens nu inmiddels voor
altijd en voor het hiernamaals opgesloten? Mocht hij het gedaan hebben
natuurlijk.

Ja, hij heeft uiteindelijk bekend, en ik heb niets gelezen over twijfels
daarover.

Met vriendelijke groet,
Paul van der Vlis.

[Den Voldere]

Hoi,

Post by John Bokma
ikzelf zou rsync -avh gebruiken. Het zal vast niet sneller zijn, maar
neemt ook de meest belangrijke eigenschappen over (gid, uid, tijden,
enz.). Evt. --delete om bestanden die er niet (meer) horen ook te wissen.

/me mompelt iets over --sparse

Robert

[Dick Streefland]

John Bokma <***@castleamber.com> wrote:
| ikzelf zou rsync -avh gebruiken. Het zal vast niet sneller zijn, maar
| neemt ook de meest belangrijke eigenschappen over (gid, uid, tijden,
| enz.). Evt. --delete om bestanden die er niet (meer) horen ook te wissen.

Met rsync -aHSi behoud je ook hard-links en sparse files.

[Martijn van Buul]

Post by houghi
Wat zou de snelste manier geweest zijn?
1) Gewoon een mv
2) Een cp
3) tar en dan mv
4) ...

Ik denk dat tenzij je rare dingen gaat doen het geen donder uit zal maken. Op
een beetje moderne machine is het toch allemaal IO-bound; je disks vormen
waarschijnlijk de beperking.

Persoonlijk zou ik een

tar cf - /source/dir | (cd /target; tar xvpf -)

doen, maar da's meer (slechte ?) gewoonte dan iets anders. Zie vooral ook het
antwoord van John Bokma.

Een en ander gaat natuurlijk niet op als je de tar niet via een pipe laat
lopen.

[Martijn van Buul]

Post by Martijn van Buul

Post by houghi
Wat zou de snelste manier geweest zijn?
1) Gewoon een mv
2) Een cp
3) tar en dan mv
4) ...

Ik denk dat tenzij je rare dingen gaat doen het geen donder uit zal maken. Op
een beetje moderne machine is het toch allemaal IO-bound; je disks vormen
waarschijnlijk de beperking.
Persoonlijk zou ik een
tar cf - /source/dir | (cd /target; tar xvpf -)
doen, maar da's meer (slechte ?) gewoonte dan iets anders. Zie vooral ook het
antwoord van John Bokma.

Oeps, even vergeten dat niet iedereen een zinnige versie van tar gebruikt...

GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

tar cSf - /source/dir | (cd /target; tar xvpf -)

Opvallend genoeg moet dat onder FreeBSD opeens anders; daar moet de -S aan
de *uitpakkende* tar gevoerd worden, terwijl het onder NetBSD niet boeit
aangezien die toch meteen The Right Thing doet, en mijn oorspronkelijke
vloek het meteen goed zou doen. Opvallend.

Overigens: Ook rsync moet je expliciet vragen om sparse files te snappen.

Martijn

[1] Zo zie je maar weer: GNU is Not Usefull :P

[Rob]

Post by Martijn van Buul
GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

Zijn er nog mensen/programma's die dat gebruiken?

[Philip Paeps]

Post by Rob

Post by Martijn van Buul
GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

Zijn er nog mensen/programma's die dat gebruiken?

Ja.

Denk aan filesystem images voor embedded development of (nog meer hip dezer
dagen) virtual machines. Er zijn ook nog steeds applicaties die record-based
data sparse opslaan.

Vanwaar het idee dat ze niet meer gebruikt zouden worden?

- Philip

[Rob]

Post by Philip Paeps

Post by Rob

Post by Martijn van Buul
GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

Zijn er nog mensen/programma's die dat gebruiken?

Ja.
Denk aan filesystem images voor embedded development of (nog meer hip dezer
dagen) virtual machines. Er zijn ook nog steeds applicaties die record-based
data sparse opslaan.

Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme
voor het sparse opslaan van disk images in. Daar worden dus geen sparse
files voor gebruikt.

Ik weet nog wel "van vroeger" dat ik wel eens truukjes gebruikte (ik
dacht met een optie van cp) om de hele disk langs te lopen en alle files
zo sparse mogelijk te maken, en dan weer verrukt was als dit een paar
honderd kB had opgeleverd.

Maar tegenwoordig is diskspace zo goedkoop dat niemand meer maalt om een
paar blokjes met nullen, en sparse files hebben ook nadelen.
(zoals fragmentatie)

Noem eens zo'n applicatie die record-based data sparse opslaat.
Ik weet dat het in theorie kan en dat er ooit wel eens wat mee gedaan
is maar dit gaf altijd een hoop ellende als nietsvermoedende gebruikers
de data probeerden over te zetten enzo. Volgens mij is iedereen daar nu
wel mee gestopt.

[Martijn van Buul]

Post by Rob
Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme
voor het sparse opslaan van disk images in. Daar worden dus geen sparse
files voor gebruikt.

En omdat jij vmware gebruikt doet iedereen dat ook? Virtualbox gebruikt
bij voorbeeld *zeer zeker* sparse files, dito voor qemu.

Post by Rob
Maar tegenwoordig is diskspace zo goedkoop dat niemand meer maalt om een
paar blokjes met nullen, en sparse files hebben ook nadelen.
(zoals fragmentatie)

Waarom gebruik je dan vmware's 'mechanisme voor het sparse opslaan van disk
images' ? Erg consequent ben je niet.

[Rob]

Post by Martijn van Buul

Post by Rob
Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme
voor het sparse opslaan van disk images in. Daar worden dus geen sparse
files voor gebruikt.

En omdat jij vmware gebruikt doet iedereen dat ook? Virtualbox gebruikt
bij voorbeeld *zeer zeker* sparse files, dito voor qemu.

Sorry ik was vergeten te zeggen dat het een voorbeeld wa.

Post by Martijn van Buul

Post by Rob
Maar tegenwoordig is diskspace zo goedkoop dat niemand meer maalt om een
paar blokjes met nullen, en sparse files hebben ook nadelen.
(zoals fragmentatie)

Waarom gebruik je dan vmware's 'mechanisme voor het sparse opslaan van disk
images' ? Erg consequent ben je niet.

Nee gebruik ik niet, ik gebruik pre-allocated files, ik gaf alleen aan
dat het er in zit.

[Kees Nuyt]

On Wed, 5 May 2010 09:43:48 +0000 (UTC), Martijn van Buul

Post by Martijn van Buul

Post by Rob
Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme
voor het sparse opslaan van disk images in. Daar worden dus geen sparse
files voor gebruikt.

En omdat jij vmware gebruikt doet iedereen dat ook? Virtualbox gebruikt
bij voorbeeld *zeer zeker* sparse files, dito voor qemu.

qemu: zou best kunnen, da's voor mij lang geleden.
VirtualBox: nee.

Het VirtualBox dynamische .vdi formaat lijkt sparse maar is dat
niet. De file breidt gewoon sequentieel uit. Direct na de
fileheader staat een blokadministratie waarin wordt bijgehouden
op welke fileoffset elk blok in het virtuele device is
gealloceerd.
Omdat de blocksize vrij groot is gekozen is de omvang van die
mappingtabel redelijk beperkt.

Omdat de grootte van de mappingtabel bij het aanmaken van de .vdi
wordt vastgesteld kan een dynamische .vdi niet groeien boven het
vooringestelde maximum. Met een sparse file zou dat wel kunnen.

Best regards,
--
( Kees Nuyt
)
c[_]

[Rob]

Post by Kees Nuyt
On Wed, 5 May 2010 09:43:48 +0000 (UTC), Martijn van Buul

Post by Martijn van Buul

Post by Rob
Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme
voor het sparse opslaan van disk images in. Daar worden dus geen sparse
files voor gebruikt.

En omdat jij vmware gebruikt doet iedereen dat ook? Virtualbox gebruikt
bij voorbeeld *zeer zeker* sparse files, dito voor qemu.

qemu: zou best kunnen, da's voor mij lang geleden.
VirtualBox: nee.
Het VirtualBox dynamische .vdi formaat lijkt sparse maar is dat
niet. De file breidt gewoon sequentieel uit. Direct na de
fileheader staat een blokadministratie waarin wordt bijgehouden
op welke fileoffset elk blok in het virtuele device is
gealloceerd.
Omdat de blocksize vrij groot is gekozen is de omvang van die
mappingtabel redelijk beperkt.

Dit is wat ik bedoel met een in de applicatie geimplementeerde sparse
file. Dit is wat VMware ook doet.
Het heeft dezelfde functionaliteit als een sparse file (een grote file
waarin niet alle blokken in gebruik zijn en die dan ook evenredig minder
ruimte op de disk inneemt) maar dan zonder te vertrouwen op de OS
implementatie van sparse files, en zonder het nadeel dat de file ineens
veel ruimte gaat innemen als ie onoordeelkundig gecopieerd wordt.

Omdat dit soort software tegenwoordig ook onder Windows moet kunnen draaien
denk ik niet dat je nog veel applicaties tegenkomt die Unix-style sparse
files gebruiken.

Puristen roepen wel "ja maar ze moeten er zijn hoor, volgens mij heeft
een kennis van mijn zwager er nog ergens een op de server". Maar concrete
voorbeelden noemen dat is te lastig.

[Martijn van Buul]

Post by Rob
Puristen roepen wel "ja maar ze moeten er zijn hoor, volgens mij heeft
een kennis van mijn zwager er nog ergens een op de server". Maar concrete
voorbeelden noemen dat is te lastig.

En dat is een reden om er geen rekening mee te houden? ik snap jouw probleem
niet.

[Rob]

Post by Martijn van Buul

Post by Rob
Puristen roepen wel "ja maar ze moeten er zijn hoor, volgens mij heeft
een kennis van mijn zwager er nog ergens een op de server". Maar concrete
voorbeelden noemen dat is te lastig.

En dat is een reden om er geen rekening mee te houden? ik snap jouw probleem
niet.

Nee het is een reden om aan te nemen dat de hele issue rondom sparse files
helemaal niet speelt bij het copieren van een disk.

Dan kan ik ook wel beginnen over hard links. Ik gebruik die zelf nog wel
eens dus als ik iets copieer dan let ik altijd even op dat ik de hard links
ongeschonden mee neem. Maar dat was in deze thread nog niet genoemd dus
ik neem aan dat anderen hier geen gebruik (meer) van maken en dus geen
rekening meer mee hoeven te houden.

[Fred Mobach]

Post by Rob

Post by Martijn van Buul

Post by Rob
Puristen roepen wel "ja maar ze moeten er zijn hoor, volgens mij heeft
een kennis van mijn zwager er nog ergens een op de server". Maar
concrete voorbeelden noemen dat is te lastig.

En dat is een reden om er geen rekening mee te houden? ik snap jouw
probleem niet.

Nee het is een reden om aan te nemen dat de hele issue rondom sparse
files helemaal niet speelt bij het copieren van een disk.
Dan kan ik ook wel beginnen over hard links. Ik gebruik die zelf nog
wel eens dus als ik iets copieer dan let ik altijd even op dat ik de
hard links
ongeschonden mee neem. Maar dat was in deze thread nog niet genoemd
dus ik neem aan dat anderen hier geen gebruik (meer) van maken en dus
geen rekening meer mee hoeven te houden.

En of ik nogal vaak hardlinks gebruik. Da's reuze handig als je backups
wilt maken van een aantal redelijk identieke machines :
1. cp -al <source> <target>
2. rsync -avz -e 'ssh -P' --delete-after --exclude-from=<file> <host>:/
<target>

[unknown]

Post by Fred Mobach
En of ik nogal vaak hardlinks gebruik. Da's reuze handig als je backups
1. cp -al <source> <target>
2. rsync -avz -e 'ssh -P' --delete-after --exclude-from=<file> <host>:/
<target>

Dito. Mijn backup script gebruikt het, om in de ruimte van 1 (plus een
beetje) backup tot twee weken of meer op te slaan. Zeg maar full backup
met een differential backup. Of zoiets.

Bart

[Dick Streefland]

Bart Friederichs <"bart apestaartje friesoft punt nl"> wrote:
| > En of ik nogal vaak hardlinks gebruik. Da's reuze handig als je backups
| > wilt maken van een aantal redelijk identieke machines :
| > 1. cp -al <source> <target>
| > 2. rsync -avz -e 'ssh -P' --delete-after --exclude-from=<file> <host>:/
| > <target>
|
| Dito. Mijn backup script gebruikt het, om in de ruimte van 1 (plus een
| beetje) backup tot twee weken of meer op te slaan. Zeg maar full backup
| met een differential backup. Of zoiets.

Het kan ook zonder die "cp -al", met de --link-dest optie van rsync.

[Philip Paeps]

Post by Philip Paeps

Post by Rob

Post by Martijn van Buul
GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

Zijn er nog mensen/programma's die dat gebruiken?

Ja.
Denk aan filesystem images voor embedded development of (nog meer hip dezer
dagen) virtual machines. Er zijn ook nog steeds applicaties die
record-based data sparse opslaan.

Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme voor
het sparse opslaan van disk images in.

-EPARSE
Deze zin is geen Nederlands.

Daar worden dus geen sparse files voor gebruikt.

Dus toch sparse files?

Ik weet nog wel "van vroeger" dat ik wel eens truukjes gebruikte (ik dacht
met een optie van cp) om de hele disk langs te lopen en alle files zo sparse
mogelijk te maken, en dan weer verrukt was als dit een paar honderd kB had
opgeleverd.
Maar tegenwoordig is diskspace zo goedkoop dat niemand meer maalt om een
paar blokjes met nullen, en sparse files hebben ook nadelen. (zoals
fragmentatie)

Fragmentatie is inderdaad een probleem met sparse files. Soms zijn ze echter
de eenvoudigste manier om iets te regelen. Voor disk images zijn ze uiterst
geschikt.

Noem eens zo'n applicatie die record-based data sparse opslaat. Ik weet dat
het in theorie kan en dat er ooit wel eens wat mee gedaan is maar dit gaf
altijd een hoop ellende als nietsvermoedende gebruikers de data probeerden
over te zetten enzo. Volgens mij is iedereen daar nu wel mee gestopt.

Je hebt inderdaad een punt dat, gezien de toenemende capaciteit van storage
media, nieuwe software vaak gewoon nullen schrijft in plaats van met sparse
files te werken. Echter wordt software die geschreven is toch sparse files
de beste oplossing waren niet gewoon herschreven omdat disks groter worden.
Er zijn verschillende database applicaties en applicaties met eigen interne
formaten die al jaren meegaan en sparse files gebruiken. Ik kan niet meteen
op een open source voorbeeld komen, maar tussen mijn klanten zit er wel een
aantal.

- Philip

[John Bokma]

Post by Philip Paeps

Post by Philip Paeps

Post by Rob

Post by Martijn van Buul
GNU tar moet je expliciet vragen om sparse files te bouwen. Mocht je
sparse files verwachten, gebruik dan vooral

Zijn er nog mensen/programma's die dat gebruiken?

Ja.
Denk aan filesystem images voor embedded development of (nog meer hip dezer
dagen) virtual machines. Er zijn ook nog steeds applicaties die
record-based data sparse opslaan.

Ik gebruik zelf vmware voor virtual machines en daar al het mechanisme voor
het sparse opslaan van disk images in.

-EPARSE
Deze zin is geen Nederlands.

Daar worden dus geen sparse files voor gebruikt.

Dus toch sparse files?

Wellicht bedoelt Rob: niet op OS nivo. Ik gebruik VirtualBox, en ik
gebruik ook groeiende partities (IIRC), en rsync zonder --sparse neemt
die gewoon over.

Dus mijn voorzichtige conclusie is dat VB sparse files gebruikt, maar
via een eigen systeem, waar het OS geen weet van heeft.

Aanvullend: Ik heb gisteren even een test gedaan van sata > usb WD passport
drive (320G Elite? Die met 5 jaar ipv 3 jaar garantie), en dat gaf:

13.49 M bytes/s

1 TB zal dus +/- 20.5 uur duren als dit te extrapoleren is.

Als ik zou moeten gokken denk ik dat cp + achteraf rm sneller is dan mv.

OP kan alle 4 de mogelijkheden testen :-) (cp, mv, tar | (Martijn/Fred),
rsync) en de tijden melden.

[Martijn van Buul]

Post by John Bokma
Aanvullend: Ik heb gisteren even een test gedaan van sata > usb WD passport
13.49 M bytes/s

Het is misschien interessant om te weten of dit een collectie van (relatief)
kleine bestanden was, of juist een beperkte hoeveelheid grote bestanden, en
aan wat voor USB controller je het hebt gehangen.

Voor een USB disk is het niet bijzonder snel - maar van de andere kant heb ik
geen enkele USB disk in mijn collectie die echt boven de 25 MB/s uitschiet,
terwijl dezelfde disk aan een normale SATA (of zelfs IDE) poort het vaak
beduidend beter doet.

Post by John Bokma
1 TB zal dus +/- 20.5 uur duren als dit te extrapoleren is.

Yup. Niet 1TB naar een USB disk willen pompen is de oplossing; als ik
dergelijke kopieeracties moet doen peuter ik als het een beetje kan die
disk uit zijn USB enclosure. (Ik heb dan ook een voorliefde voor enclosures
waarbij dat gemakkelijk kan..)

Post by John Bokma
Als ik zou moeten gokken denk ik dat cp + achteraf rm sneller is dan mv.

Ik veracht echt dat het verschil geneuzel in de marge is. Het enige wat je
daarmee bereikt is dat de unlink (van zowel rm als mv) wordt uitgesteld.
Aangezien je op twee fysieke disks bezig bent zie ik niet hoe dat tot
een groot verschil kan leiden. De hoeveelheid data die verplaatst moet worden
is immers in alle gevallen gelijk.

[John Bokma]

Post by Martijn van Buul

Post by John Bokma
Aanvullend: Ik heb gisteren even een test gedaan van sata > usb WD passport
13.49 M bytes/s

Het is misschien interessant om te weten of dit een collectie van (relatief)
kleine bestanden was, of juist een beperkte hoeveelheid grote
bestanden, en

Het was een mix. Ik weet niet de exacte verhouding, maar dingen die
meegaan zijn mijn Chrome en Firefox cache, Pidgin logs (vnl. klein
spul), subversion (vnl klein, gok ik), bestanden in de 1 MB - 5 MB
range, bestanden in de 700 - 2G range, en als ik VirtualBox heb gebruikt
kan er ook een of twee vdis mee gaan, 2G+ (was 1 vdi deze keer). Ik kan
mij niet herinneren hoeveel G er in totaal overgezet was, zal ik de
volgende keer ook overnemen.

Post by Martijn van Buul
aan wat voor USB controller je het hebt gehangen.

USB2 via Dell monitor -> computer. De disk is een WDC WD3200BEVS-00VAT0
(ext3). Terzijde: ik ben erg te spreken over WD passport (ik heb er 2),
met de kanttekening dat dit de enige externe HDs zijn waar ik ervaring
mee heb.

Post by Martijn van Buul
Voor een USB disk is het niet bijzonder snel - maar van de andere kant heb ik
geen enkele USB disk in mijn collectie die echt boven de 25 MB/s uitschiet,
terwijl dezelfde disk aan een normale SATA (of zelfs IDE) poort het vaak
beduidend beter doet.

Als ik direct naar disk kopieer via de desktop haal ik inderdaad meer,
meestal 20+ M/s. Ik kan mij voorstellen dat rsync nogal wat tijd
"verliest" aan het controleren van alle bestanden in /home met wat op
disk staat (+/- 200G aan data totaal)

Post by Martijn van Buul

Post by John Bokma
1 TB zal dus +/- 20.5 uur duren als dit te extrapoleren is.

Yup. Niet 1TB naar een USB disk willen pompen is de oplossing;

Ja, of zoiets starten op zondagochtend, zodat het maandag klaar is.

Post by Martijn van Buul
als ik dergelijke kopieeracties moet doen peuter ik als het een beetje
kan die disk uit zijn USB enclosure. (Ik heb dan ook een voorliefde
voor enclosures waarbij dat gemakkelijk kan..)

Kan ik mij goed iets bij voorstellen, maar dat lijkt niet eenvoudig bij
die WD passports, zeker niet die met 5 jaar garantie.

Post by Martijn van Buul

Post by John Bokma
Als ik zou moeten gokken denk ik dat cp + achteraf rm sneller is dan mv.

Ik veracht echt dat het verschil geneuzel in de marge is. Het enige wat je
daarmee bereikt is dat de unlink (van zowel rm als mv) wordt
uitgesteld.

Klopt. Ik kan mij voorstellen dat het bij heel veel bestanden best een
verschil kan maken, maar bij het totaal van 1TB data zal dat wellicht
verwaarloosbaar zijn.

Post by Martijn van Buul
Aangezien je op twee fysieke disks bezig bent zie ik niet hoe dat tot
een groot verschil kan leiden. De hoeveelheid data die verplaatst moet
worden is immers in alle gevallen gelijk.

Yup.

[Fred Mobach]

Post by Martijn van Buul
Persoonlijk zou ik een
tar cf - /source/dir | (cd /target; tar xvpf -)
doen, maar da's meer (slechte ?) gewoonte dan iets anders.

Dat lijkt me anders een zinnige gewoonte. Maar in plaats van die ';' zou
ik een '&&' gebruiken voor het geval dat ik in /target een tikfout zou
maken. Dan kan er namelijk een zooitje ontstaan.