Its 10.2.7 and yes, I will file a bug soon. On Fri, Sep 15, 2017 at 4:22 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Fri, 15 Sep 2017, Wyllys Ingersoll wrote: >> Following up on this issue: >> >> Does having too many cephfs snapshots prevent the deletion of older >> ones? We've got about 4800 snapshots and attempted to purge some older >> ones, but the "rmdir" of the old snapshots seems to hang and is not >> ever completing. >> >> ceph -s shows an ever increasing number of blocked requests while this >> is going on. I waited over 10 minutes for 1 snapshot to delete before >> I finally killed the "find" command that was attempting to remove the >> old snapshots. The blocked request count keeps going up anyway and >> the .snap directory seems unresponsive to 'ls' or other commands. > > Sounds like a bug; it should be a quick operation. What version? Can you > submit a bug report? Preferably with a matching MDS log (and debug mds = > 20, debug ms = 1). > > sage > >> >> >> >> On Fri, Sep 15, 2017 at 2:59 PM, Eric Eastman >> <eric.eastman@xxxxxxxxxxxxxx> wrote: >> > Just watch how many snapshots you create. We hit an issues around >> > 4,700 snapshots of a singe file system. See: >> > https://www.spinics.net/lists/ceph-devel/msg38203.html >> > >> > Eric >> > >> > On Fri, Sep 15, 2017 at 12:25 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> >> On Fri, 15 Sep 2017, Two Spirit wrote: >> >>> Excellent. Yes was takling about CephFS. So basically it tags and >> >>> versions all objects and their corresponding metadata. Doesn't >> >>> actually replicate anything, and keeps the old objects around in the >> >>> OSDs? >> >> >> >> Something like that. :) >> >> >> >> s >> >> >> >>> >> >>> On Fri, Sep 15, 2017 at 10:37 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> >>> > On Fri, 15 Sep 2017, Two Spirit wrote: >> >>> >> few questions >> >>> > >> >>> > I'm assuming you're talking about CephFS snapshots here: >> >>> > >> >>> >> 1) Is the idea of snapshotting about 100TB of data doable with Ceph? >> >>> > >> >>> > You can snapshot the entire file system (petabytes) if you like. >> >>> > >> >>> >> 2) How long would such a task take? Are we talking seconds, minutes, >> >>> >> hours, days, weeks? >> >>> > >> >>> > Seconds (if that). >> >>> > >> >>> >> 3) what does "stop i/o" mean. Does the filesystem unavailable to the >> >>> >> user during the snapshot time, or is this administratively unavailable >> >>> >> to the user, or does ceph stop io somewhere while in parallel the data >> >>> >> can be read/written to? >> >>> > >> >>> > There's no IO stoppage. Clients essentially mark a barrier in their >> >>> > writeback caches so that previously buffered writes are contained in the >> >>> > snapshot and new writes are not. How long it takes for that data to be >> >>> > flushed and stable/durable on OSDs depends on how big your client caches >> >>> > are, but that does not cause any io stoppage or gap in availability for >> >>> > users of the file system. >> >>> > >> >>> > sage >> >>> -- >> >>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>> >> >>> >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- >> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
