Thanks for the question! Well, overcommitment is
part of the plausible deniability design: basically we need that, whatever password secrecy level you provide, it looks like all the disk space is utilized, because if there is clearly unmapped space then it's clear that there is still something hidden.
Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected".
A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.
Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected".
A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.