Is Gparted needed in GhostBSD?

grahamperrin

vimanuelt why is GParted misrepresented negatively with a blunt "No" for ZFS Awareness?

GParted does have ZFS awareness. The same is true for KDE Partition Manager:

vimanuelt

GParted and KDE Partition Manager both can see ZFS partitions but cannot safely interpret, resize, or modify them. Both tools correctly show ZFS partitions with no mount information or usage details. This is expected as they are not ZFS-aware. These tools are helpful for seeing partition structure, but not suitable for managing ZFS data.

grahamperrin

vimanuelt ZFS partitions with no mount information

Because the partition is not mounted.

grahamperrin

vimanuelt GParted and KDE Partition Manager both can see ZFS partitions but cannot safely interpret, resize, …

If resizing is correctly prevented, then how is the interpretation unsafe?

Healthy following a move, according to documentation:

{Screenshot: a pool with multiple file systems, healthy, following a move of the pool's partition by GParted}

vimanuelt

If you are seeking a graphical tool specifically designed to manage ZFS partitions, then using a ZFS-aware GUI utility may offer a more appropriate and reliable solution.

grahamperrin

vimanuelt If you are seeking a graphical tool specifically designed to manage ZFS partitions, …

I'm not.

The wish was concise, simple: GParted.

I know its capabilities.

vimanuelt

Developing a GhostBSD-specific ZFS-aware graphical utility similar in purpose to GParted could be accomplished within a few months. The primary reason it has not yet been created is simply that the idea has not received focused attention.

vimanuelt

grahamperrin
Thanks for the clarification.

If the request is specifically for GParted to support ZFS, then it is worth noting that GParted does not currently support ZFS due to its complexity and licensing differences. That is why ZFS datasets do not appear as mountable partitions in the way other filesystems do.

That said, you do have a few options:

Wait for someone to port or extend GParted to support ZFS, though that is unlikely in the near term unless upstream developers choose to prioritize it.
Initiate or contribute to a port. Since GhostBSD and FreeBSD are open-source, you or anyone interested could create a graphical front-end for ZFS management. This has been discussed before, and a dedicated tool built on ZFS’s native tools might even be better suited than retrofitting GParted.
Use existing ZFS-native tools, such as zfs list, zpool status, and graphical wrappers available that could theoretically be adapted or recreated for BSD environments.

If your interest is more about having any graphical tool for ZFS partitioning rather than GParted specifically, it might be worth exploring or advocating for a BSD-native alternative purpose-built for ZFS.

Let us know which direction you would like to pursue. If others are interested in the same, it might be worth opening a discussion or feature proposal. :-)

grahamperrin

vimanuelt … Initiate or contribute to a port. … you or anyone interested could create a graphical front-end for ZFS management. …

I'm not a developer, and I'm not seeking a graphical utility for ZFS.

vimanuelt

grahamperrin
I suggest asking the maintainer of the application.

grahamperrin

vimanuelt I suggest asking the maintainer of the application.

Asking the maintainer why you describe something as unsafe?

vimanuelt

grahamperrin
Thank you for the clarification.

If you are not seeking a graphical utility for ZFS, and not planning to contribute to a port, then the best available option remains to use tools that are known to handle ZFS safely. While GParted may be able to display ZFS partitions, it does not fully understand the structure or metadata of ZFS datasets. That is what makes interpretation risky, not necessarily in terms of mounting or reading, but in actions that might affect alignment, partition boundaries, or metadata integrity if used beyond display.

Even a healthy status after a move does not guarantee long-term stability, especially if ZFS warnings or performance issues emerge later. This is why upstream tools such as zpool and zfs are still the recommended way to manage pools and datasets.

If there is interest in improving graphical support for ZFS, that would likely need to come from the FreeBSD or GhostBSD community through a native solution that respects ZFS's unique layout and behavior.

Let us keep documenting use cases and limitations. That is still a valuable contribution for others who may be navigating the same space.

vimanuelt

grahamperrin
I understand your concern. My use of the term "unsafe" refers to the general caution expressed by the ZFS community and upstream documentation regarding third-party tools like GParted. These tools do not have native support for ZFS structures, and while they may display partitions, they do not interpret ZFS metadata reliably. This can lead to unintended consequences if users attempt operations beyond viewing.

If you are confident in your specific use case and outcomes, that is your choice. However, when offering guidance in a public forum, I prefer to err on the side of caution for readers who may not have deep familiarity with ZFS internals.

As for the maintainer, I only suggested that route if further clarification is needed about how GParted handles ZFS under the hood. My remarks are based on observed behavior and widely accepted best practices, not on an internal claim from the developer.

Let us try to keep the conversation helpful for others who may be less technically experienced.

grahamperrin

vimanuelt I understand your concern.

With respect: I think not.

For example: if something specific is safe, please do not describe it as unsafe.

vimanuelt

Hopefully, this helps.

ZFS layouts and metadata are complex and fragile under non-native tools

ZFS maintains internal metadata and checksumming that are tightly coupled with block alignment and sector layout. Using third-party partition editors that do not understand these constraints can result in:

Block misalignment
Invalid disk labels
Loss of redundancy or bootability in EFI or mirrored root pools
Silent corruption not immediately visible to tools like zpool status

OpenZFS documentation warns against modifying underlying partitions without using ZFS-native tools:

“ZFS is designed to manage whole disks or partitions given to it. Resizing, moving, or altering those partitions outside of ZFS may result in unpredictable behavior.”

Source:
OpenZFS GitHub Issues and Discussions (e.g., zfs#12262, community mailing list discussions)

In my understanding:
Displaying ZFS partitions is generally safe.
Modifying ZFS partitions with GParted is not recommended and can be unsafe.
ZFS expects complete control of its devices and does not tolerate manipulation outside its tooling.

grahamperrin

vimanuelt ZFS expects complete control of its devices and does not tolerate manipulation outside its tooling.

As expected: all four labels were good following the move of the partition by GParted.

vimanuelt

grahamperrin
openzfs/zfs12262

grahamperrin

vimanuelt what's the relevance to GParted?

GParted is not mentioned in the issue.

zpool-upgrade(8) is not a feature of GParted. No interaction.

vimanuelt

The discussion at https://github.com/openzfs/zfs/issues/12262 highlights that more work is still needed to ensure full compatibility between third-party tools and ZFS.

Until proper support is implemented and verified, it is reasonable, and safer, to treat such interactions as potentially unsafe. It is important that we do not give others the impression that these tools are fully reliable with ZFS when they are not.

Let us help users avoid subtle and preventable issues by setting clear expectations. 😊

vimanuelt

grahamperrin
I am relaying my understanding of the issue. That is all.