Disk Replacement

[heldchen]

Hi,

i set up a new server for Truenas. 1 Pool with 2 SSD für System, and it workes perfect. Now i wanted to test a pool of HDD, get 4 of them into the system and build a z1 pool. Now i wanted to simulate a drive replacement for a faulty or damaged drive. No encryption no dedup or other things. I took of the drive physicaly, like it should be with a damaged electronic or equal things. I marked the removed drive as offline in Pool Status. Then i put a new drive to the same connection, go to pool status and push replace. Here i can choose the new devide da2 , and when i do so, the replace button is marked as pushable. But i cannot push it. It does nothing when i hit the button. I tried to choose "force" also, but the same happens-nothing. What to do??

 

[heldchen]

Oh, Replacement HDD is same model with same size withzout any partitions or something else!

 

[sretalla]

Are you using TrueNAS 13? (seems you are... since the thread is in that section)... maybe you should read the release notes:

/core/gettingstarted/corereleasenotes/

See the workaround at the bottom of the page.

 

[heldchen]

Thanks for this hint, that worked for me Hope for fix in near future.

 

[profwalken]

tryed the same but unfortunatelly in my case process fails displaying "device is too small" and they are same size HDD 2Tb but not same brand and model, one is WD red and the one I try to attach is Seagate Ironwolf , they are both 2TB disks.

 

[danb35]

Drive sizes are pretty well standardized these days, so you wouldn't ordinarily expect to see an error like this. Can you post the output of smartctl -i /dev/adaX for the old and the new drive?

 

[profwalken]

The result for ada1 new disk I try to attach

Result for ada2 old disk with datas

 

[profwalken]

When i try to extend Vdev Volume1 I get this

Code:

Erreur: Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/middlewared/job.py", line 355, in run
    await self.future
  File "/usr/local/lib/python3.9/site-packages/middlewared/job.py", line 391, in __run_body
    rv = await self.method(*([self] + args))
  File "/usr/local/lib/python3.9/site-packages/middlewared/schema.py", line 975, in nf
    return await f(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/middlewared/plugins/pool_/attach_disk.py", line 86, in attach
    await job.wrap(extend_job)
  File "/usr/local/lib/python3.9/site-packages/middlewared/job.py", line 484, in wrap
    raise CallError(subjob.exception)
middlewared.service_exception.CallError: [EFAULT] concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/middlewared/plugins/zfs.py", line 212, in extend
    i['target'].attach(newvdev)
  File "libzfs.pyx", line 392, in libzfs.ZFS.__exit__
  File "/usr/local/lib/python3.9/site-packages/middlewared/plugins/zfs.py", line 212, in extend
    i['target'].attach(newvdev)
  File "libzfs.pyx", line 2092, in libzfs.ZFSVdev.attach
libzfs.ZFSException: device is too small

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/concurrent/futures/process.py", line 243, in _process_worker
    r = call_item.fn(*call_item.args, **call_item.kwargs)
  File "/usr/local/lib/python3.9/site-packages/middlewared/worker.py", line 111, in main_worker
    res = MIDDLEWARE._run(*call_args)
  File "/usr/local/lib/python3.9/site-packages/middlewared/worker.py", line 45, in _run
    return self._call(name, serviceobj, methodobj, args, job=job)
  File "/usr/local/lib/python3.9/site-packages/middlewared/worker.py", line 39, in _call
    return methodobj(*params)
  File "/usr/local/lib/python3.9/site-packages/middlewared/worker.py", line 39, in _call
    return methodobj(*params)
  File "/usr/local/lib/python3.9/site-packages/middlewared/schema.py", line 979, in nf
    return f(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/middlewared/plugins/zfs.py", line 215, in extend
    raise CallError(str(e), e.code)
middlewared.service_exception.CallError: [EZFS_BADDEV] device is too small
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/middlewared/job.py", line 355, in run
    await self.future
  File "/usr/local/lib/python3.9/site-packages/middlewared/job.py", line 386, in __run_body
    rv = await self.middleware._call_worker(self.method_name, *self.args, job={'id': self.id})
  File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 1276, in _call_worker
    return await self.run_in_proc(main_worker, name, args, job)
  File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 1192, in run_in_proc
    return await self.run_in_executor(self.__procpool, method, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 1166, in run_in_executor
    return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
middlewared.service_exception.CallError: [EZFS_BADDEV] device is too small

 

[sretalla]

I suspect you're going to need to set your SWAP size to 0 and try it again...

System | Advanced | Swap size in GiB.

 

[danb35]

I'm wondering why OP detached the original disk from the vdev, and is now trying to extend the vdev--though that should work for a mirror vdev (and shouldn't be causing the problem shown here), it really isn't how things are designed to go.

 

[profwalken]

Woaw, right on target Sretalla, I was desperate and everything I did was never doing the job, but you point me in right way and reducing swap to 2 Gb instead of 20 Gb it was set let me finaaly add new disks and resilver, YEEEEESSSS.

So cool not to have complete setup , plugins and datas to rebuild from scratch. If you where here I offer you a beer.

 

[profwalken]

I'm wondering why OP detached the original disk from the vdev, and is now trying to extend the vdev--though that should work for a mirror vdev (and shouldn't be causing the problem shown here), it really isn't how things are designed to go.

Because one of the new disk decided to fail after one week of use and I tried to extend it after I received new disk.
I removed by error the original failure disk and all I did until now never reach to attach the new disk to the mirror pool. That's the why

 

[danb35]

The normal way to replace a disk (which works in mirrors as well as RAIDZn) is to offline the failed disk, not detach it. Then once you have a replacement ready, replace the disk--it's all described in the docs. For a mirrored pool, I don't think it's going to make much (if any) of a difference, but it's treading ground that hasn't seen a lot of traffic.

 

[profwalken]

mirror fully "on line" with 2 new disks Seagate ironwolf , resilvered from the previous WD RED disk that was always working but now detached.

Problem fixed , thanks you all for your advices.

 

[profwalken]

Well as I said it was my bad to detach the disk after having set it offline. But in GUI process to attach and extend the vdev was always hanging on same message "disk too small" and this was because swap was set to 20Gb on source disk, decreasing this to 2GB let me attach the disk and then resilver, and now all is OK