Oh, better still, as I kept looking, and the low-level panic retreated,
I found this on the mdt:
[root@lmd02 ~]# lctl get_param osc.*.prealloc_next_id
So, unless someone tells me that I am way off base, I'm going to proceed
with the assumption that this is a valid starting point, and proceed to
get my file system back online.
On 5/19/2014 2:05 PM, Bob Ball wrote:
Google first, ask later. I found this in the manuals:
26.3.4 Fixing a Bad LAST_ID on an OST
The procedures there spell out pretty well what I must do, so this
should be relatively straight forward. But, does this comment refer
to just this OST, or to all OST?
*Note - *The file system must be stopped on all servers before
performing this procedure.
So, is this the best approach to follow, allowing for the fact that
there is nothing at all left on the OST, or is there a better short
cut to choosing an appropriate LAST_ID?
On 5/19/2014 1:50 PM, Bob Ball wrote:
> I need to completely remake a failed OST. I have done this in the
> past, but this time, the disk failed in such a way that I cannot
> fully get recovery information from the OST before I destroy and
> recreate. In particular, I am unable to recover the LAST_ID file,
> but successfully retrieved the last_rcvd and CONFIGS/* files.
> mount -t ldiskfs /dev/sde /mnt/ost
> pushd /mnt/ost
> cd O
> cd 0
> cp -p LAST_ID /root/reformat/sde
> The O directory exists, but it is empty. What can I do concerning
> this missing LAST_ID file? I mean, I probably have something,
> somewhere, from some previous recovery, but that is way, way out of
> My intent is to recreate this OST with the same index, and then put
> it back into production. All files were moved off the OST before
> reaching this state, so nothing else needs to be recovered here.
> HPDD-discuss mailing list
HPDD-discuss mailing list