On 30/06/2020 13:58, Neal Gompa wrote:
So yes, SSM has been subsumed into Springfield too. There was a long
debate over the project name, but nobody came up with anything better,
so it has stuck...
On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse <swhit...@redhat.com> wrote:
On 29/06/2020 23:57, Markus Larsson wrote:
On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote:
On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote:
Why not Stratis?
Stratis cannot be used to build the root filesystem. (It's been
answered elsewhere in the thread.)
Are we sure?
While it might not be super there yet it seems it is technically
working (I may be wrong I have done 0 tests).
But given how new that is and that tolling around it isn't there it
pretty far from being a viable default.
It is perhaps also worth mentioning, since I've not seen it elsewhere in
this thread, that Stratis is part of the (larger) Project Springfield.
This is aimed at improving the overall storage/fs management experience,
and there are a number of parts of that landing in various places at the
moment. There is more to come, of course, but the overall aim is
improved user experience for whatever combination of fs/block devices
are in use,
This is the first time I've ever heard that codename, and you should
really change it, because that name is already used for cloud-based
security fuzzing from Microsoft Research. It's a great idea, though!
Improving the UX of storage management is generally a good thing, in
my view. Btrfs provides significant improvements in this regard, but
there can be even more. Tools like SSM were great attempts at
making the LVM experience not suck. Cockpit does a good job of making
handling storage management a lot more approachable, too.
I'd be curious if you are only thinking of server cases, or if desktop
cases are also being considered. Historically, projects like these
from Red Hat are largely only for the server...
There are a lot of things going on, although few of them have actually
been labelled with Springfield, so perhaps not too surprising that the
name is not so well known. There has been a new mount API upstream, for
example which is part of that, as is also the fs notifications (of which
the notifications core was merged in the most recent merge window, but
the mount notifications and fsinfo syscall are still forthcoming).
There has also been work on PCP, to ensure that we have good metrics for
a wide variety of filesystems, and there is a dashboard for GFS2 in
Cockpit as part of that work. Cockpit is one of the important consumers
of the APIs that fall under the Springfield umbrella.
There is libmount (which will get an update to take advantage of the
kernel changes mentioned above) as well as udisks2, libstoragemgmt and
blivet. The overall aim here is not to focus on one specific tool, but
instead to look at the overall stack and figure out how to make the
components work better with each other to provide a better user experience.
I know it has been rather confined to Red Hat internally, however that
was not the intention, and in fact I would like to strongly encourage
community involvement. There is an upstream mailing list, which
currently has almost no traffic: springfi...@sourceware.org so please do
join and ask questions, if anybody is interested in finding out more.
There is no Springfield codebase as such - it is an umbrella project
that involves a number of subprojects. Also, the reason that it is
interesting is that the intent is to look at both the kernel and
userspace parts of managing storage and filesystems and to improve the
whole stack, rather than looking a small pieces in isolation. Our aim is
to encourage discussion and cooperation between the individual subprojects.
To answer the earlier question, yes this it is intended for both
workstation and server use cases. That is perhaps getting a bit off
topic here, but hopefully it will help to clear up any confusion about
what Springfield is/does,
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines