what should be done for block volume about target_path.

Skip to first unread message


Feb 2, 2021, 9:22:29 PM2/2/21
to container-storage-interface-community
 There seems to be different viewpoints and implementations of block volumes about target_path.

 The first kind is that SP will place the raw device at the target_path. Ref:
  ''For volumes with an access type of block, the SP SHALL place the block device at target_path." in CSI Spec.
  "For block volumes, the CO expects there to be a device file at TargetPath." in https://kubernetes-csi.github.io/docs/raw-block.html

 And the other one is that SP will format the device and mount the device onto the target_path. In this case, target_path is a mountpoint. Ref:
  NodePublishVolume in pkg/iscsi/nodeserver.go, AttachDisk in pkg/iscsi/iscsi_util.go, https://github.com/kubernetes-csi/csi-driver-iscsi

 So which one is the standard implementation? Or does this depend on what the volume consumer expects?


Ben Swartzlander

Feb 4, 2021, 5:33:36 PM2/4/21
to container-storage-...@googlegroups.com
The two most common approaches are a single-file bind mount of the
device file from /dev, or just call mknod(2) at that path with the right
device number.


> Thanks,
> Thonic
> --
> You received this message because you are subscribed to the Google
> Groups "container-storage-interface-community" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> container-storage-interf...@googlegroups.com
> <mailto:container-storage-interf...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/container-storage-interface-community/tencent_81C005D3E14EBE3EF8E5A03F14AE95DFCF0A%40qq.com
> <https://groups.google.com/d/msgid/container-storage-interface-community/tencent_81C005D3E14EBE3EF8E5A03F14AE95DFCF0A%40qq.com?utm_medium=email&utm_source=footer>.


Feb 4, 2021, 9:01:48 PM2/4/21
to container-storage-interface-community
Hi Ben,

 Thanks for your reply.
 Originally I thought there was only one valid and standard way (either raw block or mount dir) to consume block volumes, because I thought of VolumeCapability.access_type as a indicator of backend storage type instead of the approach how CO expects to consume the block volumes.
 I'm not sure whether my understanding at present (that both ways are allowed and CO tells SP how it will consume the block volumes by access_type) is correct, and how could the SP ensure the data won't be removed by accident when using the approach formatting and mounting block device at target_path.
 Hope to get your advice and guidance.


------------------ Original ------------------
From: "Ben Swartzlander" <b...@swartzlander.org>;
Date: Fri, Feb 5, 2021 06:33 AM
To: "container-storage-interface-community"<container-storage-...@googlegroups.com>;
Subject: Re: what should be done for block volume about target_path.
To unsubscribe from this group and stop receiving emails from it, send an email to container-storage-interf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/container-storage-interface-community/39a9f642-5ff2-4cbb-6e1b-44325a5324d1%40swartzlander.org.


Feb 5, 2021, 2:34:55 AM2/5/21
to thonic, container-storage-interface-community
The approach of bind-mount or mknod are exactly the right way to duplicate a target_path device from system path.
This helped me solved another problem. Thanks.

------------------ Original ------------------
From: "thonic" <tho...@foxmail.com>;
Date: Fri, Feb 5, 2021 10:01 AM
Reply all
Reply to author
0 new messages