Date: Wed, 13 Apr 2022 12:56:48 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Chris <bsd-lists@bsdforge.com>, mahesh mv <maheshm_v@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 Message-ID: <e47ea345-bc3c-0bb6-20f2-3c2bb9fcd049@grosbein.net> In-Reply-To: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> <5fefe57150f9efab867a775722b9d71b@bsdforge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e47ea345-bc3c-0bb6-20f2-3c2bb9fcd049>