Re: CephFS Snapshot name length limit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 4/2/22 3:31 AM, Dan van der Ster wrote:
Hi Venky and CephFS devs,

Are you aware of problems with long snapshot names?

The Manila driver creates pretty long subvolume snapshot names:
https://github.com/openstack/manila/blob/master/manila/share/drivers/cephfs/driver.py#L566-L580
Ex: 3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c

And we have trouble accessing those.

It works with a recent kernel this way:

# ls /cephfs-pam-fuse/volumes/_nogroup/dbebbb35-31f1-47e5-ac75-48d65a1ee33c/.snap/3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c/fe1b97f3-3481-43a9-a677-c9424544de09/
now
#

But we cannot see the "now" file when listing via .snap in a subdir:

# ls /cephfs-pam-fuse/volumes/_nogroup/dbebbb35-31f1-47e5-ac75-48d65a1ee33c/fe1b97f3-3481-43a9-a677-c9424544de09/.snap/_3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c_1100/
#

Hi Dan

# echo _3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c_1100 | wc -c
80

This is a bug in MDS and have fixed in [1], currently the MDS will always truncate the snapshot name to 80 chars.  The suffix of '_1100' should be the partial of the parent inode#.

And in late future we will limit the snapshot name length to 240 to support fscrypt [2]. But currently as a workaround you'd better not allow the length longer than 80 - 1 - 14 = 65 chars.


[1] https://github.com/ceph/ceph/pull/45192

[2] https://github.com/ceph/ceph/pull/45312

-- Xiubo



(Subvolume_V2 users always mount the subdir, so they can only ever
access snaps via the subdir path, btw).

The kernel client has the same issue (confirmed with latest CentOS
Stream 8 kernel).

And btw old kernels can't even list this dir. Here is the latest
CentOS 7 kernel:

# ls /cephfs-pam/volumes/_nogroup/dbebbb35-31f1-47e5-ac75-48d65a1ee33c/fe1b97f3-3481-43a9-a677-c9424544de09/.snap/
ls: cannot access
/cephfs-pam/volumes/_nogroup/dbebbb35-31f1-47e5-ac75-48d65a1ee33c/fe1b97f3-3481-43a9-a677-c9424544de09/.snap/_3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c_1100:
No such file or directory
_3c42f809-4b10-4877-911d-c68910747ae5_eb90c527-9de4-4f57-87bf-6b06f57a396c_1100


I think this is all because the snap name is too long.
Notice that the subdir snap has _1100 appended -- this is supposed to
be the inode of the place where the snap was taken (IIUC) -- but it
has been truncated to 80 chars, presumably because of
https://github.com/ceph/ceph/blob/master/src/mds/snap.cc#L87

We have snaps in subvolumes with shorter names -- they work perfectly.
And anyway surely someone would have noticed if subvolume snapshots
are completely unusable, right?!

Do we have a limit (not enforced) on CephFS snapshot names?
Should we enforce that? (IIUC the user definable length should be 14
or 15 chars fewer than 80, let's say 64 to be safe?)
If you agree with this all we'll send a PR to Manila too for a quick
fix. (I can't believe no one has tried this....)

Cheers, Dan
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx


_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx




[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux