Mailinglist Archive: yast-devel (211 mails)

< Previous Next >
Re: [yast-devel] High level notes about new storage API
On Thu, 22 Oct 2015 17:04:35 +0200
Arvin Schnell <aschnell@xxxxxxxx> wrote:

On Thu, Oct 22, 2015 at 08:59:52AM +0200, Josef Reidinger wrote:

You can mount a device at several mount-points. With btrfs this
is even standard, see

Yes, I know that device can have multiple mountpoints, but here is
logic reverse. It said that one mount point can have multiple
devices ( or filesystem like used here ) which is at least for
common usage without overlapper layered mount points not possible.

It is possible, although likely stupid:

cat /proc/mounts
/dev/mapper/system-abuild /mnt ext4 rw,relatime,commit=600 0 0
/dev/mapper/system-giant--xfs /mnt xfs
rw,relatime,attr2,inode64,noquota 0 0

So the API must be able to handle the situation. Or do you prefer
an exception during probing?

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

I do not look at API from probe POV, but from library user POV, so I
query what device content is visible under /mnt, which answer is only
second one.

get_ancestors is the base function in Device and thus is not
specially named for filesystems. Otherwise the name is standard,

Yes, name make sense if you know that it is tree structure, but it
is inside POV, as user I try to read what api said to me and it
said "get me ancestors for given filesystem" which is a bit
confusing and require to know that filesystem is device and devices
is stored in tree structure and then you understand what code want
you to say. So more specialized call like
filesystem->get_device() or get_partition ( even if I know that disk
can be partitionless) can be more friendly for reader of code.

The example in does something special: It checks whether
the filesystem *somehow* is located on a LVM logical volume. This
is still the case even if first on the logical volume is an
encryption device and then the filesystem.

If you just want to know which block devices the filesystem is
directly located on use filesystem->get_blkdevices().

1) I can do such API review for all examples in example directory
if it make sense for you

Not yet or in other words the examples are not use-cases.

OK, fine for me. So I am looking forward for use case oriented examples
as it is the most important for me, as it is something we should show
potential users and it should be attractive API to convince them to use



To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation