That interesting information, unfortunately our failing server just failed completely, so copying the disks may be the only option at this point. It’s a JBOD setup, so we could pull the data off directly from the drives. It would have been nice to restore from the tool nice and clean. I had to use the tool to mark the PGs complete just so we could use the radosgw’s again. -Brent From: Brady Deetz [mailto:bdeetz@xxxxxxxxx] It's not simply a zip. I recently went through an incomplete pg incident as well. I'm not sure why your import is failing, but I do know that much. Here's a note in slack from our effort to reverse the export. I'm hoping to explore this a bit more in the next week. Data frames appear to have the following format: ceff DTDT SIZE PAYLOAD Size is probably in bytes? DTDT is frame type, 8-bits, repeated (so BEGIN=1 is encoded as 0101). File format looks like: Superblock - starts with: ceff ceff 0200 PG_BEGIN ceff 0101 <64 bit little-Endian size> PG_METADATA ceff 0909 OBJECT_BEGIN ceff 0303 <64 bit little-Endian size> (represents first object of a file?) TYPE_DATA ceff 0505 (represents an object?) (repeat TYPE_DATA frames until file completed) TYPE_ATTRS ceff 0606 TYPE_OMAP ceff 0808 OBJECT_END ceff 0404 (repeat above block for all files?) enum { TYPE_NONE = 0, TYPE_PG_BEGIN, TYPE_PG_END, TYPE_OBJECT_BEGIN, TYPE_OBJECT_END, TYPE_DATA, TYPE_ATTRS, TYPE_OMAP_HDR, TYPE_OMAP, TYPE_PG_METADATA, TYPE_POOL_BEGIN, TYPE_POOL_END, END_OF_TYPES, //Keep at the end }; On Jan 14, 2018 1:27 AM, "Brent Kennedy" <bkennedy@xxxxxxxxxx> wrote:
|
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
