Am 23.10.2015 um 10:24 schrieb Josef Reidinger:
I think it is two different things.
1) probing should handle such situation
2) common query should return only later as first one is overlaped, of course there can be specialized call to manipulate mount points knowing also about overlap or knowing that removing first mount point return to game previous one
Not sure if the two of you are talking about the same things here. Maybe
this helps to clarify:
In general, it is not a good idea to enforce a consistency check after
each low-level call. There should be such a consistency check, of
course, but when is it triggered, and what consequences does this have?
Use case: The user is in the expert partitioner and wants to change
mount points because he discovered he made a mistake: He really wants
/home on his blazingly fast SSD /dev/sda and /data on the slower
rotating disk /dev/sdb, but he accidentially put /data on /dev/sda3 and
/home on /dev/sdb1. In effect, this is a classic "swap" operation.
So, from a user's point of view, I want to be able to:
- Change the mount point of /dev/sda3 from /data to /home.
So, for the moment, I have a /home mount point on both /dev/sda3
and /dev/sdb1.
- Change the mount point of /dev/sdb1 from /home to /data.
Voila, only one /home mount point left, everything okay.
If we force the consistency check after the first step, it will complain
about the two identical mount points, so we force the user to either
change the mount point of one of the two partitions to nothing
temporarily (maybe causing another error popup if this is checked, too)
or to invent a temporary fake mountpoint. One way or the other, this is
another operation the user has to do, and it's not very intuitive.
This serves to illustrate the point: We need to keep low-level
operations and consistency checks apart. Consistency checks should be
invoked at strategic points - either just before commiting / executing
all the changes, or explicitly triggered from app code when the logical
transaction is done - i.e. when the user tries to exit the expert
partitioner. This would be a good place to do the checks and to display
any warning or error dialogs to the user.
Any time before that and we are limiting the user's workflow, forcing
him into detours and thus distracting him from what he really wants to do.
This affects the real end user as well as any application code using
libstorage.
HTH
--
Stefan Hundhammer