On Wed, Sep 8, 2021 at 10:51 AM Allison Henderson <allison.henderson@xxxxxxxxxx> wrote: > > Hi All, > > Earlier this month I had sent out a lpc micro conference proposal for > file system shrink. It sounds like the talk is of interest, but folks > recommended I forward the discussion to fsdevel for more feed back. > Below is the abstract for the talk: > > > File system shrink allows a file system to be reduced in size by some > specified size blocks as long as the file system has enough unallocated > space to do so. This operation is currently unsupported in xfs. Though > a file system can be backed up and recreated in smaller sizes, this is > not functionally the same as an in place resize. Implementing this > feature is costly in terms of developer time and resources, so it is > important to consider the motivations to implement this feature. This > talk would aim to discuss any user stories for this feature. What are > the possible cases for a user needing to shrink the file system after > creation, and by how much? Can these requirements be satisfied with a > simpler mkfs option to backup an existing file system into a new but > smaller filesystem? In the cases of creating a rootfs, will a protofile > suffice? If the shrink feature is needed, we should further discuss the > APIs that users would need. > > Beyond the user stories, it is also worth discussing implementation > challenges. Reflink and parent pointers can assist in facilitating > shrink operations, but is it reasonable to make them requirements for > shrink? Gathering feedback and addressing these challenges will help > guide future development efforts for this feature. > > > Comments and feedback are appreciated! > Thanks! > Hi Allison, That sounds like an interesting topic for discussion. It reminds me of a cool proposal that Dave posted a while back [1] about limiting the thin provisioned disk usage of xfs. I imagine that online shrinking would involve limiting new block allocations to a certain blockdev offset (or AG) am I right? I wonder, how is statfs() going to present the available/free blocks information in that state? If high blocks are presented as free then users may encounter surprising ENOSPC. If all high blocks are presented as used, then removing files in high space, won't free up available disk space. There is an option to reduce total size and present the high blocks as over committed disk usage, but that is going to be weird... Have you spent any time considering these user visible implications? Thanks, Amir. [1] https://lore.kernel.org/linux-xfs/20171026083322.20428-1-david@xxxxxxxxxxxxx/
