Hi all,
it's nice to know there is already a fix for this issue!
> If you agree with this all we'll send a PR to Manila too for a quick fix.
I'm afraid this might be harder than fixing it on the ceph side if Manila uses the name it generates as a key in its DBs. I'm not too familiar with its codebase though so take this just as a guess.
Also, since there's this hard limit on snap name length, would it make sense for `fs subvolume snapshot create` to do input validation and exit early with an error? It wouldn't solve this particular issue, but it sounds better than silently creating inaccessible snapshots.
Cheers,
Robert
so 2. 4. 2022 o 2:30 Xiubo Li <xiubli@xxxxxxxxxx> napísal(a):
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
