singularity overlay create: support sparse ext3 images

[nathanweeks]

Is your feature request related to a problem? Please describe.
Filling up the ext3 file system in an overlay image file can cause applications to fail at runtime. To prevent this from occurring, it's useful to over-provision the size of the ext3 file system. However,singularity overlay create --size <size> <ext3_image_file> creates only non-sparse image files, so the user immediately realizes the maximum cost in terms of disk usage vs. sparse image files (in addition to the extra time & I/O spent upfront to create the image, which can be nontrivial for image files in the TBs)

Describe the solution you'd like
Add a singularity overlay create --sparse option (applicable only when creating a new ext3 file system image, not when embedding a writable overlay in an existing SIF)

Describe alternatives you've considered
This could otherwise be done in several steps, following the directions in the SingularityCE user guide's Create an overlay image (< 3.8), replacing dd with truncate -s, but it would be more convenient for the end user to have this capability as an option to singularity overlay create (particularly when used in conjunction with --create-dir, which otherwise with the mkdir/truncate/mkfs.ext3 approach requires the user to know to use mkdir overlay/work/<dir>)

[dtrudg]

We'd happily accept a PR for this as a flag. I tend think that by default consuming all required space up-front is generally a good thing, as a large proportion of singularity users are often working in quota limited spaces, so creating a large sparse file might not gain much as it can 'hide' the quota / ext3 size limits.

I am quite interested in why you would be using an image file in the TBs however?

[nathanweeks]

We'd happily accept a PR for this as a flag.

I'm not that familiar with golang, but if I find some spare time I can have a go at it (I guess there's a bad pun in there somewhere...)

I tend think that by default consuming all required space up-front is generally a good thing, as a large proportion of singularity users are often working in quota limited spaces, so creating a large sparse file might not gain much as it can 'hide' the quota / ext3 size limits.

On the other hand, a quota-limited space could also be a motivator for using sparse files. Unless the user is copying a known fixed-size data to an overlay ext3 file system, they'd create an image that's some degree larger than what they need---which would actually consume the extra quota'ed storage space if the image is non-sparse.

I am quite interested in why you would be using an image file in the TBs however?

There are some bioinformatics applications (and probably applications from other domains as well) that generate & access a large numbers of smallish files during execution; these can perform poorly on a parallel file system like Lustre (and strain the Lustre metadata server). Dealing with lots o' little files in a writable overlay file system image can improve performance & keep Lustre usable for other users (e.g., see examples for Trinity & Cactus).

[vsoch]

@nathanweeks I can do this! Can you show me what the truncate interaction should look like (if you were doing it on the command line?)

[nathanweeks]

@vsoch Wow, that's awesome! My sincere thanks and appreciation (and thanks to @dtrudg as well). I look forward to advertising this functionality to users who might benefit after it has landed in a release.

[vsoch]

Thank you! I miss developing in Go so I’m eager to work on little things here to get it! Definitely ping me for said little things, of course after the addition is +1 by the project leads. And hopefully as I get better acquainted with the code and testing I’ll become more proficient at it. 😆