Shouldn't be a problem, if you are sure they are due to storage migration and not because of upload/download volume
On 11/06/13 12:24 AM, "Nick Wales" <[email protected]> wrote: >I have opened issue no 2897 to track this. > >In the mean time, can someone confirm if I'm ok to mount the secondary >storage and delete them all? > > >On 8 June 2013 02:18, Nguyen Anh Tu <[email protected]> wrote: > >> Hey, same same idea. Anyone can figure out all of the use cases that >> generate unused data (included corrupt data)? The cleanup worker now >>seemly >> doesn't cover every situation. >> >> >> 2013/6/7 Nitin Mehta <[email protected]> >> >> > I guess not. I guess there might be an enhancement for this, but if >>not >> > please feel free to raise one. >> > Ideally it should have deleted all the volumes on sec. storage once >>the >> > copy operations are done. >> > >> > The only cases where its persistent on sec. storage is during upload >> > volume. Even for download volume the link expires after some time >> > and after that the volume is deleted. >> > >> > Thanks, >> > -Nitin >> > >> > On 07/06/13 2:46 AM, "Nick Wales" <[email protected]> wrote: >> > >> > >We're in the middle of migrating our storage. I have moved all the >>VM's >> > >and >> > >the associated volumes to the new storage and this appears to have >>been >> a >> > >two part copy job on the part of cloudstack: >> > > >> > >Primary Storage 1 -> Secondary Storage -> Primary Storage 2 >> > > >> > >Right now two and three day old copies of the volumes are still >>resident >> > >on >> > >the secondary storage taking up hundreds of GB's and slowing down our >> > >efforts to migrate to the new storage. >> > > >> > >There is no mention of these volumes in the UI and its way beyond the >> > >"storage.cleanup.interval" time. Is there a way to clean them up? >> > > >> > >Thanks >> > > >> > >Nick >> > >> > >> >> >> -- >> >> N.g.U.y.e.N.A.n.H.t.U >>
