You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just a shower thought: Could resize2fs issue TRIM commands for all the "released" space after shrinking?
That would allow GCP Persistent Disk to safely allow shrinking if and only if the reduced size was trimmed. I don't know whether partitioning tools could also check whether the to-be-dropped space is trimmed on a disk backed block device, but worst case they could check for it all being zero.
This could all live behind optional flags not to have the performance degradation, but available for people who'd prefer the extra safety.
The text was updated successfully, but these errors were encountered:
It wouldn't be hard for resize2fs to issue the trim command. I can't speak to whether the GCP's Persistent Disk would be willing to shrink the space if and only if all of the reduced space was trimmed. Partitioning tools can't check whether the to-be-dropped space was trimed; but the partitioning tools could very much check the file system's superblock for common file system types to determine whether it would be safe to shrink the partition.
Just a shower thought: Could resize2fs issue TRIM commands for all the "released" space after shrinking?
That would allow GCP Persistent Disk to safely allow shrinking if and only if the reduced size was trimmed. I don't know whether partitioning tools could also check whether the to-be-dropped space is trimmed on a disk backed block device, but worst case they could check for it all being zero.
This could all live behind optional flags not to have the performance degradation, but available for people who'd prefer the extra safety.
The text was updated successfully, but these errors were encountered: