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
It seems to somehow be related to btrfs, but I am not familiar with any restriction on btrfs's ability to resize arbitrarily that would lend itself to needing a 150MiB minimum. Certainly not finding that at all in its documentation.
Actionable items to consider:
At least document the limit and why it exists.
Ideally, why not have these cases fall back on creating a new volume encrypted with the same key file of the requested size and copying contents over?
If the reason is somehow related to btrfs, detect the filesystem and enforce the limit only for btrfs
If there's no hard technical reason from filesystems, consider not having the limit.
P.S. It's very odd that btrfs resizing involves creating a directory under $HOME instead of /run/media/$USER/, which is where tomb open normally seems to go:
Looking at the source, and attempting a resize directly, it appears that
tomb
restricts resizing a tomb to 150MiB increments:tomb/tomb
Line 2849 in ff69299
This is not reflected in the documentation, and is also a really odd limit. Is there any documentation for why we have such a limit?
Looking at the
git blame
: 48c08c0It seems to somehow be related to
btrfs
, but I am not familiar with any restriction on btrfs's ability to resize arbitrarily that would lend itself to needing a 150MiB minimum. Certainly not finding that at all in its documentation.Actionable items to consider:
btrfs
, detect the filesystem and enforce the limit only forbtrfs
P.S. It's very odd that
btrfs
resizing involves creating a directory under$HOME
instead of/run/media/$USER/
, which is wheretomb open
normally seems to go:tomb/tomb
Line 2894 in ff69299
The text was updated successfully, but these errors were encountered: