gpart strangeness

[Eugene Grosbein]

21.08.2018 20:20, Mike Tancsa wrote:

> On 8/20/2018 11:34 PM, Eugene Grosbein wrote:
>>> I was trying to create a single partition on a 16G mSata drive and
>>> whenever I add a partition, all of a sudden the secondary GPT partion is
>>> borked.  Any idea whats going on here ?
>>
>> Did you look to "dmesg -a" output for additional hints?
>> What is system version?
> 
> RELENG11 r337953 AMD64
> 
> 
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0: <SATA SSD S9FM02.0> ACS-3 ATA SATA 3.x device
> ada0: Serial Number DED9075313EC01677930
> ada0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 15272MB (31277232 512 byte sectors)
> 
> Other than the message when I create the partition, nada
> 
> GEOM: diskid/DISK-DED9075313EC01677930: the secondary GPT table is
> corrupt or invalid.
> GEOM: diskid/DISK-DED9075313EC01677930: using the primary only --
> recovery suggested.
> 
> I tried different alignment options for the partition, and no changes.
> Doing MBR however seems to work for some reason
> 
> 0# gpart destroy -F ada0
> ada0 destroyed
> 0# gpart create -s mbr ada0
> ada0 created
> 0# gpart add -t freebsd ada0
> ada0s1 added
> 0# ls -l /dev/ada0*
> crw-r-----  1 root  operator  - 0x4b Jan 19 23:59 /dev/ada0
> crw-r-----  1 root  operator  - 0x7a Jan 20 22:09 /dev/ada0s1
> crw-r-----  1 root  operator  - 0x7c Jan 20 22:09 /dev/ada0s1a
> 0# newfs -U -O2 /dev/ada0s1a
> /dev/ada0s1a: 15272.1MB (31277168 sectors) block size 32768, fragment
> size 4096
>         using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
>         with soft updates
> super-block backups (for fsck_ffs -b #) at:
>  192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872,
> 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552,
>  19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232,
> 28209472, 29491712, 30773952
> 0#
> 
> 
> However, when I try to write to the disk, it crashes the box. I wonder
> if this is a bad batch of mSata SSDs.... Hmmm
> 
> 
> login: panic: ufs_dirbad: /mnt: bad dir ino 2 at offset 0: mangled entry

It seems like faulty media to me: it silently returns bad data.

There is an easy way to verify this just with naked eye:

yes | dd bs=128k of=/dev/ada0
hd /dev/ada0

That is, hd(1) should write back only 3 lines of output:

00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
01000000

If not, the media if faulty.