Hi,
On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote:Hi, 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? https://github.com/stratis-storage/stratisd/issues/635 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[1] 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... [1]: https://github.com/system-storage-manager/ssm
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...
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: springfield@xxxxxxxxxxxxxx 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,
Steve.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
