Support for shrinking filesystem

[thememika]

Shrinking the filesystem seems to be one of very important, core features. For some reason, it's still not even in the Roadmap: https://bcachefs.org/Roadmap What is the status of this feature, and is it planned at all? Thanks!

[Nihon-Ryori]

See the Bcachefs manual (dont have a revision number or date ...): 3.6 Device management 3.6.1 Filesystem resize A filesystem can be resized on a particular device with the bcachefs device resize subcommand. Currently only growing is supported, not shrinking.

• https://bcachefs.org/bcachefs-principles-of-operation.pdf

See also: GParted added now a first bcachefs support

• https://www.reddit.com/r/bcachefs/comments/1fexond/gparted_added_now_a_first_bcachefs_support/

Shrinking existing bcachefs partition, by console, also need for GParted:

• https://www.reddit.com/r/bcachefs/comments/1fh8wam/shrinking_existing_bcachefs_partition_by_console/

[Syntrait]

I think adding a shrinking feature would be very useful, since people that dual-boot often use GParted to move free space between their Linux and Windows partitions.

[nikp123]

There's a kinda bad-ish workaround, but it relies on you having multiple drives:

You can just evacuate the partition you plan on resizing. As in:

# bcachefs device evacuate /dev/paritition_you_plan_to_nuke
# bcachefs device remove /dev/partition_you_plan_to_nuke

Nuking it, then recreating it with the desired size.

Then afterwards:

# bcachefs device add /dev/the_new_partition_you_just_made /

But yes, you do need multiple drives for that partition.

EDIT: Edited to clarify what I meant

[Syntrait]

Or if you have unlimited internet, taking note of and then deleting all the games, documents, files that you can find and redownload again, and then backing up what's left, like browser data, personal documents or config files. It's possible to just archive it, encrypt it, and then upload to a cloud, if you don't have another drive. The rest is basically what @nikp123 said.

[nikp123]

Yeah didn't say that this is a solution but a workaround if your bcachefs partition has multiple drives. Bcachefs very much needs a shrink feature, this is half the reason why i never committed to f2fs for example (it still doesn't do shrinking IIRC)

[hgkamath]

• For some users, like myself, not being able to shrink can be a cause of hesitation to install for permanent long term use on a workstation.
• On server systems, once the planning phase is over and the decision is made to go with bcachefs, it makes sense to dispense with the need to ever consider modifying the disk layout, or trying out other filesystems, until a long distant time in the future that necessitates a server-rebuild. The entirety of disks may be given to bcachefs. Server deployments are usually not intended for experimentation of the wildly diverse sort requiring different partitions.
• For personal workstations on the other hand, a machine owner may want freedom in being able to run dual boot OS-es, move partitions around, make space to try new partitions for different purposes.
• The same freedom, that is to shrink the other partitions like ntfs, fat32, ext4, btrfs, the use of which made it possible to make space for a bcachefs partition, in the first place, isn't reciprocated by bcachefs. Presently bcachefs allows for one-way growth. A strategy would be to start with as small a partition as possible to fit the OS and cover its daily excesses like updates and only grow as needed. In 2 disk machines, one ssd and one hdd, one would want to ideally configure it to use a bcachefs cache partition on the ssd. Being stingy on space might limit what bcachefs could do. For a user to find what works best, the user will need to experiment, but to experiment one requires flexibility. Just as growing a filesystem allows for forward transition to bcachefs, shrinking allows for gradual way in being able to do the reverse transition if need-be. That assurance is needed.
• This keeps me from using xfs for the same reason, and so I end up using btrfs for primary purposes, which does shrink. I occasionally try out bcachefs on temporary basis and delete the disk-partition/VM-disk-partition after trying it out for a short term.

[matthiasgoergens]

We can probably support shrinking as a three-step process, thanks to already supporting multi-device operations:

1. split an existing partition in twain
2. evacuate one of the two partitions
3. delete the evacuated partition

Only the first step is new. I think in principle it would only involve operations on metadata, and not any moving of non-meta data. (Apart from moving perhaps O(1) pieces of data around that happen to straddle the border between the two new partitions, or would get in the way of fixed locations of new metadata.)

@koverstreet Is the above sane? I tried looking through the code to see how one would go about implementing it. (I tried to implement it for fuse or so only at first, no need to involve the kernel. If that makes sense.)

[Nihon-Ryori]

In my opinion, the following is a possible solution to realize shrinking of partitions for bcachefs:

1. divide the partition to be downsized into a partition with the desired target size plus a partition with the corresponding remaining size.
2. move the data of the partition to be deleted later to the partition to be retained.
3. delete the emptied partition.

Once this has been implemented in bcachefs, it can also be integrated into GParted.

[matthiasgoergens]

In my opinion, the following is a possible solution to realize shrinking of partitions for bcachefs: [...]

Is that essentially what I said, or am I missing a subtlety?

Btw you can use the same idea to move a partition to a new place, even if old and new overlap. However, you might also want to implement being able to merge adjacent partitions for completeness. (Not sure if the logic would be the same.)

Of course, this is all easy for us to speculate about. Implementation is another question.

[Nihon-Ryori]

Is that essentially what I said, or am I missing a subtlety?

It may be the same for native speakers, but my translator had problems translating it for me. So it seems that everything is ok in both versions. Let's keep looking forward.

Partly solution:

2. move the data of the partition to be deleted later to the partition to be retained: rsync -va -AHSX source target

3. delete the emptied partition: echo 'd' | sudo fdisk /dev/sdx

[iav]

1. split an existing partition in twain

This is completely pointless, as it requires a "split partition" function, which doesn't exist, and most likely never will, since who and why might it even be necessary? Can you name a file system that has this feature?

[Silverdev2482]

Or if you have unlimited internet, taking note of and then deleting all the games, documents, files that you can find and redownload again, and then backing up what's left, like browser data, personal documents or config files. It's possible to just archive it, encrypt it, and then upload to a cloud, if you don't have another drive. The rest is basically what @nikp123 said.

I think its actually half useful, way easier than reinstall if you have the drives and storage space to spare.

[Franck666666]

the Ai told Kent never did read or view this here , but he more likes anyway having Trouble with Linus , Ai told so when asked LoL

[CyanChanges]

Supposely shrinking is just to reallocate data to be removed to free space in new part. And also move pointers?

[koverstreet]

If anyone wants to work on it shrink is pretty easy to add via bch2_move_data_phys(), I've just had higher priority things that need doing :)