Re: Determining non-subvolume cephfs snapshot size

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

 



On Fri, Oct 8, 2021 at 6:44 AM David Prude <david@xxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
>     My apologies if this has been answered previously but by attempt to
> find an answer have failed me. I am trying to determine the canonical
> manner for determining how much storage space a cephfs snapshot is
> consuming. It seems that you can determine the size of the referenced
> data by pulling the ceph.dir.rbytes attribute for the the snap
> directory, however there does not seem to be an attribute which
> indicates the storage the snapshot it's self is consuming:
>
> getfattr -d -m - daily_2021-10-07_191702
> # file: daily_2021-10-07_191702
> ceph.dir.entries="17"
> ceph.dir.files="0"
> ceph.dir.rbytes="6129426031788"
> ceph.dir.rctime="1633653849.686409000"
> ceph.dir.rentries="132588"
> ceph.dir.rfiles="97679"
> ceph.dir.rsubdirs="34909"
> ceph.dir.subdirs="17"

Yeah. Because all the allocations are handled by OSDs, and the OSDs
and the MDS don't communicate about individual objects, the
per-snapshot size differential is not actually tracked. Doing so is
infeasible — it's known only by the OSD and potentially changes on
every write to the live data, which is far too much communication to
make happen while keeping any of these systems functional.

>
> I have found in the documentation references to the command "ceph fs
> subvolume snapshot info" which should be able to give snapshot size in
> bytes for a snapshot of a subvolume, however we are not using
> subvolumes.

I am reasonably sure this doesn't do what you seem to want, either — I
think it's just plugging in the rbytes value (much of the subvolume
API exists so it can plug in to the OpenStack Manila interfaces).

> If we assume a cephfs volume "volume" with a top-level
> directory "directory" and an associated snapshot "snapshot":
>
> volume/directory/.snap/snapshot
>
> What is the best way to determine the size consumed by snapshot?

If you really, REALLY need this, the only approach I can come up with
is to traverse the snapshot and the live tree and identify changed
files, and use some heuristic to guess about how much of the data is
actually changed between them.

But the basic problem is that data usage frequently doesn't belong to
a snapshot, it belongs to a SET of snapshots, so even if we did the
data gathering, we can't partition it out between them. If for
instance your data flow looks like this:
AAAA
 -- snapshot 1
BBBB
 -- snapshot 2
 -- snapshot 3
 -- snapshot 4
CCCC
 -- snapshot 5

Then you might say that snapshot 2 is size 4 and snapshots 3 and 4 are
size 0. But if you delete snapshot 2, you can't actually remove BBBB,
because it's required for snapshots 3 and 4.
-Greg

>
> Thank you,
>
> -David
>
>
> --
> David Prude
> Systems Administrator
> PGP Fingerprint: 1DAA 4418 7F7F B8AA F50C  6FDF C294 B58F A286 F847
> Democracy Now!
> www.democracynow.org
>
>
> _______________________________________________
> ceph-users mailing list -- ceph-users@xxxxxxx
> To unsubscribe send an email to ceph-users-leave@xxxxxxx

_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux