[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12
From: Eugene Grosbein <eugen () grosbein ! net>
Date: 2022-04-13 5:56:48
Message-ID: e47ea345-bc3c-0bb6-20f2-3c2bb9fcd049 () grosbein ! net
[Download RAW message or body]
13.04.2022 4:26, Chris wrote:
> I just replaced a drive 2 days ago that exhibited the same behavior. I haven't (yet)
> checked the replaced drive yet for cause. But what I chose to do was as follows.
> Get a new (known dependable) drive. Add it to the system and dump the data on the
> failing disk to the new drive. At least you'll have a safe copy of it.
> You didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT or
> ZFS?
> How you proceed after making a safe copy will depend on how you manage your disks.
> UFS/GPT?: simply remove the failing the disk, and change the entry in fdtab(5) to
> point to the new disk.
> ZFS. It should be enough to simply replace the failing disk with one at least the
> size of the failing one and resilver.
Similar to ZFS case, it is possible to make the kernel to "resilver" non-ZFS disk
by temporary creating non-persistent block-level mirror with "gmirror create" command.
It will not create any "labels" on-disk but perform copying of contents
similar to "dd" command but in more efficient way:
no data transfer from kernel land to user land and back,
also it uses MAXPHYS blocks to read/write media efficiently.
Also, it would copy partition tables (and bootloaders, if any) of all kinds.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic