Hi,
On 10/05/2016 02:18 PM, Yan, Zheng wrote:
On Wed, Oct 5, 2016 at 5:06 PM, Burkhard Linke
<Burkhard.Linke@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi,
I've managed to move the data from the old pool to the new one using some
shell scripts and cp/rsync. Recursive getfattr on the mount point does not
reveal any file with a layout refering the old pool.
Nonetheless 486 objects are left in the pool:
...
POOLS:
NAME ID USED %USED MAX AVAIL
OBJECTS
...
cephfs_two_rep_data 12 1695M 0 48740G 486
...
The majority of objects seem to belong to one file:
# rados -p cephfs_two_rep_data ls | grep -c 10000be9363.
414
But the first chunk of this file is missing (no 10000be9363.00000000 object
in that pool):
# rados -p cephfs_two_rep_data ls | grep 10000be9363 | sort
10000be9363.00000262
10000be9363.00000263
10000be9363.00000264
10000be9363.00000265
....
10000be9363.000003fe
10000be9363.000003ff
I suspect these objects are a remainder of a file deletion that was
interrupted. The remaining objects are the first chunks of files, all well
below the default 4 MB stripe size (-> named XYZ.00000000). All but one do
not have any xattr associated with them (no parent, no layout). In case of
the single object with parent xattr it seems to be a stray object. I want to
get rid of that data pool, but I would also like to avoid wrecking the
filesystem.
Do make a long story short:
What's the best way to verify that a certain inode id is not used/referenced
within cephfs anymore?
Is it possible to dump all strays to verify that the single stray object in
the pool is also an orphan and can be removed (MDS cache size is 5.000.000,
thus dumping the cache will result in a service interruption)?
Do the filesystem recovery tools detect orphaned objects in data pools?
check if 10000be9363.00000000 exists in the default data pool, If it
does not, these objects are likely orphan objects caused by unkown
file deletion bug.
Thanks for the fast reply.
Neither the default data pool nor the metadata pool contain this object,
so I'll remove the orphans.
Regards,
Burkhard
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
