Date: Sat, 3 Aug 2019 16:26:13 +0200 From: Domagoj =?UTF-8?Q?Smol=C4=8Di=C4=87?= <rank1seeker@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers@freebsd.org" <hackers@freebsd.org> Subject: Re: Device's "stolen" sector Message-ID: <20190803162613.00001766@gmail.com> In-Reply-To: <CANCZdforpXsdFA-Aykv1pmdVgWaFEU8sCsraq9g-P7sptOJAEA@mail.gmail.com> References: <20190716182350.000054f8@gmail.com> <CANCZdforpXsdFA-Aykv1pmdVgWaFEU8sCsraq9g-P7sptOJAEA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Tue, 16 Jul 2019 10:45:07 -0600 Warner Losh <imp@bsdimp.com> wrote: > On Tue, Jul 16, 2019 at 10:25 AM Domagoj Smolčić > <rank1seeker@gmail.com> wrote: > > > 11.2-RELEASE-p9 > > > > Tested with >1 disks: > > -- > > SATA disk connected directly with SATA cable to MBO, shows correct > > amount of sectors. > > diskinfo -v ada1 > > > > When I connect it to the same MBO over USB to SATA adapter, 1 > > sector is missing (the last one) > > diskinfo -v da0 > > > > Having last sector inaccessible is a huge problem as many "things" > > use it for a metadata. > > This has many times caused MBR disks occasionally to not be visible > > at all while being 'da0' (gpart: No such geom: da0.) > > And also GPT disks to be in a [CORRUPT] state upon reattach > > directly to SATA interface. > > > > Before submitting a bug, there is only 1 variable left that I can't > > test, because I have only 1 USB to SATA adapter. > > It might be a hardware issue, so can someone else test this too? > > > > On 11.x, I'd install the sg3_util port. You'll need the sg device in > your kernel. Use sg_readcap on /dev/da0 to see if the numbers match > the devinfo from ada1. If they match, then we have a bug in the da > driver. If they differ, you have hardware issues in the USB to SATA > adapter. > > Warner > 11.3-RELEASE-p1 So, I've got my hands on another adapter ... It reports equivalent number of sectors to 'ada$N' Meaning the first adapter is faulty (It additionally doesn't report '# Disk descr.' as it is, but as 'Generic External'). But it came to my attention that both adapters show incorrect '# Disk ident.' Only when attached as 'ada$N' it is correctly shown. Correctly working adapter trims (tested with 2 different HDDs) '# Disk ident.' to 12 chars. Also Cylinders and Heads are VERY different when HDD is attached as 'da$N' or 'ada$N' (tested with ok adapter) This is not a functionality issue but informational one, but then again, some filesystems require correct CHS data during formatting in order to be bootable. Domagoj Smolčićhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190803162613.00001766>