@chungy, replying to your: > Thanks, but it wasn't so much asking about storing more than you have at once, but as file systems are used, old unused space might

@chungy, replying to your: > Thanks, but it wasn't so much asking about storing more than you have at once, but as file systems are used, old unused space might still be occupying space in the Shufflecake scheme. Say you have that 1GB volume with three equally-sized volumes; sure, you can write ~333MB to each of them, and then delete all the files. Now according to each of the file systems, you have 0B used and 1GB free. When you try making new files after this point, will it still generate I/O errors? Oh, I see what you mean. In your scenario, you can still write data, because creation and deletion of files is managed by the filesystem on the volume, not by Shufflecake. So, those slices (disk space) that you have previously allocated for the volumes will now still be there, but contain empty space that is recognized as such by the filesystem and can then be overwritten. What might be improved, instead, is the fact that once a slice is empty because you have deleted all files, that slice still exists and is still assigned to the volumes which first allocated that. It might be good to have a system that reassigns that slice to the list of "unallocated" slices and that hence be claimed in future by other volumes. We have some ideas (using TRIM, see Section 6.6 of research paper) on how to implement that but, frankly, I personally think this is not extremely crucial, because it only matters if you exploit heavily the overcommitment feature (which we'd rather limit through the use of virtual quotas, as explained).