-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Support fs_type: gfs2 #417
Comments
What about #400 - this allows you to create volumes without a filesystem? |
Agreed - sounds like it would make sense to have |
Looks like all we need to do is set the gfs2 flag to mark the filesystem as supported, this can be done from the role. I'll check this a bit more and if this is all that's needed for, I should be able to prepare a fix this week. |
GFS2 is supported by blivet, but the support is disabled by default so we need to enable it. Fixes: linux-system-roles#417
@andyprice will this suffice? #418 |
Using:
It succeeds on the first run but running a second time results in
|
The problem is that |
Adding |
Interesting, I'd expected that using |
So the "label" that gfs2 presents is the locking table name that it uses for dlm locking, it's set with mkfs.gfs2's |
Yes, I understand, but it should fail on the first run now, because you are telling the role to create GFS2 with a label and we don't know how to do that. It will be created with that label because of the |
GFS2 is supported by blivet, but the support is disabled by default so we need to enable it. Fixes: linux-system-roles#417
For existing devices we want to read the default value from the device instead of trying to reset it to default/empty label when the fs_label attribute is not set. Related: linux-system-roles#417
@dwlehman actually pointed out the problem is different -- the role shouldn't try to change the label when running for the second time. I've updated the PR with a second fix for the logic around default value for |
With the latest changes in #418 I can run my test, with |
For existing devices we want to read the default value from the device instead of trying to reset it to default/empty label when the fs_label attribute is not set. Related: linux-system-roles#417
GFS2 is supported by blivet, but the support is disabled by default so we need to enable it. Fixes: linux-system-roles#417
For existing devices we want to read the default value from the device instead of trying to reset it to default/empty label when the fs_label attribute is not set. Related: linux-system-roles#417
GFS2 is supported by blivet, but the support is disabled by default so we need to enable it. Fixes: #417
For existing devices we want to read the default value from the device instead of trying to reset it to default/empty label when the fs_label attribute is not set. Related: #417
As #341 has been resolved, it would be useful to be able to create a gfs2 filesystem with the storage role. The current difficulty for the gfs2 role is that the storage role does not allow creating a volume without a filesystem, so the gfs2 role would have to allow an xfs filesystem to be created and then overwrite it with a gfs2 filesystem, which is not ideal, particularly for idempotency.
So it seems the best option* is for the storage role to create the filesystem with
fs_type: gfs2
and accept the special options that mkfs.gfs2 requires. The existingfs_create_options
option should be sufficient for this, e.g.fs_create_options: -j 2 -t mycluster:myfs
For single-node, not-clustered mount testing (only) you could use
fs_create_options: -p lock_nolock
I don't know if blivet would need changes to support this, but there appears to be at least a stub of support for gfs2 already: https://github.com/storaged-project/blivet/blob/master/blivet/formats/fs.py#L1044
* If the storage role does not manage idempotency for filesystem creation, it would be preferable (to avoid data loss) for the gfs2 role if the storage role instead allowed
fs_type: none
so that the gfs2 role can manage it itself.The text was updated successfully, but these errors were encountered: