That would be a new behaviour that I have not seen mentioned by any dev. As far as I understand it once a chunk is in your vault then it doesn’t move out unless you turn off your vault. No need to.
To another vault - where else.
Each chunk doesn’t have a set address/vault ID that it has to live in, the network simply finds the closest vault that has room.
What happens when the network grows and the data manager group that was the closest to the chunk ID and is responsible for that chunk is no longer the closest one? I would expect this data manager group to transfer the responsibility of that chunk to the new closest data manager group. But maybe this is done without changing the vault the chunk is actually stored on…
@neo I think you missed the subtlety of my points (“substantial” / “may”) and are talking as if things are fully defined and set in stone. My point is that neither is true so a little more - “may”, “could” “I think” is appropriate, is all.
As I said, I’m not staying you’re wrong, just unlikely to be right on all these points in the end.
I think you may have placed too much weight on my postulation.
I think it is self evident that a vault which has been filled for over 10 months is going to have more “stale” chunks than a vault that has only newly filled. Obviously in a statistical sense since its possible for a vault to be filled with all new chunks or all very old chunks due to the random nature of chunk hashes & XOR addresses
No assumptions needed. It is a fact, unless you devise a system that only stores >10 month old data in a filling vault. But of course then the vault that has been filled would still have older data.
Yes when appropriate. But my postulation, which is not stating fact, but postulating. So using the terms I used seemed appropriate, weren’t they. Maybe I misunderstand what to postulate actually means.
Also I think your misunderstanding of rank made my postulation seem less likely or workable.
Anyhow no problems and your point is taken.
EDIT: if you referred to new data being accessed more than old data, then you would have to show me research to deny accepted data storage habits.
What? That seems bizarrely restrictive. For what purpose?
No worries @neo I said what I did because I read your post not as “postulating” but as “this is how it is” and gave a (rather poor) example not because it was that good an example, but to try and illustrate my point. I think you are giving to much weight to the example 
(because it may be we have none persistent vaults, or it may not). I’ve no wish to offend you, and think you are one of the most helpful people on the forum.
@marmalade at the time if my post it was a feature of the design - due to it being impractical to allow deletion of immutable data. It seems that with Data Chains this will now be possible, and so is being reconsidered and I expect immutable data might well now be delete’able
Oh, interesting! I hadn’t seen that! Do you have a link?
Do you have any references, links or documentation in support of this?
Sorry @Traktion I don’t. It was either in the Data Chains thread or more likely I think something @Viv posted, possibly in the latest Test 7 thread.
No sorry, had some access when I did some R&D a few years ago. It is just considered part of their reference system in the university and doubt its published anywhere to read
I did look up giganews retention and its now 6 years for binaries and 13 years for text. And they keep increasing that retention because currently they are not deleting and haven’t for 4 years or so now. While looking for that blog post where they mention this, I realise it must be 2 years or so ago when they blogged it. Now with retention at 6 years I can see they have kept that promise.
An interesting blog that is off topic here but of interest in general is their win over a copyright troll and the troll had to pay the legal costs http://www.giganews.com/blog/2015/03/giganews-wins-big-judgment-against.html
I think you will that that it is being now considered as that is what I read in a update or test announcement.
It is still going to be tricky since datamaps can be shared outside of SAFE and even datachains could not trace that sharing (sneakernet or zipped up datamap in a file).