Verwijderen bestanden TRAAG

[tondev]

Hoop dat ik in het juiste forum zit. Ik heb de volgende vraag.
Ik heb een grote map begrensd tot 8 TB (Timemachine backup MAC) die niet meer wordt herkend door de Timemachine. Nu heb ik een nieuwe map aangemaakt en ben de oude aan het verwijderen, enkele Terrabytes groot. Na uren staat ie amper op 1% verwijderd. Heeft iemand daar ook ervaring mee of weet een antwoord s.v.p. of dit niet sneller kan?
De nieuwe map kan ik ook niet gebruiken aangezien de Timemachine aangeeft dat de nieuwe map te klein is. (waarschijnlijk omdat de oude nog veel opsnoept). Bij voorbaat dank.

[Hofstede]

Hoe verwijder je de oude data? Vanaf een PC of Mac? Dan gaat het via het netwerk en dan gaat het traag.

Het snelste gaat op de NAS zelf, bijvoorbeeld via FileStation. Het allersnelste gaat het vanuit de command line als je inlogt via telnet of SSH.

[tondev]

Zowel vanaf de Mac als in de NAS zelf gaat het traag

[tondev]

Via de Command line zou ik niet weten hoe je dat doet. Met Terminal op de Mac of in de Synology zelf?

[Hofstede]

Via ssh of telnet inloggen op de NAS. Dan kun je met het linux commando rm de directory recursief verwijderen. Als je hier niet in thuis bent kun je er beter niet mee experimenteren.
Een andere truc die je zou kunnen proberen: de share via DSM weggooien, dan gooit de NAS intern ook alle files in die share weg. Daarna opnieuw aanmaken.

[tondev]

Ik heb via Terminal (MAC) het commando RM + de bewuste directory gegeven maar er gebeurt niets. Na ruim 1,5 dag zit ik nog steeds op amper 18 % verwijderde files. Absurd!

[Briolet]

Na ruim 1,5 dag zit ik nog steeds op amper 18 % verwijderde files.

Vooral omdat een TM backup niets meer is dan één enkele diskimage file. Je zou zeggen dat hij hem alleen in de directory als 'deleted' hoeft te markeren en de ruimte weer vrijgeven.
Het is natuurlijk wel een file die over meerdere disken verdeeld staat, die ook weer in een raid systeem staan. Een raid van 8 TB opnieuw opbouwen kost ook tijden. Op mijn j modelletje is dat ook 12 uur per TB

[Hofstede]

Die aanname is fout. Op je Mac zie je de TimeMachine backup als één grote sparsebundle-file omdat hij door de finder van OSX zo wordt gepresenteerd, maar in werkelijkheid is het een directory met daarin honderden, zoniet duizenden kleine files (bands). En zo wordt hij door de NAS ook gezien, en de NAS kan niets anders doen dan die één voor één wegggooien.
Ik heb hetzelfde wel eens meegemaakt met een originele TimeCapsule van Apple. Daar was de snelste methode om een oude image weg te krijgen het simpelweg opnieuw formatteren van de schijf in de TimeCapsule.

[Briolet]

@Hofstede: Ik vind het heel onlogisch dat de nas zo'n diskimage als meerdere files ziet. Voor de nas is er zelfs geen reden om die bestandsstructuur van een sparsebundel te kennen. En normaal is zo'n diskimage gelocked met het wachtwoord van het mac-account van de gebruiker. Om er in te kunnen kijken moet de nas ook de beschikking hebben over dat wachtwoord. Het zou een slechte zaak zijn als hij dat had.

[Hofstede]

Log zelf maar eens in op je NAS en bekijk zo'n sparsebundle. Je zult zien dat hij in de linux omgeving zichtbaar is als een directory. Daarbinnen zie je dan een structuur met allemaal files met de naam band met een identificatienummer. In die band-files slaat timemachine dan weer jouw data op. Je ziet de filestructuur van je harde schijf dus niet één op één terug.
Op de TimeCapsule gebeurt dat net zo, alleen wordt het voor jou als OSX gebruiker afgeschermd.

[Briolet]

De Timemachine share kan ik niet eens zichtbaar krijgen in FileStation, dus hoe het via FileStation zichtbaar is weet ik niet, maar op linux niveau, heb je gelijk:

Code: [Selecteer]

GedeeldeData> ls /volume1/TimeMachine/xxxxxx.sparsebundle
@eaDir
Info.bckup
Info.plist
bands
com.apple.TimeMachine.MachineID.bckup
com.apple.TimeMachine.MachineID.plist
com.apple.TimeMachine.Results.plist
com.apple.TimeMachine.SnapshotHistory.plist
token
De "bands" directory zit vol files met gecodeerde filenamen. 

en op de harde schijf aan mijn airport natuurlijk hetzelfde:

Code: [Selecteer]

iMac-DDR2:~ Briolet$ ls /Volumes/"Kantoon Station"/xxxxxxx.sparsebundle
Info.bckup com.apple.TimeMachine.MachineID.bckup com.apple.TimeMachine.SnapshotHistory.plist
Info.plist com.apple.TimeMachine.MachineID.plist token
bands com.apple.TimeMachine.Results.plist
Alleen de "@eaDir" mist op de airport. Dat is dan blijkbaar iets wat de nas zelf toevoegt?

[Hofstede]

Klopt. @eaDir wordt door de Synology gebruikt om de resource-fork van een file op te slaan. Dit moet voor de Synology apart omdat hij met EXT4 werkt inplaats van HFS.
Nadeel van dit sparsebundle systeem is dat de grootte alleen toeneemt, niet af, ook als files al lang weg zijn. Maar daarvoor kun je het HDIUTIL commando gebruiken om je sparsebundel opnieuw te comprimeren. Dan gooit hij niet meer in gebruik zijnde bands weg en krijg je schijfruimte terug.

[r00n]

Zal je resource manager niet het één en ander aangeven waarom het zo langzaam gaat?