Re: [lustre-discuss] space is not released when removing files using zfs-0.6.4.2-1 and Lustre 2.8.0

2016-09-15 Thread Xiong, Jinshan
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

Re: [lustre-discuss] space is not released when removing files using zfs-0.6.4.2-1 and Lustre 2.8.0

2016-09-15 Thread Crowe, Tom
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

Re: [lustre-discuss] space is not released when removing files using zfs-0.6.4.2-1 and Lustre 2.8.0

2016-09-15 Thread Dilger, Andreas
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),

Re: [lustre-discuss] space is not released when removing files using zfs-0.6.4.2-1 and Lustre 2.8.0

2016-09-15 Thread Crowe, Tom
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

Re: [lustre-discuss] space is not released when removing files using zfs-0.6.4.2-1 and Lustre 2.8.0

2016-09-15 Thread Xiong, Jinshan
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,

Re: [lustre-discuss] (LFSCK) LBUG: ASSERTION( get_current()->journal_info == ((void *)0) ) failed - (ungracefully) SOLVED

2016-09-15 Thread Cédric Dufour - Idiap Research Institute
Hello, After looking at the LFSCK source code - specifically lustre/lfsck/lfsck_namespace.c - I was led to believe that suppressing the "lfsck_namespace" file in the MDT LDISKFS should be safe enough (NB: I had a backup of the MDT on a disconnected DRBD peer for the worst case scenario): #

Re: [lustre-discuss] (LFSCK) LBUG: ASSERTION( get_current()->journal_info == ((void *)0) ) failed

2016-09-15 Thread Cédric Dufour - Idiap Research Institute
Hello, On 14/09/16 20:58, Bernd Schubert wrote: > Hi Cédric, > > I'm by no means familiar with Lustre code anymore, but based on the stack > trace and function names, it seems to be a problem with the journal. Maybe > try > to do an 'efsck -f' which would replay the journal and possibly clean