Comment # 14 on bug 922308 from Stefan Hundhammer

One working day of analyzing the logs and the code later it looks like it's not
the calculations of any limits that are to blame, but a missing call to
StorageProposalClass::PostProcessor:

The missing 

    "userdata":$["/":"snapshots"]

section in the target map is added in PostProcessor::modify() in
StorageProposal.rb:4443 . This is called via either
PostProcessor::process_partitions() or via PostProcessor::process_targets().

There are multiple entry points to create storage proposals:

(1) StorageProposal.rb:3888: get_proposal()
(2) StorageProposal.rb:4491: get_inst_proposal()
(3) StorageProposal.rb:5603: get_inst_prop_vm()    ("VM" for "Volume Manager")
(4) StorageProposal.rb:5985: get_proposal_vm()
(5) StorageProposal.rb:6131: get_inst_prop() (calls one of the others)

(1), (2) and (3) each create a new instance of PostProcessor and call one of
its process_...() functions at the end (followed by an unconditional
y2milestone() logging that leaves a clear trace in the log).

(4) does not do this. Yet this is what is called after the proposal is changed:

2015-03-13 09:15:46 <1> 10.0.2.15(2721) [Ruby] modules/StorageProposal.rb:5989
get_proposal_vm ddev:/dev/sda vg:system home:false lvm:true encrypt:false

So it looks like that PostProcessor calls is simply missing in that case.