On Tue, 2025-08-19 at 19:31 +0530, Kotresh Hiremath Ravishankar wrote: > On Wed, Aug 13, 2025 at 11:52 PM Viacheslav Dubeyko > <Slava.Dubeyko@xxxxxxx> wrote: > > > > <skipped> > > > > OK. I agree that restriction creation of filesystem names greater than NAME_MAX > > length should be considered as independent task. > > > > Are you suggesting to use the inline buffer for fsname with NAME_MAX > as the limit > with this patch ? > Potentially, inline buffer for fsname could be better solution. However, if the user-space side can create the name bigger than NAME_MAX, currently, then we cannot afford the inline buffer yet for this patch. Usually, we can define as volume label as UUID during file system volume creation by means of mkfs tool. But it is always limited by some number of symbols and it is usually much shorter than 256 symbols. Also, the volume label is never involved into the file system operations and path starts from the root folder. > > So, if we are receiving filesystem name as mount command's option, then I think > > we need to consider another structure(s) for fs_name and we can store it during > > mount phase. Potentially, we can consider struct ceph_fs_client [1], struct > > ceph_mount_options [2], or struct ceph_client [3]. But I think that struct > > ceph_mount_options looks like a more proper place. What do you think? > > > > We do this already. The fsname is saved in the 'struct ceph_mount_options' as we > parse it from the mount options. I think this is used only during the > mount. The > mds server does send mdsmap and fsname is part of it. This will be used for mds > authcaps validation. Are you suggesting not to decode the fsname from mdsmap ? > > If we already have the fsname in the 'struct ceph_mount_options', then we can decode the fsname from mdsmap and to compare with the name in 'struct ceph_mount_options'. The name in mdsmap should be the same as name in 'struct ceph_mount_options'. But it doesn't make sense to save the fsname in 'the struct ceph_mdsmap' because we already keep this name in the 'struct ceph_mount_options'. Does it makes sense to you? :) Thanks, Slava.