Re: Determining non-subvolume cephfs snapshot size

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

 



Gregory,

   Thank you for taking the time to lay out this information.

-David

On 10/8/21 1:34 PM, Gregory Farnum wrote:
> 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

-- 
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




[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