On Fri, 2016-04-15 at 05:09 -0400, Bastien Nocera wrote:
Hey,
----- Original Message -----
>
> = Proposed Self Contained Change: Replace UDisks2 by Storaged =
>
https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged
>
> Change owner(s):
> * Peter Hatina <phatina redhat com>
> * Tomáš Smetana <tsmetana redhat com >
>
> Storaged extends UDisks2 API by exporting several enterprise
> features
> (in form of plugins), such as LVM2 and iSCSI. This project is a
> drop-in replacement for UDisks2, either from D-Bus or binary point
> of
> view. The main motivation of this change is to provide the unified
> D-Bus API for all the clients who are willing to manage LVM2,
> iSCSI,
> Btrfs, BCache, LSM and ZRam.
>
> == Detailed Description ==
> Aim of Storaged is to provide unified higher level management
> interface for various clients who are willing to query and manage
> storage bits of the system. We plan to replace UDisks2 by Storaged,
> since the Storaged itself is the fork of UDisks2 and these 2
> projects
> in its core haven't diverged so much (Storaged got some
> improvements
> which popped up while using it).
What are the additional dependencies compared to Udisks2?
Would gnome-disk-utility, gvfs, etc. work as well as they used to
without regressions when
dropping in storaged, either on a running system, or when compiling
against it?
Will bug fixes and enhancements to the common part between storaged
and
udisks2 be backported to udisks2?
I'm fairly certain we don't want iSCSI binaries in the Workstation
installation
(we've been trying to get rid of the ones that Anaconda brings in
already).
I also don't see why ZRam is something 1) you'd want to have to
configure,
Well, its a compressed bloc device residing in RAM - I can see various
use cases, not just the most frequent one (zram used as a swap device).
Some people for example use tmpfs for running builds, I guess zram
could be used for similar purposes, possibly enabling bigger builds
that take a bit longer than on tmpfs.
2) that has its place in a storage API.
Why is an API providing
some additional functionality you are not going
to use in your specific usecase a problem ?
I'm sure glibc and kernel provide many API calls not directly used by
the default apps on the workstation and we are still using them...
>
> Cheers
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org