You can lfsck to see if there exists any orphan objects.
I’m adding nasf into cc list and hopefully he can provide specific commands to
run.
Jinshan
On Sep 15, 2016, at 11:23 PM, Xiong, Jinshan
> wrote:
It turned out that the object 136
It turned out that the object 136 are an internal object for object accounting.
Therefore, the results you posted seem to be normal.
Jinshan
On Sep 15, 2016, at 6:27 PM, Xiong, Jinshan
> wrote:
Thanks for the info. It makes more sense to
Thanks for the info. It makes more sense to be an OST object - I was looking at
wrong source where ’trusted.lma’ is extended for OST objects, which misled me
to think this must be a MDT object.
It seems like the objects on the MDT were deleted by ‘rm’ but somehow the
objects on the OST side
Hi Andreas,
The one "broken object" that we removed as a test, did live in O/0/d*. This was
the only file we removed while having a clone mounted as "native" ZFS (changing
ZFS property "canmount=yes"). We had took a snapshot followed by ZFS
send/receive to another zpool to accomplish this
Note that the "broken objects" may be Lustre internal metadata, such as the
Object Index files, so deleting them may be bad for your filesystem without
knowing what they are.
Not that I can say for sure your bug is fixed, but ZFS 0.6.4 is getting a bit
long in the tooth (tagged April 8, 2015),
Hi Jinshan,
The examples in the first part of the thread are from one of our OST's. We had
all previous files/dirs pinned" to the OST via setstripe; so there was a
specific top level directory associated with this specific OST. After the
recursive rm, we noticed the ZFS OST, still showed space
Hi Tom,
Just to narrow down the problem, when you saw the space was not freed from
zpool, were you seeing this from MDT or OST zpool?
It seems that the objects you dumped were from MDT pool. The object 138 should
belong to a Lustre file, and it has a spilled block attached.
Jinshan
On Sep 9,